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 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.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 mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev