<div dir="ltr">Hi!<div><br></div><div>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.</div><div>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:</div>
<div><br></div><div>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)</div>
<div> Workflows (MuranoPL contracts) need to be able to express requirements based on those attributes. For example</div><div><br></div><div> image:</div><div> Contract($.class(Image).check($.family = Linux and $.arch = x86)</div>
<div><br></div><div> In UI only those images that matches such contract should be displayed.</div><div><br></div><div>2. Human readable image title "Ubuntu Linux 12.04 x86"</div><div><br></div><div>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</div>
<div><br></div><div>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.</div><div><br></div><div>5. General-purposed tags</div>
<div><br></div><div>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</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours,<br>
Stan Lagun<br>Principal Software Engineer @ Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><br>
<a href="mailto:slagun@mirantis.com" target="_blank"></a></span></span></div></div>
<br><br><div class="gmail_quote">On Fri, Jul 18, 2014 at 6:46 PM, McLellan, Steven <span dir="ltr"><<a href="mailto:steve.mclellan@hp.com" target="_blank">steve.mclellan@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">Hi,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I think this needs to be more dynamic, and if that’s agreed upon, there are a couple of approaches:<u></u><u></u></p>
<p><u></u><span>1)<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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.<u></u><u></u></p>
<p><u></u><span>2)<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>Have some public tags, but also allow user-specified tags for private packages. I think this leads to all sorts of tricky edge cases<u></u><u></u></p>
<p><u></u><span>3)<span style="font:7.0pt "Times New Roman"">
</span></span><u></u>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<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">It would also be worth considering if there’s value allowing multiple tags per image (I’m on the fence).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thoughts? If there’s general agreement I will turn this into a blueprint.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Steve<u></u><u></u></p>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>