auto hostname attribute

[tony-kerz]

per #555

[tony-kerz]

so i validated that the above works with mesos 0.23.1 and marathon 0.10.1 (with a dcos/aws setup).

the code currently grabs the hostname from the offer which turns out to actually be an ip-address vs a dns-name in my case.

not sure why that is or if it is configurable somewhere to have the offer contain a dns-name?

does anyone with more experience in that area have any insight?

i.e. this works for me

  "constraints": [
    ["hostname", "EQUALS", "10.0.3.51"]
  ]

but this doesn't:

  "constraints": [
    ["hostname", "EQUALS", "ip-10-0-3-51.ec2.internal"]
  ]

[gkleiman]

Please remove this line.

[tony-kerz]

sure, i was just following what seemed like a prevailing convention...

[gkleiman]

@tony-kerz thanks a lot for this contribution.

I posted some very minor comments, once you address them, I'll gladly merge this PR and include it in the upcoming release (2.5.0).

Happy New Year!

[tony-kerz]

@gkleiman thanks gaston, i tweaked the p/r per your suggestions.

let me know if you want me to nuke the isolated key word in the test.

tbh, i was having some issues running the tests at all within eclipse,
but i was able to run mvn test w/o isolated, so if that's the litmus test,
then i think we can omit.

i also, may have been running with a more recent version of specs2 when i experienced the issue,
so we could cross that bridge if/when we come to it

[gkleiman]

I am afraid that this is not have Marathon behaves.

If you look at Marathon's Constraints.scala, you can see that it will always use the hostname taken from the hostname field in the offer, even if the offer also includes a hostname attribute.

[tony-kerz]

true, that sentence is ambiguous.

the aspect i was trying to liken to marathon is about hostname automatically being made available for constraints.

good call tho, i'll try and re-word more specifically.

[gkleiman]

@tony-kerz thank you again for your contribution and for reacting so quickly to my previous comments. I am sorry it took so long to get your PR reviewed.

I added some more comments about things I missed in the initial review.

Regarding the tests, protos are immutable, so there should be no need for making the specification isolated. I checked out your branch and mvn test passed, so I guess we can skip that for consistency with the other specs in Chronos.

[tony-kerz]

thanks for the scala tips @gkleiman, can you review this latest revision when you get the chance ✌️

[tony-kerz]

oh, also, do you have any comment on the fact that i was only really able to use ip-addr as a constraint value vs an actual hostname?

any idea if that is somehow alterable via mesos configuration, or just inherent?

either way, i was thinking it should be mentioned in the documentation, cause i spent a cycle or two figuring out that i had to use an ip-addr v a hostname, and since the constraint key is hostname it's a little ironic.

[tony-kerz]

@gkleiman is there anything else i need to do on this for it to be suitable for a merge?

[brndnmtthws]

Using the IP in hostname is just a convention. PR seems reasonable.