On Wed, May 31, 2017 at 10:01 PM, Jay Pipes <[email protected]> wrote:

> On 05/31/2017 01:31 AM, Zhenguo Niu wrote:
>
>> On Wed, May 31, 2017 at 12:20 PM, Ed Leafe <[email protected] <mailto:
>> [email protected]>> wrote:
>>
>>     On May 30, 2017, at 9:36 PM, Zhenguo Niu <[email protected]
>>     <mailto:[email protected]>> wrote:
>>
>>     > as placement is not splitted out from nova now, and there would be
>> users who only want a baremetal cloud, so we don't add resources to
>> placement yet, but it's easy for us to turn to placement to match the node
>> type with mogan flavors.
>>
>>     Placement is a separate service, independent of Nova. It tracks
>>     Ironic nodes as individual resources, not as a "pretend" VM. The
>>     Nova integration for selecting an Ironic node as a resource is still
>>     being developed, as we need to update our view of the mess that is
>>     "flavors", but the goal is to have a single flavor for each Ironic
>>     machine type, rather than the current state of flavors pretending
>>     that an Ironic node is a VM with certain RAM/CPU/disk quantities.
>>
>>
>> Yes, I understand the current efforts of improving the baremetal nodes
>> scheduling. It's not conflict with mogan's goal, and when it is done, we
>> can share the same scheduling strategy with placement :)
>>
>> Mogan is a service for a specific group of users who really want a
>> baremetal resource instead of a generic compute resource, on API side, we
>> can expose RAID, advanced partitions, nics bonding, firmware management,
>> and other baremetal specific capabilities to users. And unlike nova's host
>> based availability zone, host aggregates, server groups (ironic nodes share
>> the same host), mogan can make it possible to divide baremetal nodes into
>> such groups, and make Rack aware for affinity and anti-affinity when
>> scheduling.
>>
> Zhenguo Niu brings up a very good point here. Currently, all Ironic nodes
> are associated with a single host aggregate in Nova, because of the
> vestigial notion that a compute *service* (ala the nova-compute worker) was
> equal to the compute *node*.
>
> In the placement API, of course, there's no such coupling. A placement
> aggregate != a Nova host aggregate.
>
> So, technically Ironic (or Mogan) can call the placement service to create
> aggregates that match *its* definition of what an aggregate is (rack, row,
> cage, zone, DC, whatever). Furthermore, Ironic (or Mogan) can associate
> Ironic baremetal nodes to one or more of those placement aggregates to get
> around Nova host aggregate to compute service coupling.
>
> That said, there's still lots of missing pieces before placement gets
> affinity/anti-affinity support...
>

Thanks Jay, we are also considering how to leverage the placement
aggregates, and if possible, we would like to contribute in this part to
make placement work well for mogan :)


>
> Best,
> -jay
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [email protected]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Best Regards,
Zhenguo Niu
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to