Kubernetes SIG CLI, 21 Dec 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes SIG CLI 20161221

Description

Kubernetes SIG-CLI planned the Roadmap for 2017 and priorities for Q1.

A

Recorded there we go.

B

All right, are you all able to see it? Yes,.

C

B

And so I just learned, I have a person starting at the end of january. They have to ramp up and it probably take them a month at least, but we could also have that person. If there's any like starter tasks or good ramping up tasks, that's something we can also add.

A

um Yeah in terms of ramping up I think we have a github label. Hulk wanted, or something like that. I could I could make sure we have a number of our issues tagged appropriately, 14 flat, like would be nice starting points for people ramping up. So that's one of the ideas in case you want to, you know, give them some issues. Using label would be nice.

B

Yeah I think that's a good. um A good plan. It'd probably be good for them to to go through the process that we have anyone ramp up on Oh.

B

So yeah that might that's probably a good good way to start his just have them experiment with how well that label actually works.

B

Alright, so should I just make sense for me to just go ahead and walk through these items. Do we say that's about yeah what works for that, all right, um so yeah, just a recap. The items are kind of group thematically about what the broader objective um are. Four set of items.

B

The first one listed here is around user education in essentially getting not developing features are not fixing bugs like getting folks comfortable with. What's already there.

A

B

The first part is around just documentation: I have an item here, I listed as just getting the commands logically grouped on how we want them, and there's I've been thinking about this more since we first discussed it and we're finding division. I think this is pretty small task. Actually, it's more sense of examples in productivity hacks. One thing I've seen on issues is a request for a feature uh that that is like I wish. Could control could do this and then we get it either it approved or halfway through min implementation and someone who's.

B

Just a really good hacker on coop controls says: oh, did you know you can combine these two flags and pipe it to this other command, and then you get that same creature. These. These are things I'd wasn't even aware of or hadn't considered, so having someone who's familiar with all those hacks, or maybe it's just collectively, sharing some of our our productivity things we do and documenting them might be a way to get them into people's hands.

B

Diet document commands that are undocumented. Currently, all of this to q1, when I was putting together a reference documentation. I realized that some commands just don't even have a single line of documentation around them about what they do.

B

I'll talk abouts, suggesting these comments to it looks like.

B

Okay, so polite a holistic walkthrough of the tool in major functions.

B

This this is mainly derived I was thinking. Documentation is thinking, documentation more in the form of like tutorial focused unless reference focused, we're assuming user comes to ku control without any knowledge about what the tool does or how to manage your configs. We have some documentation around this on the website already, but I I think as the tools kind of evolved in our vision of it is evolved. Maybe we want to restructure a backyard, especially with the apply stuff, um since that didn't exist.

B

Originally in the first iteration of KU control, the onboarding documentation doesn't do a great job of essentially taking that into account and explaining the differences. Someone that's stuck in design, developer, Docs, I think this is really just like reevaluating kind of all, how we introduce users the tool and then yes, something about linking to online docs. We need to think more about how that might be done. If we do it I'll, actually I'll try and stick to is just the top-level stop in the comments.

B

um Well documented trade-offs when multiple approaches to solving a problem. This um stuff here is like: how can how can users factor their config right? Do they do the storm in github? Do they storm locally? Do they just copy and paste the same thing over and over again or do they use like Jason net, to try and use inheritance which box is used well, but there's a lot of manages to it.

B

We went around down this road internally with something in Google, using inheritance, based approach, and it just turns out to be really unmaintained well, after a bit, do you use github and branching and use that to track diversions, so just I think that's an example just like factoring config and how there's three options right there about how you may want to factor your configs and if you think about like directory structure versus like test versus pride as directory structure stuff, like just I, think talking through the tools people have used to become successful so that when a new dev ops team decides that they're going to use Q brunette a sand, I need a way of managing their configs.

B

They actually have prior art to reference.

A

Yeah in terms of in the tank team of user onboarding, and things like that, it's related to D, provide holistic, well true item, but I see that not only as a point in terms of documentation, but also probably in line walk to write because sometimes sometimes I feel like well keep CTL is, is always related to a context right when you are using Kip's TTL. You are in a namespace in a given server with a given session, so everything you ran and cube.

A

Ctl is a little related to a can, take context and I feel that sometimes we we don't do a great job. You know for people to understand exactly where they are at some point and where they can go next right. So for me, when I'm running a number of cubes CTL command, sometimes I get lost well, where exactly I am I am in this given name space and if I'm a new user, I just did my first keep see children or my first keeps tell create okay.

A

That went well so, where do I go next, so I see that topic specifically also as a inline issue, where we could, you know, have some hinting in terms of you know where you can go max after doing and create something like that step special, because cube CTL is is capable of knowing if your new user right, because if you are just starting keeps gel, creates the cube config files for you, so that we know it's the first time you are actually doing something in keep CTL, so we could think about some inline hinting or something like that.

A

Not sure if you guys agree, but yeah.

B

um Mushroom caps right here and one user.

C

Yeah I think I think there is already an issue about I. The coop contra suggests next command, as you ever find that out. If we did one place.

B

Yeah I'm, pretty sure, you're right, 20 and there's there's probably some variations on this like starting from doing one in line tutorial that walks you through how to use that the tool or do we want just better messaging, now put about what's going on or do we want better air messaging like there's an issue about, if you, if qu controls in configure to talk to a cluster, it just says like it can't talk to local host, essentially, which is very confusing because it's like it was never completed, that sort of thing, yeah, exactly: okay, tutorials uh next command context.

B

Right great unya, as they go through this just think about that I guess the plan is going to be like. Why didn't you just know any that you think are important for q1 or maybe like we can each rank or top three at the end, and then that way after I go through all these, we can just quickly kind of figure out which ones we want to nail for 16 all right, so theme, engineering velocity.

B

This is essentially technical debt, but also includes stuff that maybe isn't like technical debt, but just things we could do to UM make us a faster and more effective Karen.

B

No no I think we're talking about. Is that, as you run, coop control, you can like right to control help. I can give you commands to run right like this is how you run engine X right and then give you like the next set of commands. Great well um velocity.

B

Yeah, so one of these one of the things I think, is a great there's. A proposal about this I think I. Think a lot of this stuff is just deciding what we want to do: I mean within the whole set of requirements or whole set of goals. I think a broader meta theme here is like dr., not necessarily fixing anything or adding anything but just deciding what we want people to do, because there's a couple ways of solving a lot of problems.

B

So yeah distribution distributing multiple tools for developing a set of client tools: khoob admin to control, there's a federation, client tool. I think this list is just going to grow. You know linearly over the set of releases, so we need to figure out a packaging mechanism, and that may include stuff like how do we package and allow users to install tools that may not be distributed with core but are considered um tied to the project very closely, such as hell more composed without stripping.

B

um Moving some of the main repo is what I think is really important from the perspective that it's going to allow us a lot more control over how we develop the product. But it's a lot of work. You're doing some research on good kid, sub-modules right now on sub trees, which I don't know that much about but might be able to help us or not.

B

16, though it's a lot of work.

B

Okay, common client libraries factored out client tools for shared infrastructure, so this could be a couple different things. Ideas I was thinking here include. So what is flags I know? This seems like kind of a silly thing, but just like having the set of flags that we think might be common for tooling, back room doubts you can just inherit them might be an interesting idea that way as you switch between tools, the dry run flag is always consistent and it like always dry dash, run not like no dash or something like that right.

B

That one's, like seems really minor and easy to do, but might be helpful for folks being started. All there is like we have infrastructure built up around like visiting all the files, for instance, as we, if you do, directory, apply on a directory or something like that. If infrastructure around just how you are busy config files, how you parse them, we have library set up around authorization and authentication config stuff, we're probably going to have some stuff set up around.

B

Can preferences and preference files, so I imagine kind of what I'd like to see is if we develop clients like khoob admin and the Federation stuff, that the way that you manage preferences for those guys is the same to the extent possible same syntax, maybe even like similar same directory in just a different dot preferences file or perfect, like cube admin, dog preferences, or something like that. I.

A

Was thinking am even something related to validations, because we currently don't don't see them and have that inside keeps itself right, because every command does, for example, flags and arguments validation a different way, so Jose shin should also be a target. We could start by having something side cubes, to tell some library that validates like mutually exclusive Flags require arguments. Things like that in make the actual validation and also our message messages consistent, and then we strike that as the library.

B

That's a good idea that actually makes me brings to mind something else.

B

Is like we going back to the theme of just documenting how we recommend people do things even within coop control itself? We have this notion of subcommands versus top-level commands and you can either create a sub command or you can create from a top level command where you can add a flag to a top-level command to get the same thing right, which is to control behavior of that command.

B

I've seen some e example of this, where we do something the same thing, two different ways as we have could control run then dash dash, like generator, which allows you to do like job versus deployment versus pod or something else, and then each one of those has their own set of mutually exclusive flags. That's how I personally, this is tough, where you can all these job flags.

B

If using the job generator sort of thing, then you have could control, create job to control, create deployment which allows so commands instead of place to control them, and then now you actually don't have that mutually exclusive thing and all the flags become much more discoverable, because you know what all the job flags are. When you do, control help create job or whatever it is so again, just just having better guidance around when you sub transverses, adding plagues.

B

Cool Tony, that's cool that this is something freaking cute. One I think I think this would actually be really helpful and powerful updating the roadmap yeah. Oh my gosh yeah. How do we do this stuff? There's? Also there's also all projects github has like projects for managing these things. Do we want to move the roadmap some of the stuff into a project, get a project which allows you to like mark items off automatically but doesn't allow you to do cross repo tracking.

D

They added cross repo tracking like a couple months ago. If we wanted to use it really. Yeah we've been using it a few for a few projects. It it works pretty decently. Thank.

B

You, oh man, that was something I just I've been wishing for every morning when I wake up. So that's awesome. Okay, yeah santa came early with your apparently a couple months ago and I just didn't realize it. Oh great thanks, Erin, that's huge I have some work to do later today: um okay, moving on to Application Lifecycle Management. So this is actually probably the more feature-rich piece see. Also clue. Control does number different things that are in its wheelhouse. It sets up configuration stuff for you.

B

It has some cluster management tasks, but this is what I think of as it's like core competency and what folks are using it most of the time, which is, if you view the kubernetes cluster, as the primary purpose is to run applications of some sort where applications is some workload or some process running somewhere, and so this is about using coop control to really manage that on Cooper, netis um and I.

B

Think part of this. So the first item I have here is actually not about to control itself but like how does coop control fit in with the other tools that um are needed right, because coop we can all use to control to go launch a deployment on keroon a days, but that's typically not sufficient to run a organization you need like see.

B

Icd may possibly write some folks do that you need a dev ops team that is managing this, so I think some of the things here are, if you're using coop control to like you, control with a config based mode. How do you initialize those configs right? Do you just write them from the ground up I know like internally at Google the way we initialize configs?

B

Typically as we go by someone who solved the problem before, like my have a Java app I find someone who's written a config for java app the copy and paste the whole thing into my directory. Half of the stuff I don't understand what it does so I just leave it there, and then you know bang on it with a hammer enough to make it work. That's probably more true in adjacent net world, where you have inheritance and things are a lot more complicated than what it is with flat configs, but I still think we.

B

We could do a better job of saying how to do this, and in one way you can even do.

B

It is food control that, like create deployment, dash, def image, dash, dash replica count and then do dash dash dry, run and dash 0 gamal, pipe it to a file, and that actually creates the config for you and it's not perfect, because it defaults some fields that you might not want defaulted in the config, but it does a pretty good job and it's actually pretty cool and I'm not sure if we tell people that that's even an option. um This is this is a big task for me.

B

I think, and it's mainly more strategic, looking forward to figure out what areas is kute control where's. Does it fit well with the other tooling available? And what areas does it not fit well, and we need to change a little bit. Yeah.

A

I definitely agree about being a big desk and even for q1 what kind? What kind of methodology could you use in terms of understanding from our customers, because I'm not I'm not sure if you guys have google have a established methodology, I already saw feel doing a few times some kind of fall with users, but would that be something like that? Or do you have anything else in mind? Oh.

B

Fantastic question I mean this is something I'm trying to figure out like naively what I, what I'd like to do is see if I can sit down with some of a diverse set of customers. I'm thinking between three and five over the quarter for like days with dev, ops, team and I, know how much I get to really look at like their code right, because you know it's all private but to the extent possible, I'd like to sit down and actually watch like box, do a push yeah I mean, and I liked it.

B

I have someone walk me through like this is how the kid gets checked in, and this is how, like the cluster, gets, updated and here's all the steps in between and then just take notes on that and try and and see like the pain points and document that sort of stuff. I don't you have other.

A

Ideas: yeah now that that's absolutely nice yeah. It would be awesome if we could do that with unaware of customers. We here in openshift we a couple months months ago with these did something similar with some customers in Europe, but it was much more focused on our web dashboard, but you know it would be something similar for the CLI and if we could, you know, understand the process for a company like that yeah. That would be awesome.

