May be we could add a label containing application id to the pods and
services.
On Friday, September 18, 2015, Dinithi De Silva wrote:
> As per the offline discussion, we will revert back to the previous way of
> handling the pod ids and service ids. So we will use service IDs as
> service1, ser
As per the offline discussion, we will revert back to the previous way of
handling the pod ids and service ids. So we will use service IDs as
service1, service2 ... serviceN and the applicationId will not append to
this.
On Thu, Sep 17, 2015 at 10:39 PM, Gayan Gunarathne wrote:
> Idea for using
Idea for using the application ID as a service name to clearly distinguish
the Kubernetes service against the application ID.If we are using other
unique identifier, we won't be identify service belongs to the application.
OTOH we use application ID to identify the application and IMO we can have
+1 decoupling application id and kub8 service name. What if we repeatedly
query the existing service names and increment the seq no until an
available service name is found? This is what we do when generating pod
names.
On Thu, Sep 17, 2015 at 8:40 PM, Pubudu Gunatilaka wrote:
> Hi Gayan,
>
> Ca
Hi Gayan,
Can't we limit the Kubernetes service name rather than limiting the
application id. If we are deploying multiple applications, it would be
better if we can have meaningful name for the application ids. If we are
going to limit the kubernetes service name, we may have to come up with
anot
Added the logic to validate the application ID length.This is because we
are using the application ID as a Kubernetes service name which supports
up-to 24 characters.
But I could enable the application ID validation length to 20 as
integration test are failed due to integration test samples applic
