Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 10:01 PM, Jay Pipes  wrote:

> On 05/31/2017 01:31 AM, Zhenguo Niu wrote:
>
>> On Wed, May 31, 2017 at 12:20 PM, Ed Leafe  e...@leafe.com>> wrote:
>>
>> On May 30, 2017, at 9:36 PM, Zhenguo Niu > > 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: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Jay Pipes]

On 05/31/2017 01:31 AM, Zhenguo Niu wrote:
On Wed, May 31, 2017 at 12:20 PM, Ed Leafe > wrote:


On May 30, 2017, at 9:36 PM, Zhenguo Niu > 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...


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 12:20 PM, Ed Leafe  wrote:

> On May 30, 2017, at 9:36 PM, Zhenguo Niu  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.


>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Ed Leafe]

On May 30, 2017, at 9:36 PM, Zhenguo Niu  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.

-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 10:20 AM, Ed Leafe  wrote:

> On May 30, 2017, at 9:08 PM, Zhenguo Niu  wrote:
>
> > There would be a collision if nova and mogan consume the same ironic
> nodes cluster, as both of them will see all the available node resources.
> So if someone wants to choose mogan for baremetal compute management, the
> recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for
> VMs, this way we treat baremetals and vms as different compute resources.
> In a cloud with both vms and baremetals, it's more clear to have different
> set of APIs to manage them if users really care about what resources they
> got instead of just the performance. We also create a mogan horizon plugin
> which adds separated baremetal servers panel[1].
>
> So Mogan does not use the placement service for tracking resources?
>

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.


>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Ed Leafe]

On May 30, 2017, at 9:08 PM, Zhenguo Niu  wrote:

> There would be a collision if nova and mogan consume the same ironic nodes 
> cluster, as both of them will see all the available node resources. So if 
> someone wants to choose mogan for baremetal compute management, the 
> recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for 
> VMs, this way we treat baremetals and vms as different compute resources. In 
> a cloud with both vms and baremetals, it's more clear to have different set 
> of APIs to manage them if users really care about what resources they got 
> instead of just the performance. We also create a mogan horizon plugin which 
> adds separated baremetal servers panel[1].

So Mogan does not use the placement service for tracking resources?


-- Ed Leafe







signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

Thanks Ruby for bringing this up!

There would be a collision if nova and mogan consume the same ironic nodes
cluster, as both of them will see all the available node resources. So if
someone wants to choose mogan for baremetal compute management, the
recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for
VMs, this way we treat baremetals and vms as different compute resources.
In a cloud with both vms and baremetals, it's more clear to have different
set of APIs to manage them if users really care about what resources they
got instead of just the performance. We also create a mogan horizon plugin
which adds separated baremetal servers panel[1].

But for users who don't care whether it's a vm or baremetal server, they
just want to ask OpenStack for a specific flavor of compute resource to run
the workloads, it's definitely no need to deploy Mogan to separate
baremetals to a different compute resource to expose full baremetal
capabilities.


[1] https://pasteboard.co/cJ889Y7IA.png


On Mon, May 29, 2017 at 9:55 PM, Loo, Ruby  wrote:

> Hi Zhenguo (and others),
>
>
>
> is there a description/email thread/documentation about how mogan and nova
> co-exists in the same cloud? In particular, will it be possible for mogan
> and nova (with ironic driver) to run? Is this something that we will
> recommend or not recommend or not mention? Because I don't see how the end
> user will know to issue a mogan command to get a baremetal server, vs a
> nova-boot command to get a baremetal server. And/or does anyone envison
> that horizon will hide all that from the user somehow?
>
>
>
> --ruby
>
>
>
> *From: *Zhenguo Niu 
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" 
> *Date: *Thursday, May 25, 2017 at 10:41 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same
> keyword 'baremetal'?
>
>
>
> 
>
>
>
> As I understand, baremetal instance in nova is a 'specical virtual
> machine'(raw performance). Users claim the instance by specifying a flavor
> with 'vcpus', 'memory', "root_gb" instead of real hardware specs like (cpu
> model/cores, hard drives type/amount, nics type/amount), then he get an
> instance with properties like 'vm_state' and other 'virtual' stuff. As
> baremetal in nova use the same model and same set of API that designed for
> vms, so even for end users, it's not that easy to know which instance is a
> baremetal server, so maybe it's good to call that baremetal server a
> special vm instance.
>
>
>
> So, yes the end user actually know that there is a difference between
> getting a bremetal instance via mogan or via nova :)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Loo, Ruby]

Hi Zhenguo (and others),

is there a description/email thread/documentation about how mogan and nova 
co-exists in the same cloud? In particular, will it be possible for mogan and 
nova (with ironic driver) to run? Is this something that we will recommend or 
not recommend or not mention? Because I don't see how the end user will know to 
issue a mogan command to get a baremetal server, vs a nova-boot command to get 
a baremetal server. And/or does anyone envison that horizon will hide all that 
from the user somehow?

--ruby

From: Zhenguo Niu 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, May 25, 2017 at 10:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 
'baremetal'?



As I understand, baremetal instance in nova is a 'specical virtual machine'(raw 
performance). Users claim the instance by specifying a flavor with 'vcpus', 
'memory', "root_gb" instead of real hardware specs like (cpu model/cores, hard 
drives type/amount, nics type/amount), then he get an instance with properties 
like 'vm_state' and other 'virtual' stuff. As baremetal in nova use the same 
model and same set of API that designed for vms, so even for end users, it's 
not that easy to know which instance is a baremetal server, so maybe it's good 
to call that baremetal server a special vm instance.

So, yes the end user actually know that there is a difference between getting a 
bremetal instance via mogan or via nova :)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev