Open Stack

On Tue, Jul 18, 2017 at 2:39 PM, Balazs Gibizer 
<balazs.gibizer at ericsson.com> wrote:
> 
> 
> On Mon, Jul 17, 2017 at 6:40 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> > On 07/17/2017 11:31 AM, Balazs Gibizer wrote:
> > > On Thu, Jul 13, 2017 at 11:37 AM, Chris Dent
> > <cdent+os at anticdent.org>
> > > wrote:
> > >> On Thu, 13 Jul 2017, Balazs Gibizer wrote:
> > >>
> > >>>
> > 
> /placement/allocation_candidates?resources=CUSTOM_MAGIC%3A512%2CMEMORY_MB%3A64%2CVCPU%3A1"
> > >>> but placement returns an empty response. Then nova scheduler 
> falls
> > >>> back to legacy behavior [4] and places the instance without
> > >>> considering the custom resource request.
> > >>
> > >> As far as I can tell at least one missing piece of the puzzle 
> here
> > >> is that your MAGIC provider does not have the
> > >> 'MISC_SHARES_VIA_AGGREGATE' trait. It's not enough for the 
> compute
> > >> and MAGIC to be in the same aggregate, the MAGIC needs to 
> announce
> > >> that its inventory is for sharing. The comments here have a bit
> > more
> > >> on that:
> > >>
> > >>
> > 
> https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L663-L678
> > >
> > > Thanks a lot for the detailed answer. Yes, this was the missing
> > piece.
> > > However I had to add that trait both the the MAGIC provider and to
> > my
> > > compute provider to make it work. Is it intentional that the 
> compute
> > > also has to have that trait?
> >
> > No. The compute node doesn't need that trait. It only needs to be
> > associated to an aggregate that is associated to the provider that 
> is
> > marked with the MISC_SHARES_VIA_AGGREGATE trait.
> >
> > In other words, you need to do this:
> >
> > 1) Create the provider record for the thing that is going to share 
> the
> > CUSTOM_MAGIC resources
> >
> > 2) Create an inventory record on that provider
> >
> > 3) Set the MISC_SHARES_VIA_AGGREGATE trait on that provider
> >
> > 4) Create an aggregate
> >
> > 5) Associate both the above provider and the compute node provider
> > with
> > the aggregate
> >
> > That's it. The compute node provider will now have access to the
> > CUSTOM_MAGIC resources that the other provider has in inventory.
> 
> Something doesn't add up. We tried exactly your order of actions (see
> the script [1]) but placement returns an empty result (see the logs of
> the script[2], of the scheduler[3], of the placement[4]). However as
> soon as we add the MISC_SHARES_VIA_AGGREGATE trait to the compute
> provider as well then placement-api returns allocation candidates as
> expected.
> 
> We are trying to get some help from the related functional test [5] 
> but
> honestly we still need some time to digest that LOCs. So any direct
> help is appreciated.

I managed to create a functional test case that reproduces the above 
problem https://review.openstack.org/#/c/485088/

> 
> 
> BTW, should I open a bug for it?

I also filed a bug so that we can track this work 
https://bugs.launchpad.net/nova/+bug/1705071

Cheers,
gibi

> 
> 
> 
> As a related question. I looked at the claim in the scheduler patch
> https://review.openstack.org/#/c/483566 and I wondering if that patch
> wants to claim not just the resources a compute provider provides but
> also custom resources like MAGIC at [6]. In the meantime I will go and
> test that patch to see what it actually does with some MAGIC. :)
> 
> Thanks for the help!
> Cheers,
> gibi
> 
> [1] http://paste.openstack.org/show/615707/
> [2] http://paste.openstack.org/show/615708/
> [3] http://paste.openstack.org/show/615709/
> [4] http://paste.openstack.org/show/615710/
> [5]
> https://github.com/openstack/nova/blob/0e6cac5fde830f1de0ebdd4eebc130de1eb0198d/nova/tests/functional/db/test_resource_provider.py#L1969
> [6]
> https://review.openstack.org/#/c/483566/3/nova/scheduler/filter_scheduler.py@167
> >
> >
> > Magic. :)
> >
> > Best,
> > -jay
> >
> > > I updated my script with the trait. [3]
> > >
> > >>
> > >> It's quite likely this is not well documented yet as this style 
> of
> > >> declaring that something is shared was a later development. The
> > >> initial code that added the support for GET /resource_providers
> > >> was around, it was later reused for GET /allocation_candidates:
> > >>
> > >>     https://review.openstack.org/#/c/460798/
> > >
> > > What would be a good place to document this? I think I can help 
> with
> > > enhancing the documentation from this perspective.
> > >
> > > Thanks again.
> > > Cheers,
> > > gibi
> > >
> > >>
> > >> --
> > >> Chris Dent                  ┬──┬◡ﾉ(° -°ﾉ)
> > https://anticdent.org/
> > >> freenode: cdent                                         tw:
> > @anticdent
> > >
> > > [3] http://paste.openstack.org/show/615629/
> > >
> > >
> > >
> > >
> > >
> > 
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > 
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev