> On 7 Mar 2019, at 10:43, Baptiste Agasse <[email protected]> > wrote: > > ----- Le 15 Fév 19, à 16:36, Michal Skrivanek <[email protected]> a > écrit : > > > On 12 Feb 2019, at 22:21, Greg Sheremeta <[email protected] > <mailto:[email protected]>> wrote: > > Hi! > > On Sat, Feb 2, 2019 at 1:35 PM Baptiste Agasse > <[email protected] <mailto:[email protected]>> > 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 > maintenance mode, but contribution are welcome on this part (I saw that the > SDK already cover it) ? of course! Ansible modules are all on ansible’s github. REST API is in oVirt sub projects. Do you currently miss anything in REST API? All I can see is that an ansible module specifically for instance types management doesn’t exist, but other than that it should be covered (e.g. [1] for VM creation flow) Thanks, michal [1] https://github.com/ansible/ansible/blob/ce9fc9b9120d692f674b693c68d63a2f3732f627/lib/ansible/modules/cloud/ovirt/ovirt_vm.py#L388 > > Have a nice day. > > Cheers. > > > > Best wishes, > Greg > > Cheers. > > -- > Baptiste > _______________________________________________ > Users mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > <https://www.ovirt.org/site/privacy-policy/> > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: > https://lists.ovirt.org/archives/list/[email protected]/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/ > > <https://lists.ovirt.org/archives/list/[email protected]/message/TJAXYBMSIAAAYLAYCSLOTONY54WT7K3O/> > > > -- > GREG SHEREMETA > SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX > Red Hat NA > > <https://www.redhat.com/> > [email protected] <mailto:[email protected]> IRC: gshereme > > <https://red.ht/sig> > _______________________________________________ > Users mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > <https://www.ovirt.org/site/privacy-policy/> > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: > https://lists.ovirt.org/archives/list/[email protected]/message/K7ASUHKQUOGH7SFCDK3LHBLILNR4ITC7/ > > <https://lists.ovirt.org/archives/list/[email protected]/message/K7ASUHKQUOGH7SFCDK3LHBLILNR4ITC7/> > > > > -- > Baptiste >
_______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/6VGX46WUWARMKHYLK52LEL2DTB4OQXBG/
