Skip to content
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.

Allow Fleet to schedule with Conflicts against units not scheduled with fleet or that are not certain machine id's #1226

Closed
hookenz opened this issue May 13, 2015 · 2 comments

Comments

@hookenz
Copy link

hookenz commented May 13, 2015

I have some machines with some unit files placed into /etc/systemd/system.
These machines have physical drives attached and unit files to mount file systems and start databases.
Although these machines are part of the CoreOS cluster and can run other things, some units I wouldn't want to schedule there.

Unfortunately, suppose I have a unit /etc/systemd/system/mysql.service and then schedule another unit with fleet and place Conflicts=mysql.service, it causes the scheduler to hang when trying to schedule the unit.

Also, fleet only has the ability to work with glob patters in Go which seem to be very limited.
It would seem natural to me to be able to specify things like:

MachineOf = ! machineA

But I understand that doesn't make sense for the way MachineOf works. Because the inverse of ! machineA would be every other machine in the cluster. I suppose if you are only scheduling a single unit then this would make sense.

Another option would be to have Conflicts= take a machine id as well.

Are there any planned improvements in the pipeline around this area?

@bcwaldon
Copy link
Contributor

bcwaldon commented Jul 9, 2015

Could you use the machine metadata feature to do this? You could tag all safe machines with something like role=schedulable, or the inverse, tag the unsafe machines as role=unschedulable, then create units with matching Metadata options. It might be cleaner if we could use a != operator in the metadata, which is coming in #1294

@dongsupark
Copy link
Contributor

I suppose the question was already answered. Closing.

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

No branches or pull requests

3 participants