Re: [openstack-dev] [Murano] Image tagging
I would also suggest to look at Graffiti
https://wiki.openstack.org/wiki/Graffiti project, I think Graffiti is
designed to solve problems related to our with images however I don't know
how well it is fit for us. They work very hard to make project
functionality available as part https://review.openstack.org/98554 of
Glance.
If it's really can solve our problem we can design solution that expose
functionality compatible in capabilities with Graffiti and have limited
short-term implementation that eventually can be replaced by Glance
[with *Metadata
Definitions Catalog* feature].
On Wed, Jul 23, 2014 at 1:52 AM, Stan Lagun sla...@mirantis.com wrote:
How do you like alternate design: uses can chose any image he wants (say
any Linux) but the JSON that is in image tag has enough information on what
applications are installed on that image. And not just installed or not but
the exact state installation was frozen (say binaries are deployed but
config files are need to be modified). The deployment workflow can peak
that state from image tag and continue right from the place it was stopped
last time. So if user has chosen image with MySQL preinstalled the workflow
will just post-configure it while if the user chosen clean Linux image it
will do the whole deployment from scratch. Thus it will become only a
matter of optimization and user will still be able to to share instance for
several applications (good example is Firewall app) or deploy his app even
if there is no image where it was built in.
Those are only my thoughts and this need a proper design. For now I agree
that we need to improve tagging to support yours use case. But this need to
be done in a way that would allow both user and machine to work with. UI at
least needs to distinguish between Linux and Windows while for user a
free-form tagging may be appropriate. Both can be stored in a single JSON
tag.
So lets create blueprint/etherpad for this and both think on exact format
that can be implemented right now
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
sla...@mirantis.com
On Tue, Jul 22, 2014 at 10:08 PM, McLellan, Steven steve.mclel...@hp.com
wrote:
Thanks for the response.
Primarily I’m thinking about a situation where I have an image that has a
specific piece of software installed (let’s say MySQL for the sake of
argument). My application (which configures mysql) requires a glance image
that has MySQL pre-installed, and doesn’t particularly care what OS (though
again for the sake of argument assume it’s linux of some kind, so that
configuration files are expected to be in the same place regardless of OS).
Currently we have a list of three hardcoded values in the UI, and none of
them apply properly. I’m suggesting instead of that list, we allow
free-form text; if you’re tagging glance images, you are expected to know
what applications will be looking for. This still leaves a problem in that
I can upload a package but I don’t necessarily have the ability to mark any
images as valid for it, but I think that can be a later evolution; for now,
I’m focusing on the situation where an admin is both uploading glance
images and murano packages.
As a slight side note, we do have the ability to filter image sizes based
on glance properties (RAM, cpus), but this is in the UI code, not enforced
at the contractual level. I agree reengineering some of this to be at the
contract level is a good goal, but it seems like that would involve major
reengineering of the dashboard to make it much dumber and go through the
murano API for everything (which ultimately is probably a good thing).
*From:* Stan Lagun [mailto:sla...@mirantis.com]
*Sent:* Sunday, July 20, 2014 5:42 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Murano] Image tagging
Hi!
I think it would be usefull to share the original vision on tagging that
we had back in 0.4 era when it was introduced.
Tagging was supposed to be JSON image metadata with extendable scheme.
Workflow should be able to both utilize that metadata and impose some
constraints on it. That feature was never really designed so I cannot tell
exactly how this JSON should work or look like. As far as I see it it can
contain:
1. Operating system information. For example os: { family: Linux,
name: Ubuntu, version: 12.04, arch: x86_x64 } (this also may be
encoded as a single string)
Workflows (MuranoPL contracts) need to be able to express
requirements based on those attributes. For example
image:
Contract($.class(Image).check($.family = Linux and $.arch = x86)
In UI only those images that matches such contract should be displayed.
2. Human readable image title Ubuntu Linux 12.04 x86
3. Information about built-in software for image-based deployment. Not
sure exactly what information is needed. Meybe even portion of Object Model
so
Re: [openstack-dev] [Murano] Image tagging
Thanks for the response.
Primarily I’m thinking about a situation where I have an image that has a
specific piece of software installed (let’s say MySQL for the sake of
argument). My application (which configures mysql) requires a glance image that
has MySQL pre-installed, and doesn’t particularly care what OS (though again
for the sake of argument assume it’s linux of some kind, so that configuration
files are expected to be in the same place regardless of OS).
Currently we have a list of three hardcoded values in the UI, and none of them
apply properly. I’m suggesting instead of that list, we allow free-form text;
if you’re tagging glance images, you are expected to know what applications
will be looking for. This still leaves a problem in that I can upload a package
but I don’t necessarily have the ability to mark any images as valid for it,
but I think that can be a later evolution; for now, I’m focusing on the
situation where an admin is both uploading glance images and murano packages.
As a slight side note, we do have the ability to filter image sizes based on
glance properties (RAM, cpus), but this is in the UI code, not enforced at the
contractual level. I agree reengineering some of this to be at the contract
level is a good goal, but it seems like that would involve major reengineering
of the dashboard to make it much dumber and go through the murano API for
everything (which ultimately is probably a good thing).
From: Stan Lagun [mailto:sla...@mirantis.com]
Sent: Sunday, July 20, 2014 5:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Murano] Image tagging
Hi!
I think it would be usefull to share the original vision on tagging that we had
back in 0.4 era when it was introduced.
Tagging was supposed to be JSON image metadata with extendable scheme. Workflow
should be able to both utilize that metadata and impose some constraints on it.
That feature was never really designed so I cannot tell exactly how this JSON
should work or look like. As far as I see it it can contain:
1. Operating system information. For example os: { family: Linux, name:
Ubuntu, version: 12.04, arch: x86_x64 } (this also may be encoded as
a single string)
Workflows (MuranoPL contracts) need to be able to express requirements
based on those attributes. For example
image:
Contract($.class(Image).check($.family = Linux and $.arch = x86)
In UI only those images that matches such contract should be displayed.
2. Human readable image title Ubuntu Linux 12.04 x86
3. Information about built-in software for image-based deployment. Not sure
exactly what information is needed. Meybe even portion of Object Model so that
if such image is used Murano environment will automatically recocnize and
incorporate that application like it was added by user to be installed on clean
instance. This will allow using of pre-build images with preinstalled software
(e.g. speed up deployment) but will make it transparent for the user so that
this software could be managed as well as applications that user choses to
install
4. Minimal hardware requirement for the image. Murano could use that
information to guarantee that user will not select flavor that is too small for
that operating system.
5. General-purposed tags
We need to think how this concept fits into our roadmap and new Glance design
(probably there are other projects that can benefit from extended image
metadata) before chosing one of your approaches
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
On Fri, Jul 18, 2014 at 6:46 PM, McLellan, Steven
steve.mclel...@hp.commailto:steve.mclel...@hp.com wrote:
Hi,
Images that can be used for package deployment have to be tagged in glance in
order to enable the UI to filter the list of images to present to a user (and
potentially preselect). Currently the tags are defined in the dashboard code
(images/forms.py) which makes things very inflexible; if I can upload an image
and a package that consumes that image, I don’t want to have to make a code
change to use it.
Anyone who can upload images should also be able to specify tags for them.
There is also the question of whether a user should be allowed to tag images
that don’t belong to them (e.g. a shared image used by a private package), but
I think that can be punted down the road somewhat.
I think this needs to be more dynamic, and if that’s agreed upon, there are a
couple of approaches:
1) Store allowed tags in the database, and allow administrators to add to
that list. Ordinary users would likely not be able to create tags, though they
could use pre-defined ones for images they owned.
2) Have some public tags, but also allow user-specified tags for private
packages. I think this leads to all sorts of tricky edge cases
3) Allow freeform tags (i.e. don’t provide any hints). Since there’s no
formal link between the tag
Re: [openstack-dev] [Murano] Image tagging
How do you like alternate design: uses can chose any image he wants (say
any Linux) but the JSON that is in image tag has enough information on what
applications are installed on that image. And not just installed or not but
the exact state installation was frozen (say binaries are deployed but
config files are need to be modified). The deployment workflow can peak
that state from image tag and continue right from the place it was stopped
last time. So if user has chosen image with MySQL preinstalled the workflow
will just post-configure it while if the user chosen clean Linux image it
will do the whole deployment from scratch. Thus it will become only a
matter of optimization and user will still be able to to share instance for
several applications (good example is Firewall app) or deploy his app even
if there is no image where it was built in.
Those are only my thoughts and this need a proper design. For now I agree
that we need to improve tagging to support yours use case. But this need to
be done in a way that would allow both user and machine to work with. UI at
least needs to distinguish between Linux and Windows while for user a
free-form tagging may be appropriate. Both can be stored in a single JSON
tag.
So lets create blueprint/etherpad for this and both think on exact format
that can be implemented right now
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
sla...@mirantis.com
On Tue, Jul 22, 2014 at 10:08 PM, McLellan, Steven steve.mclel...@hp.com
wrote:
Thanks for the response.
Primarily I’m thinking about a situation where I have an image that has a
specific piece of software installed (let’s say MySQL for the sake of
argument). My application (which configures mysql) requires a glance image
that has MySQL pre-installed, and doesn’t particularly care what OS (though
again for the sake of argument assume it’s linux of some kind, so that
configuration files are expected to be in the same place regardless of OS).
Currently we have a list of three hardcoded values in the UI, and none of
them apply properly. I’m suggesting instead of that list, we allow
free-form text; if you’re tagging glance images, you are expected to know
what applications will be looking for. This still leaves a problem in that
I can upload a package but I don’t necessarily have the ability to mark any
images as valid for it, but I think that can be a later evolution; for now,
I’m focusing on the situation where an admin is both uploading glance
images and murano packages.
As a slight side note, we do have the ability to filter image sizes based
on glance properties (RAM, cpus), but this is in the UI code, not enforced
at the contractual level. I agree reengineering some of this to be at the
contract level is a good goal, but it seems like that would involve major
reengineering of the dashboard to make it much dumber and go through the
murano API for everything (which ultimately is probably a good thing).
*From:* Stan Lagun [mailto:sla...@mirantis.com]
*Sent:* Sunday, July 20, 2014 5:42 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Murano] Image tagging
Hi!
I think it would be usefull to share the original vision on tagging that
we had back in 0.4 era when it was introduced.
Tagging was supposed to be JSON image metadata with extendable scheme.
Workflow should be able to both utilize that metadata and impose some
constraints on it. That feature was never really designed so I cannot tell
exactly how this JSON should work or look like. As far as I see it it can
contain:
1. Operating system information. For example os: { family: Linux,
name: Ubuntu, version: 12.04, arch: x86_x64 } (this also may be
encoded as a single string)
Workflows (MuranoPL contracts) need to be able to express requirements
based on those attributes. For example
image:
Contract($.class(Image).check($.family = Linux and $.arch = x86)
In UI only those images that matches such contract should be displayed.
2. Human readable image title Ubuntu Linux 12.04 x86
3. Information about built-in software for image-based deployment. Not
sure exactly what information is needed. Meybe even portion of Object Model
so that if such image is used Murano environment will automatically
recocnize and incorporate that application like it was added by user to be
installed on clean instance. This will allow using of pre-build images with
preinstalled software (e.g. speed up deployment) but will make it
transparent for the user so that this software could be managed as well as
applications that user choses to install
4. Minimal hardware requirement for the image. Murano could use that
information to guarantee that user will not select flavor that is too small
for that operating system.
5. General-purposed tags
We need to think how this concept fits into our roadmap and new Glance
Re: [openstack-dev] [Murano] Image tagging
Hi!
I think it would be usefull to share the original vision on tagging that we
had back in 0.4 era when it was introduced.
Tagging was supposed to be JSON image metadata with extendable scheme.
Workflow should be able to both utilize that metadata and impose some
constraints on it. That feature was never really designed so I cannot tell
exactly how this JSON should work or look like. As far as I see it it can
contain:
1. Operating system information. For example os: { family: Linux,
name: Ubuntu, version: 12.04, arch: x86_x64 } (this also may be
encoded as a single string)
Workflows (MuranoPL contracts) need to be able to express requirements
based on those attributes. For example
image:
Contract($.class(Image).check($.family = Linux and $.arch = x86)
In UI only those images that matches such contract should be displayed.
2. Human readable image title Ubuntu Linux 12.04 x86
3. Information about built-in software for image-based deployment. Not sure
exactly what information is needed. Meybe even portion of Object Model so
that if such image is used Murano environment will automatically recocnize
and incorporate that application like it was added by user to be installed
on clean instance. This will allow using of pre-build images with
preinstalled software (e.g. speed up deployment) but will make it
transparent for the user so that this software could be managed as well as
applications that user choses to install
4. Minimal hardware requirement for the image. Murano could use that
information to guarantee that user will not select flavor that is too small
for that operating system.
5. General-purposed tags
We need to think how this concept fits into our roadmap and new Glance
design (probably there are other projects that can benefit from extended
image metadata) before chosing one of your approaches
Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis
sla...@mirantis.com
On Fri, Jul 18, 2014 at 6:46 PM, McLellan, Steven steve.mclel...@hp.com
wrote:
Hi,
Images that can be used for package deployment have to be tagged in glance
in order to enable the UI to filter the list of images to present to a user
(and potentially preselect). Currently the tags are defined in the
dashboard code (images/forms.py) which makes things very inflexible; if I
can upload an image and a package that consumes that image, I don’t want to
have to make a code change to use it.
Anyone who can upload images should also be able to specify tags for them.
There is also the question of whether a user should be allowed to tag
images that don’t belong to them (e.g. a shared image used by a private
package), but I think that can be punted down the road somewhat.
I think this needs to be more dynamic, and if that’s agreed upon, there
are a couple of approaches:
1) Store allowed tags in the database, and allow administrators to
add to that list. Ordinary users would likely not be able to create tags,
though they could use pre-defined ones for images they owned.
2) Have some public tags, but also allow user-specified tags for
private packages. I think this leads to all sorts of tricky edge cases
3) Allow freeform tags (i.e. don’t provide any hints). Since there’s
no formal link between the tag that a package looks for and the tags
currently defined in code, this wouldn’t make anything more susceptible to
inaccuracies
It would also be worth considering if there’s value allowing multiple tags
per image (I’m on the fence).
Personally, I think that 1) would be an improvement over the current
situation that’s reasonably easy to implement; that would allow the bare
minimum of flexibility without requiring much extra design. The other
options would perhaps be a longer term goal.
Thoughts? If there’s general agreement I will turn this into a blueprint.
Steve
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] Image tagging
Hi, Images that can be used for package deployment have to be tagged in glance in order to enable the UI to filter the list of images to present to a user (and potentially preselect). Currently the tags are defined in the dashboard code (images/forms.py) which makes things very inflexible; if I can upload an image and a package that consumes that image, I don't want to have to make a code change to use it. Anyone who can upload images should also be able to specify tags for them. There is also the question of whether a user should be allowed to tag images that don't belong to them (e.g. a shared image used by a private package), but I think that can be punted down the road somewhat. I think this needs to be more dynamic, and if that's agreed upon, there are a couple of approaches: 1) Store allowed tags in the database, and allow administrators to add to that list. Ordinary users would likely not be able to create tags, though they could use pre-defined ones for images they owned. 2) Have some public tags, but also allow user-specified tags for private packages. I think this leads to all sorts of tricky edge cases 3) Allow freeform tags (i.e. don't provide any hints). Since there's no formal link between the tag that a package looks for and the tags currently defined in code, this wouldn't make anything more susceptible to inaccuracies It would also be worth considering if there's value allowing multiple tags per image (I'm on the fence). Personally, I think that 1) would be an improvement over the current situation that's reasonably easy to implement; that would allow the bare minimum of flexibility without requiring much extra design. The other options would perhaps be a longer term goal. Thoughts? If there's general agreement I will turn this into a blueprint. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
