[openstack-dev] Introducing Project Graffiti

Sundar, Murali murali.sundar at intel.com
Mon May 12 22:10:44 UTC 2014


Alex,

The concepts for Graffiti are very general and are not really tied to a specific use case like application-catalog. It is fundamentally a way to annotate any resource with metadata. For example, what standard way can we use to describe the capabilities of a compute host? How can that capability be referenced on images, host-aggregates, policies, flavors, etc. How can ISVs, vendors declare their unique capabilities and have it be associated with various objects? Say I create a machine image that uses certain libraries that can benefit from some specific HW capability? How can I declare that requirement and have it be applied during scheduling? What Graffiti allows a person to do is tag various resources in openstack with known metadata, and the metadata can then be used for any purpose. We demonstrate it being used to deal with extra specs in flavors, images etc.

You are welcome to our design session @ the summit http://youtu.be/f0SZtPgcxk4 and we can discuss more, and talk about the demo code that we have working. If you are not able to make it to the session, please just email me and we can still meet and discuss this.

Thanks,
Murali


-----Original Message-----
From: Alexander Tivelkov [mailto:ativelkov at mirantis.com] 
Sent: Tuesday, May 06, 2014 2:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Introducing Project Graffiti

Hi Travis,

It will be great to have your team join the artifact repository initiative. We are going to have a session at the summit ([1]) to discuss the design, and you most welcome to join. We'll publish the etherpad with brief agenda for this session later this week.


Speaking about Murano you've got a very good point: currently Murano's application catalog is very tightly coupled with the workflow engine.
It happens because Murano aims not only to provide the pure catalog capabilities, but also to manage the lifecycle of the deployed
applications: provide ways to handle external and internal events, maintain the applications' state, report usage statistics etc - all of this usually requires workflows, and these workflows have to be aware about the applications' data structure and interdependencies. That's where the idea of Murano's workflow engine came from.

However, it turned out to be overcomplicated and having some potential overlaps with existing OpenStack projects (you probably saw a very long discussions here about it) - and we are now working hard to fix this, by establishing a clean separation between plain catalog functionality of Murano and the workflow-related processes: some of them should go to different projects, some will remain in Murano but in more unified and clear manner. We'll have a couple of design sessions on this as well - at the "cross-project workshop" ([2], [3])
- feel free to join as well, if you are interested.

Speaking about the data storage for Murano, currently we look forward to the Glance Artifact Repository: we expect murano application packages (being composed out of Heat templates, workflows, binary files and other stuff) to be stored as composite multi-part artifacts in Glance. Each part of this artifact will be an "entry-point" for some action is some OpenStack service (like you said: boot sources for Nova, templates for Heat etc), while the workflow which coordinates this various services and tells them which part of artifact to boot from will be run as the higher-level layer service.
Hope this answer your questions. If you have more to ask, please feel free to join our weekly meeting in IRC ([4]) - the nearest one is today (Tuesday), at 17:00 UTC

Thanks!


[1] http://junodesignsummit.sched.org/event/b0e1f0cbefffa942e276f1add9f85d03#.U2h8JF6nDWU
[2] http://junodesignsummit.sched.org/event/b7f067ff055ff7db9c92867f3febe1d9#.U2iAd16nDWU
[3] http://junodesignsummit.sched.org/event/556d10915a1a0a2f1aee3ba286826b60#.U2iAeF6nDWU
[4] https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
--
Regards,
Alexander Tivelkov


On Tue, May 6, 2014 at 9:37 AM, Tripp, Travis S <travis.tripp at hp.com> wrote:
> Hi Angus,
>
>> This seems neat, but also seems to have some overlap with glance's 
>> new catalog and some of the things Murano are doing. Have you had a look at those efforts?
>
> Thanks! We have been keeping an eye on the Glance work and the Murano work, and your email reminded me to catch back up on both of them. I think in both cases that the Graffiti concepts are complementary. However, strictly speaking from a bird's eye view on application categorization, there is some reconciliation to work out on that aspect.
>
> Regarding the Glance artifact repository, this looks like a nice revamp of its concepts. Most of it seems to be very related to handling artifacts, dependencies, versions, and relationships associated with packaging in a generic way so that external services can use it in a variety of ways. There is one feature that was discussed in the last Glance meeting logs that I think we might be able to leverage for some of the Graffiti concepts. That is a dynamic schemas API. Perhaps, we can build the Graffiti dictionary concepts on top of it.  We're definitely interested in anything that creates less moving parts for us and is already part of the standard OpenStack ecosystem.
>
> For Murano, the pure application catalog UI is an interesting concept that today still seems to be intertwined with the Murano workflow engine. It isn't clear to me if the intent is for it to eventually become the UI for everything application related, including Solum and pure Heat templates? From the mailing list discussions, it seems that this is still a rather unresolved question.
>
> For us we'd like to be able to provide end user help with even the existing launch instance UI. Also, one of the goals of the Graffiti concepts is to be able to directly "tag" resources with metadata that comes from multiple sources, whether that is system provided (e.g. various compute capabilities) or user provided (e.g. categories or software tags) and then be able to search on them. This can be used for boot sources, flavors, host aggregates, etc, and perhaps even networks in the future.  It seems possible that Murano may just be a consumer of some of the same data?
>
> -Travis
>
>> -----Original Message-----
>> From: Angus Salkeld [mailto:angus.salkeld at rackspace.com]
>> Sent: Monday, May 05, 2014 8:16 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] Introducing Project Graffiti
>> Importance: High
>>
>> On 05/05/14 20:26 +0000, Tripp, Travis S wrote:
>> >Hello Everybody,
>> >
>> >A challenge we've experienced with using OpenStack is discovering, 
>> >sharing,
>> and correlating metadata across services and different types of 
>> resources. We believe this affects both end users and administrators.
>>
>> Hi
>>
>> This seems neat, but also seems to have some overlap with glance's 
>> new catalog and some of the things Murano are doing. Have you had a look at those efforts?
>>
>> -Angus
>>
>> >
>> >For end users, the UI can be too technical and require too much 
>> >pre-existing
>> knowledge of OpenStack concepts. For example, when you launch 
>> instances, you should be able to just specify categories like "Big Data" or an "OS Family"
>> and let the system find the boot source for you, whether that is an 
>> image, snapshot, or volume.  It should also allow finer grained 
>> filtering such as choosing specific versions of software that you want.
>> >
>> >For administrators, we'd like there to be an easier way to 
>> >meaningfully
>> collaborate on properties across host aggregates, flavors, images, 
>> volumes, or other cloud resources. Today, this often involves 
>> searching wikis and opening the source code.
>> >
>> >We, HP and Intel, believe that both of the above problems come back 
>> >to
>> needing a better way for users to collaborate on metadata across 
>> services and resource types.  We started project Graffiti to explore 
>> ideas and concepts for how to make this easier and more approachable 
>> for end users. We're asking for your input and participation to help us move forward!
>> >
>> >To help explain the ideas of the project, we have created a quick 
>> >screencast
>> demonstrating the concepts running under POC code. Please take a look!
>> >
>> >
>> >*         Graffiti Concepts Overview:
>> >
>> >o   http://youtu.be/f0SZtPgcxk4
>> >
>> >Please join with us to help refine the concepts and identify where 
>> >we can best
>> fit in to the ecosystem. We have a few blueprints, but they need 
>> additional support outside of the Horizon UI. We believe our best 
>> path is one where we can contribute the Graffiti service as either a 
>> new project in an existing program or as a series of enhancements to 
>> existing projects.  Your insight and feedback is important to us and we look forward to growing this initiative with you!
>> >
>> >We have a design session at the summit where we'd love to have open
>> discussion with all who can attend:
>> >
>> >Juno Summit Design Session
>> >http://sched.co/1m7wghx
>> >
>> >For more info, please visit our wiki:
>> >
>> >Project Wiki
>> >https://wiki.openstack.org/wiki/Graffiti
>> >
>> >IRC
>> >#graffiti on  Freenode<http://freenode.net/>
>> >
>> >Related Blueprints
>> >https://blueprints.launchpad.net/horizon/+spec/instance-launch-using
>> >-ca
>> >pability-filtering
>> >https://blueprints.launchpad.net/horizon/+spec/faceted-search
>> >https://blueprints.launchpad.net/horizon/+spec/tagging
>> >https://blueprints.launchpad.net/horizon/+spec/host-aggregate-update
>> >-me
>> >tadata
>> >https://blueprints.launchpad.net/python-cinderclient/+spec/support-v
>> >olu
>> >me-image-metadata
>> >
>> >Thank you,
>> >Travis Tripp
>> >
>> >
>>
>> >_______________________________________________
>> >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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list