Re: [one-users] Adding test system datastore

[Carlos Martín Sánchez]

On Thu, Feb 20, 2014 at 3:24 PM, Stefan Kooman  wrote:

> Quoting Carlos Martín Sánchez (cmar...@opennebula.org):
>
> > > At the moment the multi DS support is configured at template level.
> From a
> > > "system" perspective it would be nice to be able to control which
> > > datastore gets used. For example filter on user, group, vm template
> > > attributes, etc. At least we have a use case for this (seperate "Qtree"
> > > per datastore for IO billing). It proably makes the scheduler's life
> > > more complicated :(.
> >
> >
> > So, basically adding ACL rules to grant deployment rights for each system
> > DS, right?
>
> Yes, that would do the trick.
>
> Gr. Stefan
>

Ticket created:
http://dev.opennebula.org/issues/2742

Keep an eye on it, and remind us in the next roadmap planning ;)
--
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org  | cmar...@opennebula.org |
@OpenNebula  
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Stefan Kooman]

Quoting Carlos Martín Sánchez (cmar...@opennebula.org):
 
> > At the moment the multi DS support is configured at template level. From a
> > "system" perspective it would be nice to be able to control which
> > datastore gets used. For example filter on user, group, vm template
> > attributes, etc. At least we have a use case for this (seperate "Qtree"
> > per datastore for IO billing). It proably makes the scheduler's life
> > more complicated :(.
> 
> 
> So, basically adding ACL rules to grant deployment rights for each system
> DS, right?

Yes, that would do the trick. 

Gr. Stefan

-- 
| BIT BV  http://www.bit.nl/Kamer van Koophandel 09090351
| GPG: 0xD14839C6   +31 318 648 688 / i...@bit.nl
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Carlos Martín Sánchez]

Hi,

On Tue, Feb 18, 2014 at 5:47 PM, Daniel Dehennin <
daniel.dehen...@baby-gnu.org> wrote:
>
>
> Am'I right about group and resource providers?
>

The resource providers makes easier to assign clusters to groups, see [1]
for a screencast of the new functionality.
But in this case it will only help if he new system DS is in a different
cluster, which means it won't be able to work with the existing hosts...

Regards

[1]
http://opennebula.org/partitioning-clouds-with-virtual-data-centers-vdcs/
--
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org  | cmar...@opennebula.org |
@OpenNebula  
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Carlos Martín Sánchez]

On Tue, Feb 18, 2014 at 4:42 PM, Stefan Kooman  wrote:

> Quoting Carlos Martín Sánchez (cmar...@opennebula.org):
> > Hi there,
> >
> > Maybe we could try to replicate the 'onehost disable' behaviour.
> > That is, a disabled system DS would be ignored by the scheduler, but you
> > can still deploy VMs manually there.
>
> I think this would support Daniel's use case. But how do you deploy a VM
> manually? I.e how do you by-pass the scheduler (except by creating a
> "WILD" vm)?
>

You can use the onevm deploy command, or the sunstone button.
To avoid the scheduler being quicker than you, pending VMs can be put on
hold. Or use the onetemplate instantiate --hold option.


> At the moment the multi DS support is configured at template level. From a
> "system" perspective it would be nice to be able to control which
> datastore gets used. For example filter on user, group, vm template
> attributes, etc. At least we have a use case for this (seperate "Qtree"
> per datastore for IO billing). It proably makes the scheduler's life
> more complicated :(.


So, basically adding ACL rules to grant deployment rights for each system
DS, right?


>  > What do you think? Should I open a ticket for this?
>
> Yes, it's definitely useful.
>

Done:
http://dev.opennebula.org/issues/2738

 --
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org  | cmar...@opennebula.org |
@OpenNebula  
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Daniel Dehennin]

Carlos Martín Sánchez  writes:

> Hi there,
>
> Maybe we could try to replicate the 'onehost disable' behaviour.
> That is, a disabled system DS would be ignored by the scheduler, but you
> can still deploy VMs manually there.
>
> What do you think? Should I open a ticket for this?

Am'I right about group and resource providers?

If yes, disabling a DS is not useful for my usecase.

But remains interesting for general cluster management, for example if
something goes wrong with the backend, system DS could be disabled and
VMs restarted to use another one.

Regards.
-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Stefan Kooman]

Quoting Carlos Martín Sánchez (cmar...@opennebula.org):
> Hi there,
> 
> Maybe we could try to replicate the 'onehost disable' behaviour.
> That is, a disabled system DS would be ignored by the scheduler, but you
> can still deploy VMs manually there.

I think this would support Daniel's use case. But how do you deploy a VM
manually? I.e how do you by-pass the scheduler (except by creating a
"WILD" vm)? 

At the moment the multi DS support is configured at template level. From a
"system" perspective it would be nice to be able to control which
datastore gets used. For example filter on user, group, vm template
attributes, etc. At least we have a use case for this (seperate "Qtree"
per datastore for IO billing). It proably makes the scheduler's life
more complicated :(.

> What do you think? Should I open a ticket for this?

Yes, it's definitely useful.

Gr. Stefan

-- 
| BIT BV  http://www.bit.nl/Kamer van Koophandel 09090351
| GPG: 0xD14839C6   +31 318 648 688 / i...@bit.nl
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Carlos Martín Sánchez]

Hi there,

Maybe we could try to replicate the 'onehost disable' behaviour.
That is, a disabled system DS would be ignored by the scheduler, but you
can still deploy VMs manually there.

What do you think? Should I open a ticket for this?

Regards

--
Carlos Martín, MSc
Project Engineer
OpenNebula - Flexible Enterprise Cloud Made Simple
www.OpenNebula.org | cmar...@opennebula.org |
@OpenNebula


On Mon, Feb 17, 2014 at 4:52 PM, Stefan Kooman  wrote:

> Quoting Daniel Dehennin (daniel.dehen...@baby-gnu.org):
> > Stefan Kooman  writes:
> >
> >
> > [...]
> >
> > > You can, in your vm template you can put the following:
> > >
> > > SCHED_DS_REQUIREMENTS="NAME=NAMEOFYOURTESTDATASTORE". All other DS'es
> > > will be filtered out.
> >
> > This will force a VM to use this one when it have this
> > SCHED_DS_REQUIREMENTS, but what about all other VMs which do not have
> > any requirements set?
> >
> > As far as I understand, they will use it too.
>
> They might use it. It depends on the policy set on the DS (packing,
> striping or custom) [1]. You have to set the requirement on each and
> every vm (template) to make sure they end up in the correct datastore.
> See sched.log to see what priorities your datastores end up with. Our
> datastores end up with the same priority and the first one in the list
> gets chosen.
>
> Gr. Stefan
>
> [1]:
>
> http://docs.opennebula.org/stable/administration/storage/system_ds.html?highlight=system%20datastores
>
> >
> >
> > [...]
> >
> > > Actually I was looking for this as well :). For example I would like to
> > > be able to "link" certain datastores to "groups", i.e. use datastore A
> > > for group A by default instead of having it defined in every single
> > > template. If users of group A have the possibility to define their own
> > > templates and they would forget the "SCHED_DS_REQUIREMENTS" to their
> > > datastore it would end up somewhere else (if at least they have enough
> > > rights on other (system) datastores). Basically it would be nice to
> have
> > > even more filtering capabitilites to ensure correct
> > > placement/deployment.
> >
> > If I remember correctly, I heard about some group and resource providers
> > mechanisms for 4.6, it may address this.
> >
> > Regards.
> >
> > --
> > Daniel Dehennin
> > Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
> > Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF
>
>
>
> > ___
> > Users mailing list
> > Users@lists.opennebula.org
> > http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
> --
> | BIT BV  http://www.bit.nl/Kamer van Koophandel 09090351
> | GPG: 0xD14839C6   +31 318 648 688 / i...@bit.nl
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iF4EAREIAAYFAlMCMEoACgkQTyGgYdFIOcbqOwEAjnynlt3OOcgnm+c4FoVA22uj
> q6mKLNQ4iW5QqaGthhcBAJxYt3gkqWRP3iXV/rPME0/Bq/ZOm8UVpEa9PEqIBO7h
> =tDzh
> -END PGP SIGNATURE-
>
> ___
> Users mailing list
> Users@lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Stefan Kooman]

Quoting Daniel Dehennin (daniel.dehen...@baby-gnu.org):
> Stefan Kooman  writes:
> 
> 
> [...]
> 
> > You can, in your vm template you can put the following:
> >
> > SCHED_DS_REQUIREMENTS="NAME=NAMEOFYOURTESTDATASTORE". All other DS'es
> > will be filtered out.
> 
> This will force a VM to use this one when it have this
> SCHED_DS_REQUIREMENTS, but what about all other VMs which do not have
> any requirements set?
> 
> As far as I understand, they will use it too.

They might use it. It depends on the policy set on the DS (packing,
striping or custom) [1]. You have to set the requirement on each and
every vm (template) to make sure they end up in the correct datastore.
See sched.log to see what priorities your datastores end up with. Our
datastores end up with the same priority and the first one in the list
gets chosen.

Gr. Stefan

[1]:
http://docs.opennebula.org/stable/administration/storage/system_ds.html?highlight=system%20datastores

> 
> 
> [...]
> 
> > Actually I was looking for this as well :). For example I would like to
> > be able to "link" certain datastores to "groups", i.e. use datastore A
> > for group A by default instead of having it defined in every single
> > template. If users of group A have the possibility to define their own
> > templates and they would forget the "SCHED_DS_REQUIREMENTS" to their
> > datastore it would end up somewhere else (if at least they have enough
> > rights on other (system) datastores). Basically it would be nice to have
> > even more filtering capabitilites to ensure correct
> > placement/deployment.
> 
> If I remember correctly, I heard about some group and resource providers
> mechanisms for 4.6, it may address this.
> 
> Regards.
> 
> -- 
> Daniel Dehennin
> Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
> Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF



> ___
> Users mailing list
> Users@lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org


-- 
| BIT BV  http://www.bit.nl/Kamer van Koophandel 09090351
| GPG: 0xD14839C6   +31 318 648 688 / i...@bit.nl


signature.asc
Description: Digital signature
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Daniel Dehennin]

Stefan Kooman  writes:


[...]

> You can, in your vm template you can put the following:
>
> SCHED_DS_REQUIREMENTS="NAME=NAMEOFYOURTESTDATASTORE". All other DS'es
> will be filtered out.

This will force a VM to use this one when it have this
SCHED_DS_REQUIREMENTS, but what about all other VMs which do not have
any requirements set?

As far as I understand, they will use it too.


[...]

> Actually I was looking for this as well :). For example I would like to
> be able to "link" certain datastores to "groups", i.e. use datastore A
> for group A by default instead of having it defined in every single
> template. If users of group A have the possibility to define their own
> templates and they would forget the "SCHED_DS_REQUIREMENTS" to their
> datastore it would end up somewhere else (if at least they have enough
> rights on other (system) datastores). Basically it would be nice to have
> even more filtering capabitilites to ensure correct
> placement/deployment.

If I remember correctly, I heard about some group and resource providers
mechanisms for 4.6, it may address this.

Regards.

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF


signature.asc
Description: PGP signature
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

Re: [one-users] Adding test system datastore

[Stefan Kooman]

Quoting Daniel Dehennin (daniel.dehen...@baby-gnu.org):
> Hello,
> 
> I would like to add a new system datastore to make some tests on my ONE
> 4.2 cluster.
> 
> My problem is that it will be automatically used when added to my
> cluster.
> 
> I would like to define some requirements to make it selectable only for
> specific VM.

You can, in your vm template you can put the following:

SCHED_DS_REQUIREMENTS="NAME=NAMEOFYOURTESTDATASTORE". All other DS'es
will be filtered out.
> 
> Is there a way to mark a system datastore to not be used by default,
> except for template with the “good” requirements?

Actually I was looking for this as well :). For example I would like to
be able to "link" certain datastores to "groups", i.e. use datastore A
for group A by default instead of having it defined in every single
template. If users of group A have the possibility to define their own
templates and they would forget the "SCHED_DS_REQUIREMENTS" to their
datastore it would end up somewhere else (if at least they have enough
rights on other (system) datastores). Basically it would be nice to have
even more filtering capabitilites to ensure correct
placement/deployment.

Gr. Stefan


-- 
| BIT BV  http://www.bit.nl/Kamer van Koophandel 09090351
| GPG: 0xD14839C6   +31 318 648 688 / i...@bit.nl


signature.asc
Description: Digital signature
___
Users mailing list
Users@lists.opennebula.org
http://lists.opennebula.org/listinfo.cgi/users-opennebula.org