Skip to content
This repository has been archived by the owner on Jul 27, 2023. It is now read-only.

Question: mesos-consul interaction with marathon folder #63

Open
kamaradclimber opened this issue Feb 16, 2016 · 7 comments
Open

Question: mesos-consul interaction with marathon folder #63

kamaradclimber opened this issue Feb 16, 2016 · 7 comments

Comments

@kamaradclimber
Copy link
Contributor

Marathon framework recently introduced folders to group application.

The effect on mesos task is to prefix the task name by the name of the prefix and an underscore. For instance:

/my/group/application

will have tasks named:

my_group_application.16836b3f-d40e-11e5-b006-c4346bb5c9dc 

Consul recommends to use dns compatible names which does not include underscores.

What would be you recommendation to cope with those names?
Could we consider a way to rewrite task names to replace underscores ?

@ChrisAubuchon
Copy link
Contributor

mesos-consul currently strips '_'s from the task name.

my_group_application.16836b3f-d40e-11e5-b006-c4346bb5c9dc

would be registered as

mygroupapplication.16836b3f-d40e-11e5-b006-c4346bb5c9dc

I'm not sure what else we can do. It would be nice to register it as /my/group/application in Consul but the service API doesn't support grouping.

@kamaradclimber
Copy link
Contributor Author

thanks for your response.

I think service name would make more sense if the underscore was replaced by an hyphen. It would reflect the hierarchy that marathon users are trying to define.

What do you think?

Maybe we could have this as an option?

@kamaradclimber
Copy link
Contributor Author

@ChrisAubuchon would you accept a PR to replace _ by - instead of blank ?

Would you prefer to have the replacement character passed as an option and default to blank ?

@ChrisAubuchon
Copy link
Contributor

Sure. I don't have a preference to be honest. It'd be nice if consul had service groups though.

kamaradclimber added a commit to criteo-forks/mesos-consul that referenced this issue Feb 19, 2016
Previously underscores where removed when creating the service name.
This usually does not correspond to the intent of the user since he set
a separator in the task name.

In the specific case of marathon, the folder separator is converted to
underscore when creating a mesos task.

Users in marathon sets: /mygroup/mysubgroup/myapp

Tasks name is mesos are: mygroup_mysubgroup_myapp.[guid]

Before this patch, consul service names were mygroupmysubgroupmyapp
After this patch, consul service names are mygroup-mysubgroup-myapp.

Fixes mantl#63
@kamaradclimber
Copy link
Contributor Author

Sadly, I thought mesos-consul uses the task ID to name the service and just discovered it uses the tasks name.

In the case of marathon, task name are completely different when using a folder
The application /my_group/application in marathon will be named application.my_group.

I need to find another patch.

@kamaradclimber
Copy link
Contributor Author

The behavior is challenged in d2iq-archive/marathon#3163

@kamaradclimber
Copy link
Contributor Author

I've implemented a patch to use the taskID instead of the taskName to name services.
criteo-forks@1ff7a6b

However I thinks this is very specific (will help only marathon users and might break other frameworks users).

@ChrisAubuchon coudl you reopen this issue ? I would be glad to take your input on a way to solve the issue.

@ChrisAubuchon ChrisAubuchon reopened this Feb 24, 2016
Mongey pushed a commit to Mongey/mesos-consul that referenced this issue Feb 26, 2016
Previously underscores where removed when creating the service name.
This usually does not correspond to the intent of the user since he set
a separator in the task name.

In the specific case of marathon, the folder separator is converted to
underscore when creating a mesos task.

Users in marathon sets: /mygroup/mysubgroup/myapp

Tasks name is mesos are: mygroup_mysubgroup_myapp.[guid]

Before this patch, consul service names were mygroupmysubgroupmyapp
After this patch, consul service names are mygroup-mysubgroup-myapp.

Fixes mantl#63
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants