cloud_controller_ng
cloud_controller_ng copied to clipboard
cloudfoundry
App ports support within the manifest
Hi CAPI people,
I would like to create an app with multiple app ports and attached routes. I don't wont to go the extra mile by calling several additional CLI commands but instead have the support directly within the manifest itself.
Calling multiple CLI commands is cumbersome and error-prone and using a single manifest is much more user-friendly.
If you need more context: There was already a discussion on the whole app ports and routes situation at https://github.com/cloudfoundry/routing-release/issues/152 and it was mentioned that the CAPI team is responsible for the development of the manifest.
In case there are work packages that can be done by an "outsider" like me, feel free to contact me and I would be glad to help. :relaxed:
Thanks in advance for any help that pushes this topic further.
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/169439315
The labels on this github issue will be updated when the story is started.
@cwlbraa I know the networking program has been interested in a top-level routes key (peer to applications) to make things like app ports and weighted routing easier. I haven't been involved in any discussions around making that a reality.
@Gerg @reid47 any updates on VAT thinking around routes in the manifest? I asked the networking folks and their ask is to be involved in the design.
VAT is not planning to add any additional fields to manifests (except for maybe an optional version field).
Can I ask why? It's an awesome feature to be able to do mappings and interesting routings this way, but having to step out of the declarative manifest is a bit cumbersome. Is it because of the nature of revisions causing some weirdness with value changes between deployment updates? Are things just in a holding pattern until more decisions are made on cf-for-k8s networking & what interaction there might be w/ a k8s service object...?
Perhaps specifying version could be done in label metadata rather than additional fields? Though fields for routing options feels like it would add value & would likely need to be it's own field rather than also specified as annotation data. It's possible I'm mischaracterizing and/or oversimplifying this; I don't mean to come off as entitled, I just don't understand 🤷♂
Hey @aegershman , Greg is referring specifically to his team, the V3 acceleration team (VAT). They are focused mostly on deprecating v2. They added v3 routes a while back and Chris and I were just trying to understand whether ports and routes would be added to manifests as part of that effort. There are 2 other groups of people that work in this arena, the CAPI team and CF Networking Program.
The "version" thing is just so that we can change the semantics of the manifest in the future without introducing breaking changes. It's not related to this request at all.
I wouldn't say things are "in a holding pattern" IRT cf-for-k8s, but there is a ton of focus on that area. That type of thing has mostly deprioritized surfacing Routes on CF manifests. I know @ndhanushkodi & @tcdowney have been working on Routes in cf-for-k8s, maybe they can speculate as to how that work might affect requests like this?
I don't think it's fair to say that the work we're doing has deprioritized work on Route in serverside manifests. The Kubernetes CF Route CRD includes port as part of each Destination (it closely mirrors the Cloud Controller V3 definition of Routes and Destinations) and with the work we're doing we intend on Route resources being created in Kubernetes regardless of where they came from (v2, v3, server-side manifests).
I view the manifest as just another means of creating a Route and since port can be specified on the v3 insert destination endpoint it feels like adding it to the manifest as well would be a nice quality of life improvement.
Fortunately in the manifest spec routes are already an array of objects so shouldn't be a backwards incompatible change to add these additional fields.
👍 thank you both @cwlbraa and @tcdowney for the responses:
The "version" thing is just so that we can change the semantics of the manifest in the future without introducing breaking changes. It's not related to this request at all.
I see, makes lots of sense; as an aside, that's something I really admire about k8s resource definitions having the resourceVersion baked into the manifest itself, things of that sort, etc.
I view the manifest as just another means of creating a Route and since port can be specified on the v3 insert destination endpoint it feels like adding it to the manifest as well would be a nice quality of life improvement.
So then if I'm reading this correctly, this is something which is likely to come in the future to the cf manifest, though not currently prioritized / de-prioritized behind other v3-related work?
(( apologies, I fully know it's annoying when people pester about commitments and timelines and junk, and I don't mean to distract or put you all in a weird position, but alas, here I am doing it ¯\\_(ツ)_/¯ ))
@Gerg @reid47 I see from Tim that the app manifest spec now includes a routes section, am I right in assuming any modifications to that section of the manifest spec to specify ports and such are out of scope for the initial V3 GA?
@jspawar There is currently a routes section in app manifests, however it is currently nested under applications. The discussion here is around moving to a top-level routes field (peer to applications) to enable more advanced routing features in app manifests.
As for the "initial V3 GA", the endpoint for server-side manifests is already GA on v3. That said, the version field in manifests allows future iterations of app manifest specifications, independent from the API version.
My team (VAT) is not planning to do any additional work on server-side manifests. I suspect there will be efforts in the future to expand routing features in the manifest (weighted routing, app ports, route protocols, etc).
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/175726091
The labels on this github issue will be updated when the story is started.