Open Stack

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 <slagun at 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
>
>  <slagun at mirantis.com>
>
>
> On Tue, Jul 22, 2014 at 10:08 PM, McLellan, Steven <steve.mclellan at 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:slagun at 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.mclellan at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelikyan at mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/5d65997f/attachment-0001.html>