[ovirt-users] Re: Please don't remove instance type

[Michal Skrivanek]

> On 7 Mar 2019, at 10:43, Baptiste Agasse  
> wrote:
> 
> - Le 15 Fév 19, à 16:36, Michal Skrivanek  a 
> écrit :
> 
> 
> On 12 Feb 2019, at 22:21, Greg Sheremeta  > wrote:
> 
> Hi!
> 
> On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse 
> mailto:baptiste.aga...@lyra-network.com>> 
> wrote:
> Hi all,
> 
> We are happy oVirt users for some years now (we started with 3.6, now on 4.2) 
> and we manage most of our virtualization stacks with it. To provision and 
> manage our machines, we use the foreman (for bare metal and virtual machines) 
> on top of it. I made some little contributions to the foreman and other 
> underlying stuff to have a deeper integration with oVirt, like to be able to 
> select instance type directly from foreman interface/api and we rely on it. 
> We use instance types to standardize our vms by defining system resources 
> (memory, cpu and cpu topology) console type, boot options. On top of that we 
> plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having 
> resources definitions separated from OS installation help us to keep instance 
> types and templates lists small and don't bother users about some technical 
> underlying stuff. As we are interested in automating oVirt maintenance tasks 
> and configuration with ansible, I asked at FOSDEM oVirt booth if there is any 
> ansible module to manage instance types in Ovirt as I didn't find it in ovirt 
> ansible infra repo. The person to whom I asked the question said that you are 
> planning to remove instance types from ovirt, and this make me sad :(. So 
> here I am to ask why do you plan to remove instance types from oVirt. As far 
> as I know, it's fairly common to have "instance types" / "flavors" / "sizes" 
> on one side and then templates (bare OS, preinstalled appliances...) on other 
> side and pick one of each to make an instance. If this first part is missing 
> in future version of ovirt, it will be a pain point for us. So, my question 
> is, do you really plan to remove instances type definitely ?
> 
> I don't know the future plans (maybe someone else can comment), but I have 
> heard that instance types are barely used. You might be the first person I 
> know of who is using them.
> 
> The argument for keeping templates but removing instance types is probably 
> that templates already are effectively instance types. That's why I never use 
> them. For example, create a CentOS template with 16 CPUs, 32GB RAM, 500GB 
> disk ... that's effectively a large instance type. Create another template 
> with 1 CPU, 2GB RAM, 30GB disk ... that's effectively a small instance type.
> 
> Is there a use case beyond this that instance types provide that templates 
> don’t?
> 
> It was supposed to give better abstraction for hw, and more importantly 
> something you can change later on and it gets reflected in all VMs using that 
> type. Problem with that is that it got quite complex and we never really 
> found the right cut between what belongs to Instance and what to Template. It 
> works…but there are few corner cases here and there which are quite difficult 
> to fix. 
> 
> But no, we do not plan to remove them. It’s just in a deep maintenance mode 
> where we don’t really invest time to cover REST, ansible and all the bells 
> and whistles. If it works for you, great. If not and you would want to submit 
> a fix then please feel free to do so too.
> 
> Thanks,
> michal
> 
> Hi,
> 
> First, thank you both for your answers, and sorry for the delay. To be more 
> clear on how we use instance types and templates, we use it like our external 
> cloud providers use this kind of concepts:
> 
> * Templates is a pre-provisionned OS (and maybe one or more application 
> installed on top of it). Template needs storage space on storage domain(s) to 
> be stored. 
> * Instance types are "size" and other "metadata" applied to the template/VM 
> (eg: CPUs/Cores count, RAM size, headless VM, SPICE, or VNC ?, scsi support ? 
> HA ? ...). You can have a lot of "profiles" at "no cost" because it's just 
> configuration

yep, that was the idea for them. It’s just that not enough people expressed 
their interest in this feature…

> 
> IMHO, on our workload, as we have a limited set of templates but a lot of 
> different "sizes/types" of VMs. If instead of using instance types +  
> templates, we only use templates we will have a lot of templates with mostly 
> the same OSes/application preinstalled on it and the maintenance/storage 
> costs will be a lot greater than today. For some corner cases, we also have 
> "non templated" VMs and we apply instance type to it too (we enforce that any 
> VM, build from template or not on our clusters have an instance type applied 
> to it)
> 
> We are greatly interested in ansible modules to maintain and configure our 
> multiple oVirt stacks. I know that you will not invest time in providing 
> ansible module for instance types as you said that part of ovirt is in

[ovirt-users] Re: Please don't remove instance type

[Baptiste Agasse]

- Le 15 Fév 19, à 16:36, Michal Skrivanek  a 
écrit : 





BQ_BEGIN

On 12 Feb 2019, at 22:21, Greg Sheremeta < [ mailto:gsher...@redhat.com | 
gsher...@redhat.com ] > wrote: 

Hi! 

On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse < [ 
mailto:baptiste.aga...@lyra-network.com | baptiste.aga...@lyra-network.com ] > 
wrote: 

BQ_BEGIN
Hi all, 

We are happy oVirt users for some years now (we started with 3.6, now on 4.2) 
and we manage most of our virtualization stacks with it. To provision and 
manage our machines, we use the foreman (for bare metal and virtual machines) 
on top of it. I made some little contributions to the foreman and other 
underlying stuff to have a deeper integration with oVirt, like to be able to 
select instance type directly from foreman interface/api and we rely on it. We 
use instance types to standardize our vms by defining system resources (memory, 
cpu and cpu topology) console type, boot options. On top of that we plan to use 
templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources 
definitions separated from OS installation help us to keep instance types and 
templates lists small and don't bother users about some technical underlying 
stuff. As we are interested in automating oVirt maintenance tasks and 
configuration with ansible, I asked at FOSDEM oVirt booth if there is any 
ansible module to manage instance types in Ovirt as I didn't find it in ovirt 
ansible infra repo. The person to whom I asked the question said that you are 
planning to remove instance types from ovirt, and this make me sad :(. So here 
I am to ask why do you plan to remove instance types from oVirt. As far as I 
know, it's fairly common to have "instance types" / "flavors" / "sizes" on one 
side and then templates (bare OS, preinstalled appliances...) on other side and 
pick one of each to make an instance. If this first part is missing in future 
version of ovirt, it will be a pain point for us. So, my question is, do you 
really plan to remove instances type definitely ? 




I don't know the future plans (maybe someone else can comment), but I have 
heard that instance types are barely used. You might be the first person I know 
of who is using them. 

The argument for keeping templates but removing instance types is probably that 
templates already are effectively instance types. That's why I never use them. 
For example, create a CentOS template with 16 CPUs, 32GB RAM, 500GB disk ... 
that's effectively a large instance type. Create another template with 1 CPU, 
2GB RAM, 30GB disk ... that's effectively a small instance type. 

Is there a use case beyond this that instance types provide that templates 
don’t? 

BQ_END


It was supposed to give better abstraction for hw, and more importantly 
something you can change later on and it gets reflected in all VMs using that 
type. Problem with that is that it got quite complex and we never really found 
the right cut between what belongs to Instance and what to Template. It 
works…but there are few corner cases here and there which are quite difficult 
to fix. 

But no, we do not plan to remove them. It’s just in a deep maintenance mode 
where we don’t really invest time to cover REST, ansible and all the bells and 
whistles. If it works for you, great. If not and you would want to submit a fix 
then please feel free to do so too. 

Thanks, 
michal 

BQ_END

Hi, 

First, thank you both for your answers, and sorry for the delay. To be more 
clear on how we use instance types and templates, we use it like our external 
cloud providers use this kind of concepts: 

* Templates is a pre-provisionned OS (and maybe one or more application 
installed on top of it). Template needs storage space on storage domain(s) to 
be stored. 
* Instance types are "size" and other "metadata" applied to the template/VM 
(eg: CPUs/Cores count, RAM size, headless VM, SPICE, or VNC ?, scsi support ? 
HA ? ...). You can have a lot of "profiles" at "no cost" because it's just 
configuration 

IMHO, on our workload, as we have a limited set of templates but a lot of 
different "sizes/types" of VMs. If instead of using instance types + templates, 
we only use templates we will have a lot of templates with mostly the same 
OSes/application preinstalled on it and the maintenance/storage costs will be a 
lot greater than today. For some corner cases, we also have "non templated" VMs 
and we apply instance type to it too (we enforce that any VM, build from 
template or not on our clusters have an instance type applied to it) 

We are greatly interested in ansible modules to maintain and configure our 
multiple oVirt stacks. I know that you will not invest time in providing 
ansible module for instance types as you said that part of ovirt is in 
maintenance mode, but contribution are welcome on this part (I saw that the SDK 
already cover it) ? 

Have a nice day. 

Cheers. 



BQ_BEGIN


BQ_BEGIN


Best wishes, 
Greg 

BQ_BEGIN

Cheers. 

-- 
Baptiste 

[ovirt-users] Re: Please don't remove instance type

[Michal Skrivanek]

> On 12 Feb 2019, at 22:21, Greg Sheremeta  wrote:
> 
> Hi!
> 
> On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse 
> mailto:baptiste.aga...@lyra-network.com>> 
> wrote:
> Hi all,
> 
> We are happy oVirt users for some years now (we started with 3.6, now on 4.2) 
> and we manage most of our virtualization stacks with it. To provision and 
> manage our machines, we use the foreman (for bare metal and virtual machines) 
> on top of it. I made some little contributions to the foreman and other 
> underlying stuff to have a deeper integration with oVirt, like to be able to 
> select instance type directly from foreman interface/api and we rely on it. 
> We use instance types to standardize our vms by defining system resources 
> (memory, cpu and cpu topology) console type, boot options. On top of that we 
> plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having 
> resources definitions separated from OS installation help us to keep instance 
> types and templates lists small and don't bother users about some technical 
> underlying stuff. As we are interested in automating oVirt maintenance tasks 
> and configuration with ansible, I asked at FOSDEM oVirt booth if there is any 
> ansible module to manage instance types in Ovirt as I didn't find it in ovirt 
> ansible infra repo. The person to whom I asked the question said that you are 
> planning to remove instance types from ovirt, and this make me sad :(. So 
> here I am to ask why do you plan to remove instance types from oVirt. As far 
> as I know, it's fairly common to have "instance types" / "flavors" / "sizes" 
> on one side and then templates (bare OS, preinstalled appliances...) on other 
> side and pick one of each to make an instance. If this first part is missing 
> in future version of ovirt, it will be a pain point for us. So, my question 
> is, do you really plan to remove instances type definitely ?
> 
> I don't know the future plans (maybe someone else can comment), but I have 
> heard that instance types are barely used. You might be the first person I 
> know of who is using them.
> 
> The argument for keeping templates but removing instance types is probably 
> that templates already are effectively instance types. That's why I never use 
> them. For example, create a CentOS template with 16 CPUs, 32GB RAM, 500GB 
> disk ... that's effectively a large instance type. Create another template 
> with 1 CPU, 2GB RAM, 30GB disk ... that's effectively a small instance type.
> 
> Is there a use case beyond this that instance types provide that templates 
> don’t?

It was supposed to give better abstraction for hw, and more importantly 
something you can change later on and it gets reflected in all VMs using that 
type. Problem with that is that it got quite complex and we never really found 
the right cut between what belongs to Instance and what to Template. It 
works…but there are few corner cases here and there which are quite difficult 
to fix. 

But no, we do not plan to remove them. It’s just in a deep maintenance mode 
where we don’t really invest time to cover REST, ansible and all the bells and 
whistles. If it works for you, great. If not and you would want to submit a fix 
then please feel free to do so too.

Thanks,
michal

> 
> Best wishes,
> Greg
>  
> 
> Cheers.
> 
> -- 
> Baptiste
> ___
> Users mailing list -- users@ovirt.org 
> To unsubscribe send an email to users-le...@ovirt.org 
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ 
> 
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/ 
> 
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/
>  
> 
> 
> 
> -- 
> GREG SHEREMETA
> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX
> Red Hat NA
> 
>  
> gsher...@redhat.com IRC: gshereme
> 
>  ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/K7ASUHKQUOGH7SFCDK3LHBLILNR4ITC7/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users

[ovirt-users] Re: Please don't remove instance type

[Greg Sheremeta]

Hi!

On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse <
baptiste.aga...@lyra-network.com> wrote:

> Hi all,
>
> We are happy oVirt users for some years now (we started with 3.6, now on
> 4.2) and we manage most of our virtualization stacks with it. To provision
> and manage our machines, we use the foreman (for bare metal and virtual
> machines) on top of it. I made some little contributions to the foreman and
> other underlying stuff to have a deeper integration with oVirt, like to be
> able to select instance type directly from foreman interface/api and we
> rely on it. We use instance types to standardize our vms by defining system
> resources (memory, cpu and cpu topology) console type, boot options. On top
> of that we plan to use templates to apply OS (CentOS 7 and CentOS 6
> actually). Having resources definitions separated from OS installation help
> us to keep instance types and templates lists small and don't bother users
> about some technical underlying stuff. As we are interested in automating
> oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM
> oVirt booth if there is any ansible module to manage instance types in
> Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I
> asked the question said that you are planning to remove instance types from
> ovirt, and this make me sad :(. So here I am to ask why do you plan to
> remove instance types from oVirt. As far as I know, it's fairly common to
> have "instance types" / "flavors" / "sizes" on one side and then templates
> (bare OS, preinstalled appliances...) on other side and pick one of each to
> make an instance. If this first part is missing in future version of ovirt,
> it will be a pain point for us. So, my question is, do you really plan to
> remove instances type definitely ?
>

I don't know the future plans (maybe someone else can comment), but I have
heard that instance types are barely used. You might be the first person I
know of who is using them.

The argument for keeping templates but removing instance types is probably
that templates already are effectively instance types. That's why I never
use them. For example, create a CentOS template with 16 CPUs, 32GB RAM,
500GB disk ... that's effectively a large instance type. Create another
template with 1 CPU, 2GB RAM, 30GB disk ... that's effectively a small
instance type.

Is there a use case beyond this that instance types provide that templates
don't?

Best wishes,
Greg


>
> Cheers.
>
> --
> Baptiste
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/
>


-- 

GREG SHEREMETA

SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX

Red Hat NA



gsher...@redhat.comIRC: gshereme

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/K7ASUHKQUOGH7SFCDK3LHBLILNR4ITC7/