Open Stack

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-volu
>> >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