AW: AW: Customization of nova-scheduler

Laurent Dumont laurentfdumont at gmail.com
Wed Jun 16 00:54:35 UTC 2021


Out of curiosity, how did you end up implementing your workflow? Through
the scheduler or is the logic external to Openstack?

On Tue, Jun 15, 2021 at 11:48 AM <levonmelikbekjan at yahoo.de> wrote:

> Hi Sean,
>
> I am already done with my solution. Everything works as expected! :)
>
> Thank you for your support. You guys are great.
>
> Best regards
> Levon
>
> -----Ursprüngliche Nachricht-----
> Von: Sean Mooney <smooney at redhat.com>
> Gesendet: Dienstag, 15. Juni 2021 16:37
> An: Stephen Finucane <stephenfin at redhat.com>; levonmelikbekjan at yahoo.de;
> openstack at lists.openstack.org
> Betreff: Re: AW: AW: Customization of nova-scheduler
>
> On Tue, 2021-06-15 at 15:18 +0100, Stephen Finucane wrote:
> > On Thu, 2021-06-10 at 17:21 +0200, levonmelikbekjan at yahoo.de wrote:
> > > Hi Stephen,
> > >
> > > I'm  trying to customize my nova scheduler. However, if I change the
> > > nova.conf as it is written here
> > > https://docs.openstack.org/operations-guide/de/ops-customize-compute
> > > .html , then my python file cannot be found. How can I configure it
> > > correctly?
> > >
> > > Do you have any idea?
> > >
> > > My controller node is running with CENTOS 7. I couldn't install
> > > devstack because it is only supported for CENTOS 8 version.
> >
> > That document is very old. You want [1], which documents how to do
> > this properly.
>
> wwell that depend if they acatully want to write ther own filter yes but
> if they want to replace the scheduler with a new one we recently removed
> support for that right.
> previously we had several schduler implemtation like the caching scheduler
> and that old doc
> https://docs.openstack.org/operations-guide/de/ops-customize-compute.html
>
> descibes on how to replace the filter scheduler dirver with an new one.
> we deprecated it ussuri
>
> https://github.com/openstack/nova/commit/6a4cb24d39623930fd240e67d65013803459839d
>
> and you finally removed the extention point in febuary
>
> https://github.com/openstack/nova/commit/5aeb3a387494c4559d183d1290db3c92a96dfb90
> so from wallaby on you can nolonger write an alternitvie schduler
> implemenation out of tree without reverting that.
>
> so yes
>
> https://docs.openstack.org/nova/latest/user/filter-scheduler#writing-your-own-filter
> is how you customise schduling now but you cant customise the schduler
> itself out fo tree anymore.
>
> >
> > Hope this helps,
> > Stephen
> >
> > [1]
> > https://docs.openstack.org/nova/latest/user/filter-scheduler#writing-y
> > our-own-filter
> >
> > > Best regards
> > > Levon
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Stephen Finucane <stephenfin at redhat.com>
> > > Gesendet: Montag, 31. Mai 2021 18:21
> > > An: levonmelikbekjan at yahoo.de; openstack at lists.openstack.org
> > > Betreff: Re: AW: Customization of nova-scheduler
> > >
> > > On Mon, 2021-05-31 at 13:44 +0200, levonmelikbekjan at yahoo.de wrote:
> > > > Hello Stephen,
> > > >
> > > > I am a student from Germany who is currently working on his
> > > > bachelor thesis. My job is to build a cloud solution for my
> > > > university with Openstack. The functionality should include the
> > > > prioritization of users. So that you can imagine exactly how the
> > > > whole thing should work, I would like to give you an example.
> > > >
> > > > Two cases should be solved!
> > > >
> > > > Case 1: A user A with a low priority uses a VM from Openstack with
> > > > half performance of the available host. Then user B comes in with
> > > > a high priority and needs the full performance of the host for his
> > > > VM. When creating the VM of user B, the VM of user A should be
> > > > deleted because there is not enough compute power for user B. The
> > > > VM of user B is successfully created.
> > > >
> > > > Case 2: A user A with a low priority uses a VM with half the
> > > > performance of the available host, then user B comes in with a
> > > > high priority and needs half of the performance of the host for his
> VM.
> > > > When creating the VM of user B, user A should not be deleted,
> > > > since enough computing power is available for both users.
> > > >
> > > > These cases should work for unlimited users. In order to optimize
> > > > the whole thing, I would like to write a function that precisely
> > > > calculates all performance components to determine whether enough
> > > > resources are available for the VM of the high priority user.
> > >
> > > What you're describing is commonly referred to as "preemptible" or
> > > "spot"
> > > instances. This topic has a long, complicated history in nova and
> > > has yet to be implemented. Searching for "preemptible instances
> > > openstack" should yield you lots of discussion on the topic along
> > > with a few proof-of-concept approaches using external services or
> > > out-of-tree modifications to nova.
> > >
> > > > I’m new to Openstack, but I’ve already implemented cloud projects
> > > > with Microsoft Azure and have solid programming skills. Can you
> > > > give me a hint where and how I can start?
> > >
> > > As hinted above, this is likely to be a very difficult project given
> > > the fraught history of the idea. I don't want to dissuade you from
> > > this work but you should be aware of what you're getting into from
> > > the start. If you're serious about pursuing this, I suggest you
> > > first do some research on prior art. As noted above, there is lots
> > > of information on the internet about this. With this research done,
> > > you'll need to decide whether this is something you want to approach
> > > within nova itself, via out-of-tree extensions or via a third party
> > > project. If you're opting for integration with nova, then you'll
> > > need to think long and hard about how you would design such a system
> > > and start working on a spec (a design document) outlining your
> > > proposed solution. Details on how to write a spec are discussed at
> > > [1]. The only extension points nova offers today are scheduler
> > > filters and weighers so your options for an out-of-tree extension
> > > approach will be limited. A third party project will arguably be the
> > > easiest approach but you will be restricted to talking to nova's
> > > REST APIs which may limit the design somewhat. This Blazar spec [2]
> > > could give you some ideas on this approach (assuming it was never
> > > actually implemented, though it may well have been).
> > >
> > > > My university gave me three compute hosts and one control host to
> > > > implement this solution for the bachelor thesis. I’m currently
> > > > setting up Openstack and all the services on the control host all
> > > > by myself to understand all the functionality (sorry for not using
> > > > Packstack) 😉. All my hosts have CentOS 7 and the minimum
> > > > deployment which I configure is Train.
> > > >
> > > > My idea is to work with nova schedulers, because they seem to be
> > > > interesting for my case. I've found a whole infrastructure
> > > > description of the provisioning of an instance in Openstack
> > > > https://docs.openstack.org/operations-guide/de/_images/provision-a
> > > > n-instance.png
> > > > .
> > > >
> > > > The nova scheduler
> > > > https://docs.openstack.org/operations-guide/ops-customize-compute.
> > > > html
> > > >  is the first component, where it is possible to implement
> > > > functions via Python and the Compute API
> > > > https://docs.openstack.org/api-ref/compute/?expanded=show-details-
> > > > of-specific-api-version-detail,list-servers-detail
> > > >  to check for active VMs and probably delete them if needed before
> > > > a successful request for an instantiation can be made.
> > > >
> > > > What do you guys think about it? Does it seem like a good starting
> > > > point for you or is it the wrong approach?
> > >
> > > This could potentially work, but I suspect there will be serious
> > > performance implications with this, particularly at scale. Scheduler
> > > filters are historically used for simple things like "find me a
> > > group of hosts that have this metadata attribute I set on my image".
> > > Making API calls sounds like something that would take significant
> > > time and therefore slow down the schedule process. You'd also have
> > > to decide what your heuristic for deciding which VM(s) to delete
> > > would be, since there's nothing obvious in nova that you could use.
> > > You could use something as simple as filter extra specs or something
> > > as complicated as an external service.
> > >
> > > This should be lots to get you started. Once again, do make sure
> > > you're aware of what you're getting yourself into before you start.
> > > This could get complicated very quickly :)
> > >
> > > Cheers,
> > > Stephen
> > >
> > > > I'm very happy to have found you!!!
> > > >
> > > > Thank you really much for your time!
> > >
> > >
> > > [1] https://specs.openstack.org/openstack/nova-specs/readme.html
> > > [2]
> > > https://specs.openstack.org/openstack/blazar-specs/specs/ussuri/blaz
> > > ar-preemptible-instances.html
> > >
> > > > Best regards
> > > > Levon
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Stephen Finucane <stephenfin at redhat.com>
> > > > Gesendet: Montag, 31. Mai 2021 12:34
> > > > An: Levon Melikbekjan <levonmelikbekjan at yahoo.de>;
> > > > openstack at lists.openstack.org
> > > > Betreff: Re: Customization of nova-scheduler
> > > >
> > > > On Wed, 2021-05-26 at 22:46 +0200, Levon Melikbekjan wrote:
> > > > > Hello Openstack team,
> > > > >
> > > > > is it possible to customize the nova-scheduler via Python? If
> > > > > yes, how?
> > > >
> > > > Yes, you can provide your own filters and weighers. This is
> > > > documented at [1].
> > > >
> > > > Hope this helps,
> > > > Stephen
> > > >
> > > > [1]
> > > > https://docs.openstack.org/nova/latest/user/filter-scheduler#writi
> > > > ng-y
> > > > our-own-filter
> > > >
> > > > >
> > > > > Best regards
> > > > > Levon
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210615/e5468361/attachment-0001.html>


More information about the openstack-discuss mailing list