Client-side constraints for jobs

[kompa...@gmail.com]

Hi,

We have a lot of jobs that works fine in our cluster. But we would like to add a dedicated node for a single job and place on the node only that particular job.

As a solution we can add a constraint for all jobs and nomad will place them to a current cluster and for the new job add a constraint for that dedicated node.

But it would much easier not to modify all .nomad files but add something like client-side constraint which would enable "non-greedy" allocation.

For instance on client-side:

      required_jobs_constraint {
        attribute = "${meta.host_type}"
        operator  = "="
        value     = "awesome_host"
      }

It wouldn't allow nomad to allocate jobs without `host_type` constraint.

Is there any way to exclude client from the pool of available clients for running all jobs except job with particular constraint?

[Pavel Znamensky]

Found the same problem on github: https://github.com/hashicorp/nomad/issues/2299

вт, 17 июл. 2018 г. в 12:10, <kompa...@gmail.com>:

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/nomad/issues
IRC: #nomad-tool on Freenode
---
You received this message because you are subscribed to a topic in the Google Groups "Nomad" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nomad-tool/4J0nkRnxPlI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to nomad-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomad-tool/3588647c-1140-494c-9207-d50e76c345bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin DynamicD]

Why not just put those nodes in a dedicated Datacenter?  Form a nomad perspective, it just makes them their own cluster that will never get deployed to unless your job specifically calls the new DC out.  It fits your use case exactly.

Essentially it feels a bit square peg, round hole: "put all these servers in a single pool ... but don't actually use them as a single pool" ... just make too pools.  It makes it obvious that this other bx has a special purpose, nothing will ever accidentally run on it, and it also makes it painfully clear where your resiliency short comings are ;)

[Pavel Znamensky]

You're right. Indeed I could create another fake DC and allocations would be placed as expected. But it doesn't look straightforward because it will add mess into monitoring and service discovery. 

 Justin DynamicD wrote:

To unsubscribe from this group and all its topics, send an email to nomad-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nomad-tool/231baa98-5b1a-4963-8ae0-f04d64b6eaf6%40googlegroups.com.

[pre...@hashicorp.com]

Nomad currently doesn't support your use case, however we have been discussing the notion of node pools to segment nodes within a datacenter and apply these types of constraints. This is likely coming in a future release.

[Pavel Znamensky]

Thanks!

суббота, 21 июля 2018 г. пользователь написал:

To view this discussion on the web visit https://groups.google.com/d/msgid/nomad-tool/2ee3cd5e-ac85-47f9-8d8e-be371522a944%40googlegroups.com.

[dma...@istreamplanet.com]

This would half-solve your problem, and is a total hack: You could reserve all the resources for your special job, so when it does get allocated, no more jobs will get allocated on that host.  That requires your special job to get allocated first, though.

[dma...@istreamplanet.com]

What about constrains on nodes just like you have constraints on jobs.  If a job can say "I will only run on node XYZ", a node should be able to say "I will only run jobs ABC".