A

B

I'd love to know offline I'd love to talk to you just about how about you will you found that maybe just impossible? I can take your learnings from how to run that nah um yeah, so I need to come up with a plan, but I need to at least have a planning to one. This is really not well defined right now, even how to go about approaching this from UM threats this stuff. There's a lot of stuff in here.

B

I skipped a couple things but, like you, control apply, we know it's broken in just certain ways. We have a list of issues like part of a polite cycle management is making sure that the tools work and do what they're supposed to do um and then the config factoring I think I talk to me a little bit about that earlier.

B

I'd like to do some research here as part of that first thing about how people are doing that the command based management, I. Think of is like there's kind of three ways: I think of goop control, managing apps, there's command based, that's the crate set for you run, exposed set of commands. Then there's the config based imperative commands, which is create, delete, update or replace I'm config files, and then the apply and I think the imperative can fake is pretty worked pretty well.

B

We don't have too many issues with it, because it's pretty straightforward and uses the API pretty much directly, but the apply and the set ones are all client-side logic.

B

um Client version skew retains correct, behavior, Wow, 28, q1, yeah, I. Think that sounds good to me. Okay, I! Don't know you probably have a better idea of how much work this is than I. Do getting think. There's a couple pieces to this.

B

So one is the simple: the simpler pieces I'd stay hard, but at least well understood what is needed, which is the not having the compiling go types I think that's going to require actually API changes, because right now we get a bunch of data from the compiled in go types from the struct tags is how it like.

D

B

And that's where stuff right and they have to add that to the open, API spec as extensions or we would.

C

Ya, are they down a status I? Think.

B

I can talk yourself. I have some idea on how to do some of that stuff, but I, probably medi. This person will have to talk to you. The other piece is going to be stuff that just breaks um I know why we keep seeing this, but there's some legacy. Logic, that's just baked into assumptions about how stuff works in the server one of these that's going to break again for 16.

B

Is this the garbage collection? Every time we add garbage collection or briefing of children? For some reason it breaks the client-side garbage collection.

B

That stretch, that's gonna ain't going to take just a few quarters, that's what you work it out and the only long-term solution. There is moving stuff out of out of what's running the client and into something run. That's tied to the server version.

B

And third-party resources in federated API resources. Okay, this is another one. That's going to be, maybe a bit of work. Just because again we don't! Those struck tags don't exist anywhere, we can do is possibly as an annotation on the third party resource or something about how to merge fields.

C

Actually, I'm not sure why we can complete this untrue. One yeah, since there are many outstanding communities of solar power, resource and I have talked with David. Then we may want to first update sort of power source implementation, and then we can focus some creative issues after that, okay.

B

That makes sense, I just removed it I think between that and the the one that the arm. Sorry, the version skew like I think we could only do one of those they're, both pretty meaty tasks right extension support. This goes I see.

B

I, just one second I, just wanna make.

D

B

Pack, book period.

B

B

The I think we kind of covered this. The last thing I.

B

Think this is so generally. We know that some things are broken with apply and the extension resource types. We probably want to do something a little more exhaustive in terms of making sure that those work once we fix the known issues.

B

Okay, Tony yeah I think this might be a stretch for q1 and we don't have a proof design for this, yet I know Clayton has a design. Sorry, I was talking about the coop control, supports extension points to add additional commands.

B

These should support extending subcommands to work with their prey resources and federated api resources.

B

Just might be a stretch, no ah Erin, I I, don't think so. Man.

D

B

Out of the box.

B

Yeah I think Heather's API is pretty new yet but Bobby I know you'd, know better, because red had us a lot more hands-on experience with that than I do.

A

Yeah but as far as I know not yet.

D

Wha can either of you guys point me to an issue for that. If there is one just.

B

For federated API resources.

D

Specifically for the discovery.

B

C

Oppressed of the ninja here are just some comment.

B

Are you talking about that in the proposal comment anything yeah.

C

Does it not this one I think about this one.

C

C

Okay, I was in dance.

B

Yeah so in Tony's comment there is a proposal about the coop control extension keys. That's not targeted at the at the Federated API resources. It looks like both. Those comments are targeted just at the general extensions I. Don't think I'm not aware of any issues about to control working with federated the API. Okay.

A

Cool now, I personally, the the way AC extinction supports or key one is that I believe we should come up with approved designs for everything we want to support it at least extension, so, first resources and Padres very good resources and a neo subcommand liking the proof of concept I did so for me, you know if we can close on a design for all of those on q1.

A

That would be good enough, because you know it's been in discussions for quite some time already, and so we should focus on a place close on the proposal and then they cause the actual implementation actually happen after q1, probably.

B

Yeah, I think, that's more realistic unless we're getting an army of fully ramped up engineers.

B

um Okay and then the last item I have here is about.

B

This idea of being able to a notion of exposing applications, that's kind of first-party entities and grouping multiple deployments, maybe into an application and being able to interact with them in that context.

B

So, for instance, if you have like a Redis master and the reddest nodes- and you do if you do a Google get apps and it would show you that is one application composed of multiple controllers, that sort of thing and that this would extend to the UI, and so you have kind of this native feel across both, and this has to do with the extensions because third-party resources may so like for Cassandra. For instance, I think you could create a third-party resource that then um has a controller that uses multiple different.

B

Other controllers, like deployments kind of like I described, credits and you'd, want to be able to expose that okay almost done to control as a platform. This goes back to kind of some of the engineering velocity pieces, but is essentially. This is automatically. We've talked about user education, engineering, velocity and managing the applications, sending it the cluster itself, and this goes to kind of whatever, like the infrastructure, could control provides that's not business logic for specific commands. How do we support that.

A

In terms of Lee, of removing the dependency of Cobra, I have a couple for requests or issues from some external contributors that some shepherding they're, both stale forever. Probably I didn't hear from her from them for a few weeks, but there there is some work started in that sense already, so removing dependency of Cobra in making the actual command execution separate from from the actual commander. Cobra I'll have to take a look at those pr's again see if they were able to do any progress on that. But anyway, if somehow started already.

B

Okay, excellent reduce to control logic and moving it into the server. This is pretty good, there's a tracking issue.

B

We should I guess marking it as q1 means we want to do something here. It's not I guess we can.

B

We can leave it kind of flexible, which items and irie planning on having Tony's is something you're planning on driving yourself, and you have kind of a concrete vision about what sub items you'd like to see completed. Yes,.

C

Existence of cars Marge one, so I might get some small paste on in co. One like move printers to suicide, I think about getting down on the first quarter off. Ok,.

B

Let's start: um is there a design doc for that or we already discussed? How are gonna do that I can't remember yeah.

C

We already have one ok.

B

Cool um yeah after the meeting maybe go up and just add, clarify like what specific issues just on the dock by adding printers and the link tissue design, technical debt, yay Fabio, actually making our issues meaningful. That sounds wonderful um stabilize. What does stabilize coop control apply is that does that go back to that life cycle management, about yeah.

A

Absolutely if you want to remove it from tech map vector case I'll.

B

Just add C issue c-section and.

B

Civilized improved, printing and describing framework. Okay, tony, is this of moving into the server side piece now.

A

I added that one, it's related to number la issue I had so if there are a large number of drinking and describers issues, so I add that there in the sense of well, we should probably try to fix some of them because they're just too too many of them. On the other hand, I'm not sure about the work from moving printers to the server side. If the actual code base would be reused entirely.

A

So I'm not sure if that you know plays well with the work of moving things to the server side, but anyway it's a huge tech depth. There are just too many issues related to printers and stuff. This.

B

Is amazing, this umbrella issue? I think I'm just going to give this to the person starting and just say me through these quick, because.

A

It looks like a great.

B

List of things that are relatively simple, yeah.

A

Absolutely there are some really minor ones. There are some that required decisions like things like we not be completely compatible with emma 1.2. We take some pieces from yema 1.1, so there are some things that require decisions, but on the other hand, there are a bunch of issues that really minor stuff minor creases. To do.

A

B

Yeah, um that seems like a good starting point. Just getting the number down will allow us to focus like, even if they're, like simple fixes that are hugely impactful. Mr., the noise yeah.

A

Absolutely I added key one to that topic exactly in that sense. You know I would like, for you want to see that number go down at least a little bit. You know, or at least we could keep the face of not having a lot of stuff still being added, and you know not come to the end of q1 and have like 1000 of them. So we should illustrate to improve a little bit number.

B

Okay right so we've gone through the full list. We have a number of different items, a marked I guess. The second piece of this is like: how firm do you want to make these commitments? Are these just ambitions or, like things we'd like to work on and we'll get some of these done, but not follow them or are these like at the end of the quarter? We fully expect everything that says you want to be able to be crossed off this list. At least some section of it.

A

Well, I think for some of them le at least it's worth that we start and probably continue for a good part of the year right. For example, the item about understanding the processes from our customers, so I see that as an ongoing work, probably so not very free will be able to come up with a closed.

A

You know government by the end of q1 anyway, but it would be nice if we could at least start that at least which one or two customers, something like that to at least you know have by again, if you want have a better understanding about the topic.

B

Yeah that makes sense.

B

Yeah, yes, I, agree, I, agree with what you said and I guess. Just a point of clarification is Dewey I.

B

Suspect that kind of with what we've called out on here, some of these items, we won't even like start q1. It's kind of my gut feeling. It just seems like there's a lot of stuff which might be fine, and maybe these are like some of these items are the things that we say. If we get new community members will stick them on these right, like especially big, create view commands. That seems like really straightforward one.

B

um Maybe maybe we should just call out like of the items that we have marked is q1, which ones are we going to say like we fully intend to have at least started this and made progress on it in q1 vs? These are things we're going to tell other people to focus on.

A

Yeah personally, I feel I feel ok with pretty much all we marked as key one except probably turbo, researches, stuff, I'm, not sure and specially curated API researchers, I'm, not very free, will be ready to move. You know anything comes up of those in q1, but a part that I think it's plea: okay, okay, no.

B

A

If you guys agree, but that's how you know, that's how I feel it.

B

Yeah I think sorry go ahead. Tony yeah.

C

I think for third-party resource we may not focus on coop control, only first quarter when I first I'd some suicide implementation, and then we can go always q control part of certain resource so generally as ink. Well, we can live a lot touch with adding cube control side, support for certain resource.

B

That sounds good to me, so I'm just going to mark both of those two. That's a really good point fabio and I didn't realize I think that's what I was thinking, but those two are uh potentially a lot of work, but if we just start them and start scoping the work in deciding what needs to be done, that's probably a good goal for q1 and then um we can revisit them in 1.7 or q2 yeah.

B

Hello, so I can, if we're happy with items that are marked off here, I can either me or one of you guys, can just pull them out and put them in the either a spreadsheet or another document that we can share with the community.

A

Yeah, absolutely I can do that. Phillip I think you're already on pto right, but I can still do that before the end of this week and sent to you guys. I mostly feel good about the list. Let's put it on a spreadsheet and give a difficult look at it, but we're all I think it's looking good.

B

Fantastic yeah, I'm feeling really good about it too.

B

Cool, ok and then Aaron. One last thing: uh do you is there anything on here or what's your plan for q1? Are you planning on working on any of these items? Would you like us to involve you in anything specifically I.

D

Can't really commit to any work right now, but I am going to be coming to these stand-ups every week, starting in 2017 and hopefully I'll have a better picture. Then that we can do is.

B

There something specifically you'd like to get out of the stand up. I.

D

Mostly I'm coming to this from the tpr world, I want to see where I can pitch in on getting tprs better represented in cube, see Tito at this point, but this doc has illuminated a lot of other stuff that I need to gather my thoughts on and and I'll hop into the slack room and dump my thoughts. I guess: awesome!

D

B

Cool so then yeah, presumably since tony, was looking at the tpr, no wait. Nevermind did that kid strike now. It's here uh sure apply works with tpr and federated api resource yeah. Since uh you guys will probably talk about that. At some point I assume yeah.

D

I'm also I've started since this doc has a lot of federal api resource language in it. I'm also pretty interested there so tony I'll ping, yuan slack and ask you a million questions and bother you until you tell me to stop. Oh.

C

Ok show sure thanks.

B

If you guys are looking for background on federated api resources, Paul Maury is doing a lot of work with that now from the Service Catalog side.

D

Where I'm coming from 20.

B

B

All right so I guess that's it for this meeting and I guess: let's see next week, I we're not meeting next week right, yeah.

A

That's right, I'm, not sure about the ball January. You guys have a meeting at the first week or let it just keep for the second wake up. Demaree.

B

um Whatever is friendly schedule that.

A

This seems good to me: okay, yeah I'll just get. Let me actually check when you next one so no meeting next week, and then we have one for january for to the first week of january. If that works, for you guys, you took it for me. Yeah.

C

B

Cool sounds good to me too, all right! Well, everyone enjoy your holidays and I'll see y'all later yeah, just like.

A

I'm party Oh guys great job. Thank you. Okay,.