Re: [openstack-dev] [magnum][app-catalog][all] Build unified abstraction for all COEs
or the versatility > >> of Mesos. They want to avoid caring about the infrastructure provider > >> bit (and not deploy Mesos or Kubernetes themselves). > >> > >> Let's focus on the infrastructure provider bit -- that is what we do and > >> what the ecosystem wants us to provide. > >> > > > >__ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Georgy Okrokvertskhov Director of Performance Engineering, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack Foundation] [board][tc][all] One Platform – Containers/Bare Metal? (Re: Board of Directors Meeting)
At Mirantis we are playing with different technologies to explore possible ways of using containers. Recently we did some POC kind of work for integration existing OpenStack components with containers technologies. Here is a link <https://youtu.be/UthzO-xdoug> for a demo. In this POC Nova API can schedule a container via Nova Mesos driver which is quite similar to nova-docker concept. The most interesting part is that Neutron manages Docker networks and Cinder creates a volume which can be attached to the container. Mesos is not necessary here, so the same work can be done with existing nova-docker driver. We did not try to address all possible cases for containers. This POC covers a very specific use cases when someone has a limited number of applications which can be executed in both VMs and containers. This application is self container so there is no needs in complex orchestration which Kubernetes or Marathon provides. -Gosha On Wed, Apr 13, 2016 at 8:05 AM, Joshua Harlow <harlo...@fastmail.com> wrote: > Thierry Carrez wrote: > >> Fox, Kevin M wrote: >> >>> I think my head just exploded. :) >>> >>> That idea's similar to neutron sfc stuff, where you just say what >>> needs to connect to what, and it figures out the plumbing. >>> >>> Ideally, it would map somehow to heat & docker COE & neutron sfc to >>> produce a final set of deployment scripts and then just runs it >>> through the meat grinder. :) >>> >>> It would be awesome to use. It may be very difficult to implement. >>> >>> If you ignore the non container use case, I think it might be fairly >>> easily mappable to all three COE's though. >>> >> >> This feels like Heat with a more readable descriptive language. I don't >> really like this approach, because you end up with the lowest common >> denominator between COE's functionality. They are all different. And >> they are at the peak of the differentiation phase. The LCD is bound to >> be pretty basic. >> >> This approach may be attractive for us as infrastructure providers, but >> I also know this is not attractive to users who used Kubernetes before >> and wants to continue to use Kubernetes (and don't really want to care >> about whether OpenStack is running under the hood). They don't want to >> learn another descriptor language or API, they just want to learn the >> Kubernetes description model and API and take advantage of its unique >> capabilities. >> >> In summary, this may be a good solution for *existing* OpenStack users >> to start playing with containerized workloads. But it is not a good >> solution to attract the container cool kids to using OpenStack as their >> base infrastructure provider. For those we need to make it as >> transparent and simple to use their usual tools to deploy on top of >> OpenStack clouds. The more they can ignore we are there, the better. >> >> > I get the feeling of 'the more they can ignore we are there, the better.' > but it just feels like at that point we have accepted our own fate in this > arena vs trying to actually having an impact in it... Do others feel that > it is already at the point where we can no longer attract the cool kids, is > the tipping point of that happening already past? > > I'd like for openstack to still attract the cool kids, and not just > attract the cool kids by accepting 'the more they can ignore we are there, > the better' as our fate... I get that someone has to provide the equivalent > of roads, plumbing and water but man, it feels like we can also provide > other things still ;) > > -Josh > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Georgy Okrokvertskhov Director of Performance Engineering, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Heat][Kolla][Magnum] The zen of Heat, containers, and the future of TripleO
e cluster with virtual IPs and failover and all > that > > jazz. It may be that everything would just work the same way, but we > would > > be in uncharted territory and there would likely be unanticipated > > subtleties. It's particularly unclear how we would handle stop-the-world > > database migrations in this model, although we do have the option of > hoping > > that stop-the-world database migrations will have been completely phased > out > > by then. > > > > To make it even more complicated, we ultimately want the services to > > heterogeneously spread among controller nodes in a configurable way. I > > believe that Dan's work on composable roles has already gone some way > toward > > this without even using containers, but it's likely to become > increasingly > > difficult to model in Heat without some sort of template generation. (I > > personally think that template generation would be a Good Thing, but > we've > > chosen not to go down that path so far.) Quite possibly even just having > > composable roles could make it untenable to continue maintaining separate > > Pacemaker and non-Pacemaker deployment modes. It'd be really nice to have > > the flexibility to do things like scale out different services at > different > > rates. What's more, we are going to need some way of redistributing > services > > when a machine in the cluster fails, and ultimately we would like that > > process to be automated, which would *require* a template generation > > service. > > > > We certainly *could* build all of that. But we definitely shouldn't > because > > this is the kind of thing that services like Kubernetes and Apache Mesos > are > > designed to do already. And that raises another possibility: Angus & > friends > > are working on capturing the orchestration relationships for > Mesos+Marathon > > within the Kolla project (specifically, in the kolla-mesos repository). > This > > represents a tremendous opportunity for the TripleO project to further > its > > mission of having the same deployment tools available to everyone as an > > official part of the OpenStack project without having to maintain them > > separately. > > > > As of the Liberty release, Magnum now supports provisioning Mesos > clusters, > > so TripleO wouldn't have to maintain the installer for that either. (The > > choice of Mesos is somewhat unfortunate in our case, because Magnum's > > Kubernetes support is much more mature than its Mesos support, and > because > > the reasons for the decision are about to be or have already been > overtaken > > by events - I've heard reports that the features that Kubernetes was > missing > > to allow it to be used for controller nodes, and maybe even compute > nodes, > > are now available. Nonetheless, I expect the level of Magnum support for > > Mesos is likely workable.) This is where the TripleO strategy of using > > OpenStack to deploy OpenStack can really pay dividends: because we use > > Ironic all of our servers are accessible through the Nova API, so in > theory > > we can just run Magnum out of the box. > > This is something we already & partially discussed when I submitted > the Containers blueprint, in September 2015: > https://review.openstack.org/#/c/222002/ > > I was told to abandon this blueprint, so Container folks could create a > new one: > https://review.openstack.org/#/c/223182/ > > The "new" blueprint was never merged so I guess TripleO team accepted > the design, moreoever discussed during Tokyo Summit. > I am sad to see you were not involved in both blueprints, nor present > during our discussions, but let's move forward. > > > > > The chances of me personally having time to prototype this are > slim-to-zero, > > but I think this is a path worth investigating. > > A lot of people are currently very busy, because of releases and other > critical topics, like CI, split stack and composable roles, maybe > people focusing on containers can also reply to this thread and try to > understand why we're here now. > > I know it has currently no impact on TripleO, but I plan to gather > feedback about Puppet & Containers usage during next Summit in Austin, > I know TimeWarner is deploying OpenStack with docker & Puppet > OpenStack modules at scale, and they have a pretty nice experience on > that. > -- > Emilien Macchi > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Georgy Okrokvertskhov Director of Performance Engineering, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios
Hi Gal, We do have DVR testing results on 200 nodes for both VXLAN and VLAN configurations. We plan to publish them in performance-docs repository. Thanks Georgy On Thu, Feb 18, 2016 at 6:06 AM, Gal Sagie <gal.sa...@gmail.com> wrote: > Hello All, > > We have started to test Dragonflow [1] data plane L3 performance and was > wondering > if there is any results and scenarios published for the current Neutron DVR > that we can compare and learn the scenarios to test. > > We mostly want to validate and understand if our results are accurate and > also join the > community in defining base standards and scenarios to test any solution > out there. > > For that we also plan to join and contribute to openstack-performance [2] > efforts which to me > are really important. > > Would love any results/information you can share, also interested in > control plane > testing and API stress tests (either using Rally or not) > > Thanks > Gal. > > [1] > http://docs.openstack.org/developer/dragonflow/distributed_dragonflow.html > [2] https://github.com/openstack/performance-docs > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Mesos orchestration as discussed at mid cycle (action required from core reviewers)
ughts on the idea. > > > > Note of the core reviewers there, we had 7 +1 votes (and we have a 9 > > individual core reviewer team so there is already a majority but I’d > like to > > give everyone an opportunity weigh in). > > As one of the core reviewers who couldn't make the summit, this sounds > like a very exciting direction to go in. I'd love to see more docs (I > realize it's still early) on how mesos will be utilized and what > additional frameworks may be used as well. Is kubernetes planned to be > part of this mix since mesos works with it now? > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging]
I believe in oslo.messaging routing_key is a topic. Here is an example for ceilometer: https://github.com/openstack/ceilometer/blob/master/ceilometer/meter/notifications.py#L212 And here is an oslo code for rabbitMQ driver: https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L926 Routing_key is set to topic. Thanks Gosha On Tue, Sep 1, 2015 at 6:27 PM, Nader Lahouti <nader.laho...@gmail.com> wrote: > Hi, > > I am considering to use oslo.messaging to read messages from a rabbit > queue. The messages are put into the queue by an external process. > In order to do that I need to specify routing_key in addition to other > parameters (i.e. exchange and queue,... name) for accessing the queue. I > was looking at the oslo.messaging API and wasn't able to find anywhere to > specify the routing key. > > Is it possible to set routing_key when using oslo.messaging? if so, can > you please point me to the document. > > > Regards, > Nader. > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov ativel...@mirantis.com
wrote:
Hi Gosha,
Supporting versioning in existing backend will require us to re-implement
the significant part of Artifact Repository in Murano API: we'll need to
add versions and dependencies concepts into our model (which is already
complicated and dirty enough), extend appropriate API calls etc. And all
the efforts will be a waste of time once we finally migrate to Artifacts.
Also, what do you mean by set by default? V3 API is experimental, but it
is already merged into upstream Glance, so there is no problem with using
it in Murano right away.
This is exactly why I have these concerns. I wonder how much customers
will use experimental API in production. I just don't want to add extra
block on Murano adoption way.
--
Regards,
Alexander Tivelkov
On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov
gokrokvertsk...@mirantis.com wrote:
Hi Alex,
Thank you for the great summary.
I have a concern about item #8. Can we add an option to Murano to use
previous storage engine rather then Glance v3? We need to make sure that v3
API in Glance is set by default before we do a hard dependency on it in
Murano.
Thanks
Gosha
On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov
ativel...@mirantis.com wrote:
Hi folks,
Ability to manage multiple versions of application packages and their
dependencies was always an important item in Murano roadmap, however we
still don't have a clear spec for this feature.
Yesterday we hosted a small design session to come up with a plan on
what can be done in Liberty timeframe to have proper versioning for
MuranoPL classes and packages. Stan Lagun, Kirill Zaitsev and myself
participated offline, some other muranoers joined remotely. Thanks to
everybody who joined us.
TL;DR: it turns out that now we have a clear plan which will allow us to
achieve proper versioning of the packages and classes, and we'll try to
implement the most important parts of it in Liberty.
Here is the detailed outcome of the session:
1. We'll use the standard Semantic Versioning format
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our
packages: changes which break backwards-compatibility should increment
the
major segment, non-breaking new features increment the minor segment and
all non-breaking bugfixes increment the patch segment. The developers
should be carefull with the new features part: if you add a new method
to
a class, it may be considered a breaking change if the existing
subclasses
of this class have the same method already declared. We still assume that
such changes should lead to increment of 'minor' segment, however it is
up
to best judgement of developers in particular case: if the risk of such
method override is really high it may worth to increment the 'major'
segment. Proper guideline on the versioning rules will be published
closer
to L release.
2. A new field 'Version' is introduced into package manifest file
which should define package version in complete semver format. The field
itself is optional (so existing apps are not broken), if it is not
specified the package is assumed to have version '0.0.0'
3. The existing 'Require' block of Application manifest will be used
to specify the package dependencies. Currently it is a yaml-based
dictionary, with the keys set to fully-qualified names of the dependency
packages and the values set to the version of those dependencies.
Currently
this block is used only for integration with apps stored at
apps.openstack.org. It is suggested to use this block in the
deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the
semver notation, however it may be specified in the shortened format,
i.e.
without specifying the 'patch' or 'patch' and 'minior' components. In
this
case the dependency will be specified as a range of allowed versions. For
example, a dependency version 1.2 will mean a (1.2.0 = version 1.3)
range.
If the version of a dependency is not specified (like in this
existing app - [1]) then we assume the version 0 - i.e. the last
available pre-release version of a package.
4. Murano core library is also a package which has its own version.
The current one is assumed to have a version 0.1.0, the one which is
going
to be released in L will be probably called 0.2.0. The lib is still
quickly
evolving, so we are not releasing a 1.0.0 until we are sure that we are
not
going to have any breaking changes anytime soon.
As with any other package it will be possible to have several
versions of the Core Library installed in Murano at the same moment of
time.
5. There is no mandatory need to add the the dependency on the core
library to the Requires
Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes
are no difference from the classes defined in a regular package. 8. We are going to store murano packages as Glance V3 Artifacts Repository, naturally mapping package's FQN and version to artifact's name and version. The package dependencies will be stored in Glance as cross-artifact dynamic dependencies (i.e. dependencies not on a particular artifact but on the last artifact matching the given name and the version range query) as soon as that feature is implemented in Glance (currently only static dependencies are implemented there). Until that, the dependencies will be stored as a regular list of strings, and the Murano engine will process it and query Glance to fetch the packages. 9. In L cycle we are not going to show multiple versions of the same app in Murano dashboard: only the last one will be shown if the multiple versions are present. This is to minimize the changes at Dashboard side: in future releases we'll add the ability to select the proper version. The generation of the object model by dynamic UI also remains intact. 10. However, the structure of the object model isself gets changed: in the ? block of each object two new fields appear: package and version, which correspond to the FQN and the version of the package which contain the class of the given object. UI leaves these fields as Nones when it generates the OM, and the engine computes them in a regular way: queries the package repository for the most recent version of a package which contains the class with a given name, and saves information about its name and version. This values get persisted in an Object Model when it gets serialized after the deployment. As a result, the versions of the components are fixed once the environment is deployed, so if some packages get updated afterwards, the existing components remain pinned to their initial version. As a result, the environment may get several components of the same type but different versions. 11. When the Object Model is validated after the deserialization, the behavior of $.class() contract is changed. During its validation the value passed to the appropriate property or argument should be of a type which is declared either in a current package (or in the another version of the current package, given that the major component of the versions is the same) or in one of the packages satisfying the requirements of the current one. I.e. it becomes impossible to reference any class from the unreferenced package. 12. When inheriting some other class using the 'Extends' attribute, the ancestor class should be defined either in the current package or in one of the packages satisfying the requirements of the current one. 13. (creepy advanced stuff) It may turn out that in case of the multiple inheritance a single class will attempt to inherit from two different versions of a same class. An exception should be thrown in this case, unless there is a possibility to find a version of this class which satisfies all parties. *For example: classA inherits classB from packageX and classC from packageY. Both classB and classC inherit from classD from packageZ, however packageX depends on the version 1.2.0 of packageZ, while packageY depends on the version 1.3.0. This leads to a situation when classA transitively inherits classD of both versions 1.2 and 1.3. So, an exception will be thrown. However, if packageY's dependency would be just 1 (which means any of the 1.x.x family) the conflict would be resolved and a 1.2 would be used as it satisfies both inheritance chains.* So, all the above cover most of our present needs for MuranoPL package and class versioning. Also, we already have a way which allows us to properly version the format of MuranoPL language (a Format key in application manifests) and UI-definition files (Version key in that files). This basically allows us to target the packages for a minimum version of Murano / Murano Dashboard. I hope this rather lengthly email is useful. Stan Lagun has taken an action item to frame all the above into a more formal spec. [1] https://github.com/openstack/murano-apps/blob/master/MySQL/package/manifest.yaml#L26 -- Regards, Alexander Tivelkov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org
Re: [openstack-dev] [Murano] Documentation on how to Start Contributing
Hi, If I understand correctly, you want to be able to install modified Murano from your own repository. There is a devstack integration script in Murano repository which does this. Here are lines where you can point to specific repository for Murano installation in devstack: https://github.com/openstack/murano/blob/master/devstack/plugin.sh#L17-L18 Installation procedure in the README.rst file in the folder devstack of murano repository. Thanks Gosha On Thu, Jul 9, 2015 at 9:54 PM, Nikolay Starodubtsev nstarodubt...@mirantis.com wrote: Hi, Can you describe what problems do you have with bring code changes into a live Devstack environment, and test them. If you want a real-time QA experience you can ask your questions at #murano on freenode. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-07-10 2:32 GMT+03:00 Vahid S Hashemian vahidhashem...@us.ibm.com: Hello, I am wondering if there is any documentation for new contributors that explains how to get up-to-speed with Murano development; something that covers how to bring code changes into a live Devstack environment, and test them. I've looked at the Murano documentation online and have not been able to find it. Any pointer is very much appreciated. Thanks. - *Vahid Hashemian, Ph.D.* Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Congress] Application placement use case
Hi Tim, Thank you for the comprehensive information. From Murano standpoint each OpenStack region is a separate Heat endpoint. So once Murano has a decision about placement it will just use proper Heat endpoint to initiate stack creation process. Murano does not expect that Congress will do actual placement. Murano has a way to do this by itself as it just pushes stack template to the Heat. As I see in your reply there is a clear way to define such policies which is really great. It sounds like there is nothing we need to change in the Congress itself which is also great. I think we have explicit Congress call in Murano, at least it was discussed in Paris. I will check if we have someone in Murano team who can draft a spec for this feature and use case in Murano. Sounds like we have enough information for that. Once again, thank you for the information. Regards, Gosha On Mon, Jul 6, 2015 at 9:13 AM, Tim Hinrichs t...@styra.com wrote: Sorry--hit the Send button by accident. Hi Gosha, This definitely sounds like an interesting use case for Congress. Keep in mind that Congress doesn't itself do placement (though we did some experimentation with that [1][2]). Some thoughts. 1. Let's suppose Murano/Congress/etc. allow us to figure out which app should be deployed in which region. Is there a separate Nova for each region that can do the actual scheduling? If not, how would Murano force the app to be deployed in the proper region? 2. Let's assume Murano can force the app to the proper region. One option for using Congress to compute the proper region would be to write policy statements that enumerate the permitted regions for a given application, and then ask Congress for one of those regions. For your suggested policies above, we could write the following datalog statements Solaris is required then select Region_Solaris. permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) A. If Solaris is required then select region_solaris permitted_region(app, region_solaris) :- murano:app_requires(app, solaris) B. If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] This one requires additional expressiveness in the language than we currently have (because it asks to minimize over several options). But it would be something like... best_region(app, min(y)) :- permitted_region(app, x), ceilometer:region_load(x, y) [1] Design doc: https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit [2] Slides: https://drive.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/view Tim On Thu, Jul 2, 2015 at 7:36 AM Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, All applications are monolithic so they don't need to be split over multiple regions. It is necessary to have an ability to select a region based on requirements and for now I don't care how they are placed inside the region. I am not sure how region's capabilities will be stored and actually this is a reason why I am asking if Congress will solve this. I can imagine a policy which says if Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] In this use case Murano will deploy complex environment which consist of multiple atomic applications with different requirements, so deployment will be across clouds but for whole environment. Imagine IBM MQ on AIX and PowerPC + Oracle DB on Solaris + Microsoft IIS on Windows 2012 HyperV + WebSphere on RHEL KVM. Thanks Gosha On Wed, Jul 1, 2015 at 10:17 PM, ruby.krishnasw...@orange.com wrote: Hi Did you mean placement at “two levels”. First to select the region and then within each region, Nova scheduler will place on hosts. But where will the capabilities of each region (based on which placement decision will be made) be stored? Will each region be queried to obtain this information? Will a single application need to be placed (split across) different regions? Ruby *De :* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Envoyé :* mercredi 1 juillet 2015 21:26 *À :* OpenStack Development Mailing List *Objet :* [openstack-dev] [Murano][Congress] Application placement use case Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova
Re: [openstack-dev] [Murano] Discuss simulated-execution-mode-murano-engine blueprint
Hi Kate,
MuraPL has a concept of exceptions. Unit testing will be important to make
sure that workflows behaves correctly in exceptions situations. How will be
this addressed int he testing framework? Will you have some specific
assertions like python unit testing framework?
Thanks
Gosha
On Mon, Jul 6, 2015 at 9:02 AM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Folks,
I have specific topic to discuss: how murano test-fixture will look like
and how it can be run.
The idea is to implement a unit-testing framework, similar to regular
frameworks for python or other languages,
which will allow to define test fixtures in MuranoPL.
A Test fixture is a regular muranoPL class definition, which methods are
the test cases.
When such fixture is included into Murano application package the
deployment of application may be tested without running actual VM's.
Here is how the test fixture may look like:
Namespaces:
=: io.murano.apps.foo.tests
sys: io.murano.system
pckg: io.murano.apps.foo
Extends: io.murano.tests.TestFixture
Name: FooTest
Methods:
initialize:
Body:
*# Object model can be loaded from json file, or provided
directly in murano-pl code as a yaml insertion.*
*# - $.appJson:
new(sys:Resources).json('foo-test-object-model.json')*
- $.appJson:
- ?:
type: io.murano.apps.foo.FooApp
name: my-foo-obj
instance:
?:
type: io.murano.resources.Instance
...
setUp:
Body:
- $.env: $.createEnvironment($.appJson) # creates an
instance of std:Environment
- $.myApp:
$.env.applications.where($.name='my-foo-obj').first()
*# mock instance spawning*
- mock($.myApp.instance, deploy, mockInstanceDeploy, $this)
- mock(res:Instance, deploy, mockInstanceDeploy, $this)
testFooApp:
Body:
- $.env.deploy()
- $.assertEqual(true, $.myApp.getAttr('deployed'))
mockInstanceDeploy:
Arguments:
- mockContext
Body:
- Return:
* # heat template*
io.murano.tests.TestFixture - is a base class, that contains set of
methods, needed in all the test-cases which inherit it, such as assertEqual
and other similar assertions.
All it contains a $.createEnvironment method which may be called at the
setUp phase (a method being run before each test case) to construct the
object model to run the test against.
Test developer will be able to mock some of the functions or method which
are out of the scope of the current test
(for example, interaction with other applications or classes from the
standard murano library, such as instance.deploy etc).
The mock will allow to override the actual method execution and provide
the expected output of the method.
The actual implementation of mocking requires more thoughtful design, so
I'll create a separate spec for it.
What do you think about the overall idea and the test syntax proposed
above?
On Wed, Jun 3, 2015 at 5:15 PM, Ekaterina Chernova efedor...@mirantis.com
wrote:
Hi all!
I'd like to discuss first implementation thoughts about this [1]
blueprint, that we want to implement in Liberty.
This feature is supposed to increase the speed of application development.
Now engine interacts with API to get input task and packages.
Items, planned to implement first would enable loading local task and new
package, without API and Rabbit involved.
After that simple testing machinery will be added to MuranoPL: mock
support and simple test-runner.
So user can test application methods as he wants by creating simple tests.
Deployment parameters, such as heat stack and murano execution
plan outputs
may be set as returned value in tests.
Finally, tests may be placed into a murano package for easier package
verification and later modification.
I'm going to write specification soon. But before, we need to prepare
list of functions, that are needed to
implement simple mocking machinery in MuranoPL.
Please, leave your thoughts here or directly in the blueprint.
Regards, Kate.
[1] -
https://blueprints.launchpad.net/murano/+spec/simulated-execution-mode-murano-engine
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
Re: [openstack-dev] [Murano][Congress] Application placement use case
Hi, All applications are monolithic so they don't need to be split over multiple regions. It is necessary to have an ability to select a region based on requirements and for now I don't care how they are placed inside the region. I am not sure how region's capabilities will be stored and actually this is a reason why I am asking if Congress will solve this. I can imagine a policy which says if Solaris is required then select Region_Solaris. Or more complex If Solaris is required then select less loaded regions from [Region_Solaris1, Region_Solaris2] In this use case Murano will deploy complex environment which consist of multiple atomic applications with different requirements, so deployment will be across clouds but for whole environment. Imagine IBM MQ on AIX and PowerPC + Oracle DB on Solaris + Microsoft IIS on Windows 2012 HyperV + WebSphere on RHEL KVM. Thanks Gosha On Wed, Jul 1, 2015 at 10:17 PM, ruby.krishnasw...@orange.com wrote: Hi Did you mean placement at “two levels”. First to select the region and then within each region, Nova scheduler will place on hosts. But where will the capabilities of each region (based on which placement decision will be made) be stored? Will each region be queried to obtain this information? Will a single application need to be placed (split across) different regions? Ruby *De :* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Envoyé :* mercredi 1 juillet 2015 21:26 *À :* OpenStack Development Mailing List *Objet :* [openstack-dev] [Murano][Congress] Application placement use case Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova scheduler can’t be used (at least in my understanding) so we need to have some placement policies to put applications properly. And obviously we don’t want to ask end user about the placement. Right now in Murano we can do this by: 1.Hardcoding placement inside application. This approach will work and does not require any significant change in Murano. But there are obvious limitations like if we have two options for placement which one should be hardcoded. 2.Create special placement scheduler application\class in Murano which will use some logic to place applications properly. This is better approach as nothing is hard coded in applications except their requirements. Applications will just have a workflow to ask placement scheduler for a decision and then will just use this decision. 3.Use some external tool or OpenStack component for placement decision. This is a very generic use case which we saw multiple times. Tools like CIRBA are often used for this. Murano will need an interface to ask these tools. I think about this solution as an extension of 2. I am aware that Murano is working on integration with Congress and I am looking for an opportunity here to address real use case of Murano usage in real customer environment. It will be great to know if OpenStack can offer something here without involving 3rd party tools. I suspect that this is a good use case for Congress, but I would like to see how it might be implemented. Thanks Gosha -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. __ OpenStack Development Mailing List
[openstack-dev] [Murano][Congress] Application placement use case
Hi, I would like to share with the community one of the real use case which we saw while working with one of the Murano customer and ask an advice. This customer has multiple OpenStack regions which are serving for different hypervisors. The reason for that is Oracle OpenStack which is used to work with Solaris on top of SPARC architecture. There are other hypervisors KVM and VMWare which are used. There are multiple applications which should be placed to different regions based on their requirements (OS, Hypervisor, networking restrictions). As there is no single cloud, Nova scheduler can’t be used (at least in my understanding) so we need to have some placement policies to put applications properly. And obviously we don’t want to ask end user about the placement. Right now in Murano we can do this by: 1. Hardcoding placement inside application. This approach will work and does not require any significant change in Murano. But there are obvious limitations like if we have two options for placement which one should be hardcoded. 2. Create special placement scheduler application\class in Murano which will use some logic to place applications properly. This is better approach as nothing is hard coded in applications except their requirements. Applications will just have a workflow to ask placement scheduler for a decision and then will just use this decision. 3. Use some external tool or OpenStack component for placement decision. This is a very generic use case which we saw multiple times. Tools like CIRBA are often used for this. Murano will need an interface to ask these tools. I think about this solution as an extension of 2. I am aware that Murano is working on integration with Congress and I am looking for an opportunity here to address real use case of Murano usage in real customer environment. It will be great to know if OpenStack can offer something here without involving 3rd party tools. I suspect that this is a good use case for Congress, but I would like to see how it might be implemented. Thanks Gosha -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] stackforge projects are not second class citizens
__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [app-catalog][infra] Stale entries
On Sat, Jun 6, 2015 at 4:56 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-05 22:04:05 -0700 (-0700), Georgy Okrokvertskhov wrote: +1 for the periodic job. I don't know how it fits to the current OpenStack infrastructure, but we definitely need this. As I know there is a place for 3rd party gates and CI\CD systems, so probably, the best way to do this for now, is to setup this externally to the OpenStack infra. We have periodic jobs defined in Zuul which do things like rerun unit or integration tests for projects' stable branches and then send failure notifications to the stable-maint mailing list. It's definitely a thing. This is great. It means that we can use existing OpenStack approach rather then reinventing the wheel. I think I will be able to create a simple script for URLs verification. It looks pretty straightforward as catalog is in machine friendly format. Thanks Gosha __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
Oh. I think it might be possible if you use Heat template based
applications. As Murano has no clue how to merge two independent heat
templates it might create a new stack. That is why we use workflows to
define an expected behavior.
Thanks
Gosha
On Wed, Jun 3, 2015 at 1:06 PM, Georgy Okrokvertskhov
gokrokvertsk...@mirantis.com wrote:
This is interesting. I never saw such behavior. I don't think this is the
way how Murano supposed to behave. Is this a devstack version of Murano?
You probably see some issue here.
Thanks
Gosha
On Wed, Jun 3, 2015 at 11:26 AM, Vahid S Hashemian
vahidhashem...@us.ibm.com wrote:
Hi Gosha,
Thanks again for your time.
I seem to be observing a different behavior in my environment. Here is
the experiment I ran:
1. Created environment env. No stack yet.
2. Added a component to env. No stack yet.
3. Deployed env. Two stacks are created:
template for stack 1:
description: 'This stack was generated by Murano for environment env (ID:
5841466294b94562ab7aee61e45f1fd6)'
heat_template_version: '2013-05-23'
resources: {}
template for stack 2:
description: Simple template to deploy a single cirros instance
heat_template_version: '2014-10-16'
resources:
~~my_instance:
properties: {flavor: m1.micro, image: cirros-0.3.4-x86_64-uec}
type: OS::Nova::Server
4. Add a second component to env. No changes to stacks.
5. Deploy env. Two existing stacks are updated (no changes to their
template). A new stack is created.
template for stack 3:
description: Simple template to deploy a single cirros instance
heat_template_version: '2014-10-16'
resources:
~~my_instance:
properties: {flavor: m1.small, image: ubuntu-trusty-amd64}
type: OS::Nova::Server
Basically, for each component addition I see a new stack is created with
only resources from that component in it.
Am I missing something?
Regards,
-
Vahid Hashemian, Ph.D.
Advisory Software Engineer, IBM Cloud Labs
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
This is interesting. I never saw such behavior. I don't think this is the
way how Murano supposed to behave. Is this a devstack version of Murano?
You probably see some issue here.
Thanks
Gosha
On Wed, Jun 3, 2015 at 11:26 AM, Vahid S Hashemian
vahidhashem...@us.ibm.com wrote:
Hi Gosha,
Thanks again for your time.
I seem to be observing a different behavior in my environment. Here is the
experiment I ran:
1. Created environment env. No stack yet.
2. Added a component to env. No stack yet.
3. Deployed env. Two stacks are created:
template for stack 1:
description: 'This stack was generated by Murano for environment env (ID:
5841466294b94562ab7aee61e45f1fd6)'
heat_template_version: '2013-05-23'
resources: {}
template for stack 2:
description: Simple template to deploy a single cirros instance
heat_template_version: '2014-10-16'
resources:
~~my_instance:
properties: {flavor: m1.micro, image: cirros-0.3.4-x86_64-uec}
type: OS::Nova::Server
4. Add a second component to env. No changes to stacks.
5. Deploy env. Two existing stacks are updated (no changes to their
template). A new stack is created.
template for stack 3:
description: Simple template to deploy a single cirros instance
heat_template_version: '2014-10-16'
resources:
~~my_instance:
properties: {flavor: m1.small, image: ubuntu-trusty-amd64}
type: OS::Nova::Server
Basically, for each component addition I see a new stack is created with
only resources from that component in it.
Am I missing something?
Regards,
-
Vahid Hashemian, Ph.D.
Advisory Software Engineer, IBM Cloud Labs
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
Hi, Murano documentation about all internals is here: http://murano.readthedocs.org/en/latest/ You probably need to take some example applications from here: https://github.com/openstack/murano-apps Take something simple like Tomcat and PostgresSQL. You will need to have an image for Ubuntu/Debian with murano agent. It could be downloaded form here: http://apps.openstack.org/#tab=glance-imagesasset=Debian%208%20x64%20(pre-installed%20murano-agent) http://apps.openstack.org/#tab=glance-imagesasset=Debian%208%20x64%20(pre-installed%20murano-agent) Thanks Gosha On Wed, Jun 3, 2015 at 2:21 PM, Vahid S Hashemian vahidhashem...@us.ibm.com wrote: Thanks Gosha. That's right. I have been using HOT based applications. I have not used workflows before and need to dig into them. If you have any pointers on how to go about workflows please share them with me. Thanks. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
Hi Vahid, Thank you for sharing your thoughts. I have a questions about application life-cycle if we use TOSCA translator. In Murano the main advantage of using HOT format is that we can update Het stack with resources as soon as we need to deploy additional application. We can dynamically create multi-tier applications with using other apps as a building blocks. Imagine Java app on tom of Tomcat (VM1) and PostgreDB (VM2). All three components are three different apps in the catalog. Murano allows you to bring them and deploy together. Do you think it will be possible to use TOSCA translator for Heat stack updates? What we will do if we have two apps with two TOSCA templates like Tomcat and Postgre. How we can combine them together? Thanks Gosha On Tue, Jun 2, 2015 at 12:14 PM, Vahid S Hashemian vahidhashem...@us.ibm.com wrote: This is my what I have so far. Would love to hear feedback on it. Thanks. Regards, - *Vahid Hashemian, Ph.D.* Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Help needed with TOSCA support in Murano
When you update an environment in Murano it will update underlying stack. You should not see a new stack for the same environment. If you have a PostgresDB deployed and then add a Tomcat application you will see that stack was updated with new resources. There is no dependency between Tomcat and PostgresDB so deployment will just update Heat stack with independent resources (new Nova:Server will be added). Murano will never add a new stack for existing environment when you update it. There is no such logic in the code for sure, a single Heat stack nailed down to environment and each deployment will do stack update calls. Thanks Gosha On Tue, Jun 2, 2015 at 5:59 PM, Vahid S Hashemian vahidhashem...@us.ibm.com wrote: In other words, can a new component that is being to an environment have dependency on the existing ones? If so, how does that defined? For example, going back to your example of a multi-tier application, if I initially have PostgreDB in my environment, and later add Tomcat, how do I tell Tomcat the PostgreDB connection info? Would it be manually done through component parameters? Or there are other dynamic ways of discovering it? Thanks. Regards, - Vahid Hashemian, Ph.D. Advisory Software Engineer, IBM Cloud Labs __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
and that is it. So wearing my OpenStack developer hat on, why did you go with linode and not any one of the OpenStack based public clouds [1]? If OpenStack is not a good solution for workloads like this, then it would be great to know how what needs work. [1] https://www.openstack.org/marketplace/public-clouds/ There were a ton of great ideas that came up and it was clear there was WAY more to discuss than we could accomplish in one short session at the summit. I’m looking forward to continuing the conversation here on the mailing list, on IRC, and in Tokyo as well! [1] https://etherpad.openstack.org/p/YVR-app-catalog-plans -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [new][app-catalog] App Catalog next steps
I think the next logical step is to add versioning and predefined tags so we can distinguish application versions and application status. Right now the catalog has just information about application without any strict schema enforced. The separate problem is to how this information should be handled by OpenStack services. Potentially it should be done by Artifact repository during the import phase. It will be nice to meet with Glance team and discuss this so we can draft this import process land something in L release. Thanks Gosha On Fri, May 29, 2015 at 3:16 PM, Christopher Aedo ca...@mirantis.com wrote: On Fri, May 29, 2015 at 9:55 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I really really want to replace one image with a new one atomically with security updates preapplied. Think shellshock, ghost, etc. It will be basically be the same exact image as before, but patched. On Fri, May 29, 2015 at 11:16 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: I believe that current app store approach uses only image name rather then ID. So you can replace image with a new one without affecting application definitions. In my opinion this is a pretty serious shortcoming with the app catalog as it stands right now. There's no concept of versions for catalog assets, only whatever is put in with the asset name. It's not obvious when the binary component of an asset has been replaced for instance. Maybe the latest one has the security updates applied, maybe it doesn't? If you are watching the repo you might catch it, but that's not very use friendly. We are also unable to account for duplicate names currently (i.e. no protection against having two identically named glance images). I think the easiest way to handle at least the versions is by including additional information in the metadata. If we eventually switch to using the artifacts implementation in glance, I think some of this is resolved, but a switch like that is a long way off. Any thoughts on what we could do in the near term? -Christopher __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [murano] oslo namespace changes and murano-dashboard
Hi, We do monitor both IRC and openstack-dev. #murano is our IRC channel. Most of the time there are someone who can respond quickly. Mirantis and Telefonica guys are located in Europe so they will respond during US morning but not during US day time. HP guys are US based so they can respond more quickly in US timezones. As for the releases, murano-dashboard is installed from master on the gates, so it should already be compatible with oslo changes, but python-muranoagent is release based and we need to release a new version and upload it to pip repository as it is installed via pip. Thanks Gosha On Fri, May 29, 2015 at 9:34 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-05-29 12:28:37 -0400 (-0400), Doug Hellmann wrote: First, where do you hang out on IRC? I couldn’t find a channel that looked like it had any population, and there’s nothing mentioned on https://wiki.openstack.org/wiki/Murano [...] https://wiki.openstack.org/wiki/IRC says it's #murano (though I haven't /joined to see if anyone actually uses it, I would assume they do). -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session
questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org? subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org? subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - -- @flaper87 Flavio Percoco _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev - -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVVSaFAAoJEB7Z2EQgmLX7n/UP/12bkw4AYg+JrSh1WcgAYvxV XUB6yEaNv/I363OdY0pu6VQYW7w9IkCR3a0hkLGc6zBATab0gUVpnyWGBa+NWvMe HcyMTx82KgGIQ3uLW6NCyzmyW+CE5R5gEHnR/UhXLZmtyeiiTF4tgMN+pdTONF46 PfpoZzVkP3YRufvfCV7f1RdiZuavPD/m1VS29If0l70VEeYxUM5mPqKFwbrqhvfs 52HdzNUcb2xMiy71xfCZ9wosTGf2JzdVLy+Di5kJCACx2EYRL45VzIZzeNU37z70 AAcky6jN5mXn47/THQ+4D1su79/zQ6Ue9MVQWn4QA/IzBB/TMUWDC/1sGN4T4dXw Lfvq7BnLDzVmX39ei+Ae9kpYppiCkLwdm7j7FEu6W8QfCwH8JcRXsHFkY/6GwkPz gr7XylUtBnzv3oFU6GB63EAjsuDOOx+CZB1IAUZFjwtLEP+Gr04jcCMgkXc9Z7Bj l80NEkJ0ezqZUSQHPB0bZxcWBxP21xm72t6UGvWwmtE1qILwjE3o3o8G3sX+zVWT yJwT1wMgp79NfB1Mwl3OsV3DGIONraHU0lsFTIZwiHnUlagBiJir8i/SGbTfB6T2 dvQuBjArj+qKhQU7ohrK+TPhMMeGIcHnzzF1uwjKM+v0qu9ob1LbMYGyvm92PkBy 8dZgefSM5m3DqYJqwQ2w =SpuM -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session
I think Sergey will present Murano team. I added him to CC as he probably filters out Zaqar and Trove e-mails. Thanks Gosha On Wed, May 20, 2015 at 10:34 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, What is the final decision about this discussion? When will it happen? thanks Gosha On Thu, May 14, 2015 at 3:49 PM, Douglas Mendizábal douglas.mendiza...@rackspace.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm very much interested in talking with some Keystone folks about this auth issue. I would be willing to dedicate a Barbican Working Session to this discussion if there is a time slot that works for all the interested parties. - - Douglas Mendizabal On 5/14/15 3:13 PM, Fox, Kevin M wrote: If there's a free session, can we dedicate a session specifically to the zaqar, barbican, sahara, heat, trove, guestagent, keystone auth thingy so everyone's all together? Thanks, Kevin From: Flavio Percoco [fla...@redhat.com] Sent: Thursday, May 14, 2015 12:15 PM To: Sergey Lukjanov Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session On 14/05/15 10:07 -0700, Sergey Lukjanov wrote: Hey, in Sahara we're looking on using Zaqar as a transport for agent some day as well. Unfortunately this section overlaps with Sahara sessions. Sergey, We still have some free sessions, we'd be happy to dedicate one to Sahara. Any slot that looks good for you? http://libertydesignsummit.sched.org/overview/type/design+summit/Zaqar #.VVT0CvYU9hE http://libertydesignsummit.sched.org/overview/type/design+summit/Zaqar#.VVT0CvYU9hE Thanks, Flavio On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco fla...@redhat.com wrote: On 13/05/15 18:06 +, Fox, Kevin M wrote: Sahara also has the same problem, but worse, since they currently only support ssh with their agent, so its either assign floating ip's to all nodes, or your sahara controller must be on your one and only network node so it can tunnel. :/ Should we have a chat with them too? We've scheduled a discussion with Trove's team on Thursday at 5pm. It'd be great to have this discussion once and together to know what the common issues are and what things need to be done. I'll ping folks from both teams to invite them to this session. If they can't make it, I'm happy to use another working session slot. Cheers, Flavio http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b679 2e1cef http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b6792e1cef #.VVRL0PYU9hE Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Wednesday, May 13, 2015 10:26 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session On 11/05/15 05:49, Flavio Percoco wrote: On 08/05/15 00:45 -0700, Nikhil Manchanda wrote: 3) The trove-guest-agent is in vm. it is connected by taskmanager by rabbitmq. We designed it. But is there some prectise to do this? how to make the vm be connected in vm-network and management network? Most deployments of Trove that I am familiar with set up a separate RabbitMQ server in cloud that is used by Trove. It is not recommended to use the same infrastructure RabbitMQ server for Trove for security reasons. Also most deployments of Trove set up a private (neutron) network that the RabbitMQ server and guests are connected to, and all RPC messages are sent over this network. We've discussed trove+zaqar in the past and I believe some folks from the Trove team have been in contact with Fei Long lately about this. Since one of the projects goal's for this cycle is to provide support to other projects and contribute to the adoption, I'm wondering if any of the members of the trove team would be willing to participate in a Zaqar working session completely dedicated to this integration? +1 I learned from a concurrent thread ([Murano] [Mistral] SSH workflow action) that Murano are doing exactly the same thing with a separate RabbitMQ server to communicate with guest agents. It's a real waste of energy when multiple OpenStack projects all have to solve the same problem from scratch, so a single answer to this would be great. In that thread I suggested (and Murano developers agreed with) making the transport pluggable so that operators could choose Zaqar instead. I would strongly support doing the same here. +1 :) Flavio cheers, Zane. It'd be a great opportunity to figure out what's really needed, edge cases and get some work done on this specific case. Thanks, Flavio
Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session
We will have someone from Murano team also on this session. This topic is really hot for most of app level projects in OpenStack. Thanks Gosha On Thu, May 14, 2015 at 10:07 AM, Sergey Lukjanov slukja...@mirantis.com wrote: Hey, in Sahara we're looking on using Zaqar as a transport for agent some day as well. Unfortunately this section overlaps with Sahara sessions. On Thu, May 14, 2015 at 12:19 AM, Flavio Percoco fla...@redhat.com wrote: On 13/05/15 18:06 +, Fox, Kevin M wrote: Sahara also has the same problem, but worse, since they currently only support ssh with their agent, so its either assign floating ip's to all nodes, or your sahara controller must be on your one and only network node so it can tunnel. :/ Should we have a chat with them too? We've scheduled a discussion with Trove's team on Thursday at 5pm. It'd be great to have this discussion once and together to know what the common issues are and what things need to be done. I'll ping folks from both teams to invite them to this session. If they can't make it, I'm happy to use another working session slot. Cheers, Flavio http://libertydesignsummit.sched.org/event/59dc6ec910a732cdbf5970b6792e1cef#.VVRL0PYU9hE Thanks, Kevin From: Zane Bitter [zbit...@redhat.com] Sent: Wednesday, May 13, 2015 10:26 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [trove][zaqar] Trove and Zaqar integration. Summit working session On 11/05/15 05:49, Flavio Percoco wrote: On 08/05/15 00:45 -0700, Nikhil Manchanda wrote: 3) The trove-guest-agent is in vm. it is connected by taskmanager by rabbitmq. We designed it. But is there some prectise to do this? how to make the vm be connected in vm-network and management network? Most deployments of Trove that I am familiar with set up a separate RabbitMQ server in cloud that is used by Trove. It is not recommended to use the same infrastructure RabbitMQ server for Trove for security reasons. Also most deployments of Trove set up a private (neutron) network that the RabbitMQ server and guests are connected to, and all RPC messages are sent over this network. We've discussed trove+zaqar in the past and I believe some folks from the Trove team have been in contact with Fei Long lately about this. Since one of the projects goal's for this cycle is to provide support to other projects and contribute to the adoption, I'm wondering if any of the members of the trove team would be willing to participate in a Zaqar working session completely dedicated to this integration? +1 I learned from a concurrent thread ([Murano] [Mistral] SSH workflow action) that Murano are doing exactly the same thing with a separate RabbitMQ server to communicate with guest agents. It's a real waste of energy when multiple OpenStack projects all have to solve the same problem from scratch, so a single answer to this would be great. In that thread I suggested (and Murano developers agreed with) making the transport pluggable so that operators could choose Zaqar instead. I would strongly support doing the same here. +1 :) Flavio cheers, Zane. It'd be a great opportunity to figure out what's really needed, edge cases and get some work done on this specific case. Thanks, Flavio __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
+1. Is it a separate e-mail thread or IRC meeting? Thanks Gosha On Wed, May 13, 2015 at 10:21 AM, Fox, Kevin M kevin@pnnl.gov wrote: it seems like the trove/zaqar guys are talking about a very similar topic at the exact same time. :/ Maybe it would be a good time for all parties to get together and chat? Thanks, Kevin -- *From:* Stan Lagun [sla...@mirantis.com] *Sent:* Tuesday, May 12, 2015 11:52 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action On Wed, May 13, 2015 at 2:46 AM, Fox, Kevin M kevin@pnnl.gov wrote: Awesome. When is it/where do I go to look up that info? http://sched.co/3Clo Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
an alternative to Rabbit for communicating to the Murano agent. * Use your experience in implementing notifications over email and the like in Mistral to help the Zaqar team to add the notification features they've long been planning. These could take the form of microservices listening on a Zaqar queue. You get the reliable, asynchronous queuing semantics for free and *every* service and user can benefit from your work. Imagine if there were one place where we implemented reliable queuing semantics at cloud scale, and when we added e.g. long-polling or WebSockets everyone could benefit immediately.[4] Imagine if there were one place for notifications, at cloud scale, for operators to secure. (How many webhook implementations are there in OpenStack right now? How many of them are actually secure against malicious users?) One format for messages between services so that users can connect up their own custom pipelines. We're not that far away! All of this is within reach if we work together. Thanks for reading. Please grab me at summit if you want to know more; I am always happy to bend the ear of anyone who will listen at length on this topic. As usual, I'll be the tall dude with the weird accent ;) cheers, Zane. [1] https://review.openstack.org/#/c/180112/ [2] http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html [3] http://lists.openstack.org/pipermail/openstack-dev/2015-April/062617.html [4] http://lists.openstack.org/pipermail/openstack-dev/2015-April/062619.html On 06/05/15 11:42, Filip Blaha wrote: Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
+1 for Keystone based solution. Keystone is an identity service for OpenStack so we have to make sure that Keystone supports our use case for authentication and authorization for clients inside VMs. Thanks Gosha On Tue, May 12, 2015 at 10:32 AM, Fox, Kevin M kevin@pnnl.gov wrote: Barbican has the same issue. If Barbican is for storing secrets, how do you get a secret to the VM so it can get its secrets from Barbican? Aaaggg! :) I've been working on a solution here: https://blueprints.launchpad.net/barbican/+spec/vm-integration We're planning on talking more about that spec at the summit though. I've heard through the grape vine that Amazon lets you have a machine account that is associated with the vm. I'm not sure that's true or not, but some kind of keystone account integration into nova might help... Thanks, Kevin -- *From:* Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com] *Sent:* Tuesday, May 12, 2015 10:06 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action There is one thing which still bothers me. It is authentication. Right now with separate RabbitMQ instance we keep VMs authentication isolated from OpenStack infra. This is still a problem if you want to use webhooks (Heat autoscaling, Murano actions) via our own authentication models. If we plan to use Zaqar it will be interesting to know how Zaqar solves this issue. Frankly, I don't think that this is a good idea to use Keystone credentials or tokens for MQ clients on VMs. This topic, probably, deserves its own e-mail thread. It will be interesting to discuss this with Keystone team. What is it is possible to have a token which is restricted to be authenticated to specific API URL like GET /v1/queues/queue-id/ Thanks Gosha On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M kevin@pnnl.gov wrote: +1 From: Zane Bitter [zbit...@redhat.com] Sent: Monday, May 11, 2015 6:15 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello! This looks like a perfect soapbox from which to talk about my favourite issue ;) You're right about the ssh idea, for the reasons discussed related to networking and a few more that weren't (e.g. users shouldn't have to and generally don't want to give their private SSH keys to cloud services). I didn't know, or had forgotten, about the message queue implementation in Murano and while I think that's the correct shape for the solution, as long as the service in question is not multi-tenant capable it's a non-starter for a public clouds at least and probably many private clouds as well (after all, if you don't need multi-tenancy then why are you using OpenStack?). There's been a tendency within the application-facing OpenStack projects to hack together whatever local solutions to problems that we can in order to make progress without being held up by other projects. Let's take a moment to acknowledge that Heat is both the earliest and the biggest offender here, and that I am as culpable as anyone in the current state of affairs. There are multiple reasons for how things have gone - part of it is that it turned out we developed services in the wrong order, starting at too high a level. Part of it, frankly, is due to that element of the community that maintains a hostile position toward application-facing services and have used their influence in the community to maintain a disincentive against integrating projects together.[1] (If deployment of your project is discouraged that's one thing, but if it depends on another project whose deployment is also being discouraged then the hurdle you have to jump over is twice the height.) That said, I think we're at the point where we are hurting ourselves more than anyone else is by failing to come up with coherent, cross-project solutions. The problem articulated in this thread is not an isolated one. It's part of a more general pattern that affects a lot of projects: we need a way for the cloud to communicate to applications running in it. Angus started a recent discussion of this already on the list.[2] The requirements, IMHO, are roughly: * Reliability - we must be able to guarantee delivery to applications * Asynchrony - the cloud cannot block on user-controlled processes * Multitenancy - this is table stakes for OpenStack * Access control - even within tenants, we need to trust guest VMs minimally IMNSHO Zaqar messages are the obvious choice for the transport here. (Or something very similar in shape to Zaqar - but it'd be much better to join forces with the Zaqar team to improve it where necessary than to start a new project.) I really believe that if we work together to come up with consistent solutions to these problems that keep popping up
Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments
if your interested in CloudPulse to fill out the doodle poll here: https://doodle.com/kcpvzy8kfrxe6rvb The initial core team is composed of Ajay Kalambur, Behzad Dastur, Ian Wells, Pradeep chandrasekhar, Steven DakeandVinod Pandarinathan. I expect more members to join during our initial meeting. A little bit about CloudPulse: Cloud operators need notification of OpenStack failures before a customer reports the failure. Cloud operators can then take timely corrective actions with minimal disruption to applications. Many cloud applications, including those I am interested in (NFV) have very stringent service level agreements. Loss of service can trigger contractual costs associated with the service. Application high availability requires an operational OpenStack Cloud, and the reality is that occascionally OpenStack clouds fail in some mysterious ways. This project intends to identify when those failures occur so corrective actions may be taken by operators, tenants, and the applications themselves. OpenStack is considered healthy when OpenStack API services respond appropriately. Further OpenStack is healthy when network traffic can be sent between the tenant networks and can access the Internet. Finally OpenStack is healthy when all infrastructure cluster elements are in an operational state. For information about blueprints check out: https://blueprints.launchpad.net/cloudpulse https://blueprints.launchpad.net/python-cloudpulseclient For more details, check out our Wiki: https://wiki.openstack.org/wiki/Cloudpulse Plase join the CloudPulse team in designing and implementing a world-class Carrier Grade system for checking the health of OpenStack clouds. We look forward to seeing you on IRC on #openstack-cloudpulse. Regards, Vinod Pandarinathan [1] https://github.com/openstack-dev/cookiecutter __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments
Murano itself does not provide any monitoring. The idea here is to expose any application capabilities to do this. In this demo we had Java application deployed on Tomcat VM and connected to PostgreDB. Java app workflow executed Nagios application methods to register itself in Nagios monitoring system by adding proper IP, port, URL information for standard Nagios HTTP probes. Nagios itself has capabilities to send notifications to any other services like e-mail, IM or custom (Murano, Heat etc via simple bash\curl scripts). So, if you want to have monitoring for you apps, then you probbaly will need to modify Nagios application in murano to expose registration and e-mail setup for end users. Then Nagios will send notifications to user rather then to Murano. Another option is to add specific workflows actions in Murano or register Mistral workflow to react to Nagios monitoring event. The last, but not the least option for application will be a set of actions for some critical events. Application itself detects problems, like error in DB transactions, and it sends POST request to action URL. Action will call a workflow which will use monitoring application interface to trigger an event in monitoring system. The idea here is that application itself does not know beforehand which monitoring service is used, but it has a requirement to have monitoring service available with know interface implemented as Murano methods. I am not sure if I am good with explaining all this :-) Plenty of options available, but still they require some amount of work. Thanks Gosha On Tue, May 12, 2015 at 5:07 PM, Fox, Kevin M kevin@pnnl.gov wrote: Cool, but using nagios or the like to trigger app level actions is not what I'm primarily interested in. Mostly the reverse. Its for the app definition to provide the information nessisary for a monitoring system to report to the user when something is very wrong and needs intervention. For example, the website is unresponsive because the backend database server in the demo goes offline, or the maximum number of servers is already been reached and the site responsiveness is bad due to excessive load. Murano doesn't do that currently, does it? Thanks, Kevin -- *From:* Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com] *Sent:* Tuesday, May 12, 2015 2:04 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments Here is the way how we do VM level monitoring in application catalog. There is an application Nagios which will deploy a Nagios VM to the user tenant. And this Nagios application exposes abstracted monitoring app interface to add probes and checks. Another application, Ceilometer Alarm also allows you to use the same monitoring interface to add check for a VM. Demo is here: https://www.youtube.com/watch?v=OvPpJd0EOFw As usual Heat is used under the hood for infrastructure level management. You can add other monitoring apps like Zabbix ( https://github.com/openstack/murano-apps/tree/master/ZabbixAgent/package, https://github.com/openstack/murano-apps/tree/master/ZabbixServer/package) Thanks Gosha On Tue, May 12, 2015 at 1:31 PM, Fox, Kevin M kevin@pnnl.gov wrote: It totally depends on how much experience you think a tenant user has... If we're talking about devops, they tend to have the skills to stand up a configuration management server, a monitoring server, and manage everything via config management. If tenant users are research scientists, like some of ours, its a fair amount of work to manage nagios without config management, and config management is way more effort then most researchers want to put into learning. That's where an app catalog becomes important, and something like monitoring as a service starts to become interesting Thanks, Kevin From: Jay Pipes [jaypi...@gmail.com] Sent: Tuesday, May 12, 2015 12:50 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments On 05/12/2015 02:16 PM, Fox, Kevin M wrote: Nagios/watever As A Service would actually be very useful I think. I don't really understand why Nagios-as-a-Service would be useful to operators. I mean, operators install their monitoring system of choice via their configuration management tool of choice -- Ansible, SaltStack, Puppet, Chef, etc. Frankly, so do tenants. Tenants install software on their images using configuration management tools like mentioned above... I don't see a reason to have Nagios-as-a-Service for tenants either. Setting up a monitoring server is a fair amount of work. Not really. It's typically a simple apt-get install nagios-nrpe-plugins on client VMs along with an apt-get install nagios-server on one or more
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
I would encourage everyone to listen Zane. I think Zaqar is the way to go for Murano. It is not the first time when someone asks as to switch MQ technologies. Remember our journey with ZeroMQ? Lets meet with Zaqar team on the summit and discuss what we can do together. As I remember Zaqar even had AMQ support on their roadmap but nothing prevents us to use their HTTP based client. It will be also great if we can share the client with Heat. I don't see any reason why we can't use one generic agent for software orchestration side. The only different between Heat and Murano there is in declarative vs. imperative approach. Most of the time Heat software orchestration is enough but in some cases like executing the same script multiple times on master node to register minions imperative approach is just more flexible. Thanks Gosha On Tue, May 12, 2015 at 6:44 AM, Stan Lagun sla...@mirantis.com wrote: +1 for making Murano Engine - Murano Agent communication plugable so that one can switch to Zaqar or anything else. However watching RabbitMQ development for years I know hard can it be to build efficient and reliable system and I'm just not sure Zaqar can compete with such battle-proven thing like RabbitMQ yet. The only advantage I see is multi-tenancy. But I do believe it can be relatively easy be implemented with RabbitMQ. At lease in Murano. Don't want to go off topic here. The main idea is to use https://github.com/rabbitmq/rabbitmq-auth-backend-amqp and dynamically grant agent permissions only to his dedicated input queue so that it cannot access anything else. Not just other tenants queues but also queues of other VMs in the same tenant. In case of Murano we will not need to maintain additional secrets or databases. Neither it will be needed to create RabbitMQ users/vhosts as all of this becomes virtual. And agent will not be holding any RabbitMQ passwords at all Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis sla...@mirantis.com On Tue, May 12, 2015 at 10:52 AM, Renat Akhmerov rakhme...@mirantis.com wrote: Zane, Fully agree with you vision here. On 12 May 2015, at 07:15, Zane Bitter zbit...@redhat.com wrote: * Add an action in Mistral for sending a message to a Zaqar queue. This is easy and there's no reason you couldn't do it right now. Any volunteers? * Add a way to trigger a Mistral workflow with a Zaqar message. This is one piece in the puzzle to build user-configurable messaging flows between OpenStack services.[3] I added an agenda item for the summit in https://etherpad.openstack.org/p/vancouver-2015-design-summit-mistral to discuss this. Everyone is welcome. Imagine if there were one place where we implemented reliable queuing semantics at cloud scale, and when we added e.g. long-polling or WebSockets everyone could benefit immediately.[4] Imagine if there were one place for notifications, at cloud scale, for operators to secure. (How many webhook implementations are there in OpenStack right now? How many of them are actually secure against malicious users?) One format for messages between services so that users can connect up their own custom pipelines. We're not that far away! All of this is within reach if we work together. Cool picture of a wonderful future :) Thanks for reading. Please grab me at summit if you want to know more; I am always happy to bend the ear of anyone who will listen at length on this topic. As usual, I'll be the tall dude with the weird accent ;) With the great pleasure. (P.S. your accent is cool!) Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
Yes, Rabbit MQ is kind of shared. Each VM gets its own Queue which is dynamically created in MQ when application is being deployed. Technically we can create separate MQ users and virtual hosts for each VM, but this is an overkill for now. So by default it is just separate Queue with random generated name. If you want more protection you wiull have to change Murano default behaviour by adding a new vhost for each tenant. Thanks Gosha On Thu, May 7, 2015 at 10:26 AM, Fox, Kevin M kevin@pnnl.gov wrote: So... rabbit is not multitenant I think. You share a rabbit across multiple tenants's vms? How do you protect one tenant's vm's from getting commands sent to it by another tenant? Thanks, Kevin -- *From:* Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com] *Sent:* Thursday, May 07, 2015 9:18 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action Hi, When we use Murano in production there is a MQ service which is running on OpenStack controllers but it listens on public interface. It means that both Murano which is running on OpenStack controllers and Agent on VMs have an access to this MQ via external (public) network. When Murano creates a new deployment it actually deploys a private network and attach it to the router which acts as a gateway to external networking. So it is specific application deployment topology which allows VMs to communicate with MA via external network. Thanks Gosha On Thu, May 7, 2015 at 1:28 AM, Filip Blaha filip.bl...@hp.com wrote: yes. I agree that direction is important from only networking piont of view. Usually is more probable that VM on neutron network will be able to access O~S service ( VM -- rabbit) then opposite direction from O~S service to VM running on neutron network (mistral -- VM). Filip On 05/06/2015 06:39 PM, Georgy Okrokvertskhov wrote: Connection direction here is important only in the frame of networking connectivity problem solving. The networking in OpenStack in general works in such a way so that connections from VM are allowed to almost anywhere. In Murano production deployment we use separate MQ instance so that VMs have no access to OpenStack MQ. In the sense who initiates task execution it always a Murano service which publishes tasks (shell script + necessary files) in the MQ so that agent can pull them and execute. Thanks Gosha On Wed, May 6, 2015 at 9:31 AM, Filip Blaha filip.bl...@hp.com wrote: Hello one more note on that. There is difference in direction who initiates connection. In case of murano agent -- rabbit MQ is connection initiated from VM to openstack service(rabbit). In case of std.ssh mistral action is direction opposite from openstack service (mistral) to ssh server on VM. Filip On 05/06/2015 06:00 PM, Pospisil, Radek wrote: Hello, I think that the generic question is - can be O~S services also accessible on Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were discussing this today and we were not make a final decision. Another example is Murano agent running on VMs - it connects to RabbitMQ which is also accessed by Murano engine Regards, Radek -Original Message- From: Blaha, Filip Sent: Wednesday, May 06, 2015 5:43 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
Hi, When we use Murano in production there is a MQ service which is running on OpenStack controllers but it listens on public interface. It means that both Murano which is running on OpenStack controllers and Agent on VMs have an access to this MQ via external (public) network. When Murano creates a new deployment it actually deploys a private network and attach it to the router which acts as a gateway to external networking. So it is specific application deployment topology which allows VMs to communicate with MA via external network. Thanks Gosha On Thu, May 7, 2015 at 1:28 AM, Filip Blaha filip.bl...@hp.com wrote: yes. I agree that direction is important from only networking piont of view. Usually is more probable that VM on neutron network will be able to access O~S service ( VM -- rabbit) then opposite direction from O~S service to VM running on neutron network (mistral -- VM). Filip On 05/06/2015 06:39 PM, Georgy Okrokvertskhov wrote: Connection direction here is important only in the frame of networking connectivity problem solving. The networking in OpenStack in general works in such a way so that connections from VM are allowed to almost anywhere. In Murano production deployment we use separate MQ instance so that VMs have no access to OpenStack MQ. In the sense who initiates task execution it always a Murano service which publishes tasks (shell script + necessary files) in the MQ so that agent can pull them and execute. Thanks Gosha On Wed, May 6, 2015 at 9:31 AM, Filip Blaha filip.bl...@hp.com wrote: Hello one more note on that. There is difference in direction who initiates connection. In case of murano agent -- rabbit MQ is connection initiated from VM to openstack service(rabbit). In case of std.ssh mistral action is direction opposite from openstack service (mistral) to ssh server on VM. Filip On 05/06/2015 06:00 PM, Pospisil, Radek wrote: Hello, I think that the generic question is - can be O~S services also accessible on Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were discussing this today and we were not make a final decision. Another example is Murano agent running on VMs - it connects to RabbitMQ which is also accessed by Murano engine Regards, Radek -Original Message- From: Blaha, Filip Sent: Wednesday, May 06, 2015 5:43 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
Hi, From Murano experience I can tell you that ssh to VM in general case will not work. In order to have an ssh access you will have to assign floating IPs so that Mistral service will be able to connect to VM. That is exactly the reason why Murano uses agent and MQ mechanism when client on VM initiates a connection. I believe the same issue was in Sahara when they used direct ssh connections to VMs. Thanks Gosha On Wed, May 6, 2015 at 9:00 AM, Pospisil, Radek radek.pospi...@hp.com wrote: Hello, I think that the generic question is - can be O~S services also accessible on Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were discussing this today and we were not make a final decision. Another example is Murano agent running on VMs - it connects to RabbitMQ which is also accessed by Murano engine Regards, Radek -Original Message- From: Blaha, Filip Sent: Wednesday, May 06, 2015 5:43 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
Connection direction here is important only in the frame of networking connectivity problem solving. The networking in OpenStack in general works in such a way so that connections from VM are allowed to almost anywhere. In Murano production deployment we use separate MQ instance so that VMs have no access to OpenStack MQ. In the sense who initiates task execution it always a Murano service which publishes tasks (shell script + necessary files) in the MQ so that agent can pull them and execute. Thanks Gosha On Wed, May 6, 2015 at 9:31 AM, Filip Blaha filip.bl...@hp.com wrote: Hello one more note on that. There is difference in direction who initiates connection. In case of murano agent -- rabbit MQ is connection initiated from VM to openstack service(rabbit). In case of std.ssh mistral action is direction opposite from openstack service (mistral) to ssh server on VM. Filip On 05/06/2015 06:00 PM, Pospisil, Radek wrote: Hello, I think that the generic question is - can be O~S services also accessible on Neutron networks, so VM (created by Nova) can access it? We (I and Filip) were discussing this today and we were not make a final decision. Another example is Murano agent running on VMs - it connects to RabbitMQ which is also accessed by Murano engine Regards, Radek -Original Message- From: Blaha, Filip Sent: Wednesday, May 06, 2015 5:43 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Mistral] SSH workflow action
On Wed, May 6, 2015 at 9:26 AM, Fox, Kevin M kevin@pnnl.gov wrote: If your Mistral engine is on the same host as the network node hosting the router for the tenant, then it would probably work there are a lot of conditions in that statement though... Too many for my tastes. :/ While I dislike agents running in the vm's, this still might be a good use case for one... This would also probably be a good use case for Zaqar I think. Have a generic run shell commands from Zaqar queue agent, that pulls commands from a Zaqar queue, and executes it. The vm's don't have to be directly reachable from the network then. You just have to push messages into Zaqar. From Murano's perspective though, maybe it shouldn't care. Should Mistral abstract away how to execute the action, leaving it up to Mistral how to get the action to the vm? If that's the case, then ssh vs queue/agent is just a Mistral implementation detail? Maybe the OpenStack Deployer chooses what's the best route for their cloud? Thanks, Kevins +1 for MQ. That is the path which proved itself to be working in most of the cases. -1 for ssh as this is a big headache. Thanks, Gosha From: Filip Blaha [filip.bl...@hp.com] Sent: Wednesday, May 06, 2015 8:42 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Murano] [Mistral] SSH workflow action Hello We are considering implementing actions on services of a murano environment via mistral workflows. We are considering whether mistral std.ssh action could be used to run some command on an instance. Example of such action in murano could be restart action on Mysql DB service. Mistral workflow would ssh to that instance running Mysql and run service mysql restart. From my point of view trying to use SSH to access instances from mistral workflow is not good idea but I would like to confirm it. The biggest problem I see there is openstack networking. Mistral service running on some openstack node would not be able to access instance via its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed via ssh from namespace of its gateway router e.g. ip netns exec qrouter-... ssh cirros@10.0.0.5 but I think it is not good to rely on implementation detail of neutron and use it. In multinode openstack deployment it could be even more complicated. In other words I am asking whether we can use std.ssh mistral action to access instances via ssh on theirs fixed IPs? I think no but I would like to confirm it. Thanks Filip __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Kubernetes AutoScaling with Heat AutoScalingGroup and Ceilometer
, persist data. It would also require a cooldown period before the node removal. There have been some discussions on sending messages, but so far I don't think there is a conclusion on the generic solution. Just my $0.02. Thanks Qiming. BTW, we have been looking into similar problems in the Senlin project. Great. We can probably discuss these during the Summit? I assume there is already a session on Senlin planned, right? Regards, Qiming Both requirement 2 and 3 would probably require generating scaling event notifications/signals for master and containers to consume and probably some ASG lifecycle hooks. Req 4: In case of too many 'pending' pods to be scheduled, scheduler would signal ASG to scale up. This is similar to Req 1. 2. Scaling Pods Currently manual scaling of pods is possible by resizing ReplicationControllers. k8s community is working on an abstraction, AutoScaler[2] on top of ReplicationController(RC) that provides intention/rule based autoscaling. There would be a requirement to collect cAdvisor/Heapster stats to signal the AutoScaler too. Probably this is beyond the scope of OpenStack. Any thoughts and ideas on how to realize this use-case would be appreciated. [1] https://review.openstack.org/gitweb?p=openstack%2Fceilometer-specs.git;a=commitdiff;h=6ea7026b754563e18014a32e16ad954c86bd8d6b [2] https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/proposals/autoscaling.md Regards, Rabi Mishra __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] heat delete woes in Juno
I attached an example of the template which is hanging right now in my Juno environment. I believe it hangs because of floating ip stuff and the way how it is attached to a VM. It is autogenerated, so please don't be disturbed by strange resource names. Thanks Gosha On Thu, Mar 26, 2015 at 12:15 PM, Ala Rezmerita ala.rezmer...@cloudwatt.com wrote: Hi Matt I had similar problems with heat, and the work-around that i used is to abandon the stack (heat stack-abandon), and then I delete stack resources created one by one. Hope this helps. Ala Rezmerita Software Engineer || Cloudwatt M: (+33) 06 77 43 23 91 Immeuble Etik 892 rue Yves Kermen 92100 Boulogne-Billancourt – France -- *De: *Matt Fischer m...@mattfischer.com *À: *openstack-dev@lists.openstack.org *Envoyé: *Jeudi 26 Mars 2015 19:17:08 *Objet: *[openstack-dev] [heat] heat delete woes in Juno Nobody on the operators list had any ideas on this, so re-posting here. We've been having some issues with heat delete-stack in Juno. The issues generally fall into three categories: 1) it takes multiple calls to heat to delete a stack. Presumably due to heat being unable to figure out the ordering on deletion and resources being in use. 2) undeleteable stacks. Stacks that refuse to delete, get stuck in DELETE_FAILED state. In this case, they show up in stack-list and stack-show, yet resource-list and stack-delete deny their existence. This means I can't be sure whether they have any real resources very easily. 3) As a corollary to item 1, stacks for which heat can never unwind the dependencies and stay in DELETE_IN_PROGRESS forever. Does anyone have any work-arounds for these or recommendations on cleanup? My main worry is removing a stack from the database that is still consuming the customer's resources. I also don't just want to remove stacks from the database and leave orphaned records in the DB. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 problematic-stack.hot Description: Binary data __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Avoiding regression in project governance
Some clarification about Murano: 3. *Maybe*. Not sure about the scope, it is fairly broad and there may be some open ended corners, such as some references to billing. On the other hand an application catalog sounds really useful and like a measured progression for OpenStack as a whole. Murano may overlap with glance's stated mission of To provide a service where users can upload and discover data assets that are meant to be used with other services, like images for Nova and templates for Heat. Glance mission was changed with active help from Murano team side as Murano needs to have a storage for Applications definitions. That is why one of the Murano engineers right now is working on landing Artifact repository which was initially drafted in Murano team and then re-architected to be useful for other projects like Heat and Nova. Once artifacts are landed in Kilo release[all patches are on review] Murano will use Glance to store all packages and related objects, so there will be no any overlap with Glance. Murano also relies heavily on the Mistral service which is still in stackforge itself. This is a wrong perception. Murano currently does not use Mistral at all. It will use it once cross project initiative Congress-Murano-Mistral will be implemented. Right now Murano works without Mistral installed. Murano will use congress and Mistral to offload some of the logic outside of Murano to have very simple life-cycle workflows controlled by policies and Mistral flows. Thanks Gosha On Wed, Mar 11, 2015 at 7:28 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-03-10 23:00:16 + (+), Devananda van der Veen wrote: Many of those requirements were subjective (well tested, well documented, etc) and had to be evaluated by the TC. Are these the sort of tags you're referring to? If so, and if the TC delegated responsibility to manage the application of those tags (say, QA team manages the 'well-tested' tag), would that be sufficient? [...] Yep, that's exactly what I'm hoping for. But without those in place yet I worry that we'll end up turning away lots of new requests for help from projects coming forward thinking they're suddenly entitled by virtue of being OpenStack and not really have any common criteria to point them at so that they can work toward getting more priority. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [API WG] Environment status
I think this is a good case for API WG as statuses of entities should be consistent among OpenStack APIs. As I recall, we are mixing two different statuses for environments. The first dimension for environment status is its content status: NEW, CONFIGURING, READY The second dimension is deployment status after Murano engine executes deployment action for this environment with statuses: NOT DEPLOYED, DEPLOYING, SUCCESS, FAIL Thanks Gosha On Thu, Feb 12, 2015 at 7:38 AM, Andrew Pashkin apash...@mirantis.com wrote: Initiall my interest to that problem was caused by the bug [1] due to whose once environment was deployed with failure it stays forever with that status even if it have been deployed sucessfully later. For now status determination happens in three stages: - If at least one of all sessions of env, regardless of version, is in DEPLOYING/DELETING or DEPLOY_FAILURE/DELETE_FAILURE states - state of that session taken as state of environment. Sessions prioritized by version and midification date. - If there is no such sessions, but at least one is in OPENED state - environment state will be PENDING. - Otherwise environment will have READY status. Accordingly to that - once session was deployed with failure - it stays in that status even if it was deployed successfully later. In UI statuses are taken directly from API except another calculated status NEW. Environment matches status NEW if it has version = 0 and it has apps with status 'pending' [2]. After discussion inside Mirantis Murano team we came to these thoughts: - We need to remove statuses that does not related to deployment (PENDING). - Introduce NEVER_DEPLOYED (or NEW) status. - Change READY to DEPLOYED. - Possibly we need to keep state in Environment table in DB and no calculate it queriyng session every time. PENDING status was needed to indicate that another user do something with the environment. But it was decided, that this information must be placed somwhere else, to not be in coflict with deployment status. Another proposal was to additionaly show if environment has some dirty/not-deployed changes in it. First of all let's discuss quick fix of the alghorithm of Environment status matching [3]. I propose to take status of last modified session as status of an environment. At second let's discuss overall situation and more extensive changes that we might want introduce. [1] https://bugs.launchpad.net/murano/+bug/1413260 [2] https://github.com/stackforge/murano-dashboard/blob/master/muranodashboard/environments/api.py#L140-140 [3] https://github.com/stackforge/murano/blob/017d25f49e60e18365a50756f524e15f8d4fa78a/murano/db/services/environments.py#L62 -- With kind regards, Andrew Pashkin. cell phone - +7 (985) 898 57 59 Skype - waves_in_fluids e-mail - apash...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] SQLite support - drop or not?
...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] SQLite support - drop or not?
Hi Andrew, I understand the difficulties with SQLite support, but this is very useful for development to have SQLite instead of any other DB. I think nodoby uses SQLite in production, so probably we can just put a release note that there is a know limitation with SQLite support. Thanks Gosha On Fri, Jan 23, 2015 at 10:04 AM, Andrew Pashkin apash...@mirantis.com wrote: Hello! Current situation with SQLite support: - Migration tests does not run on SQLIte. - At the same time migrations themselves support SQLite (with bugs). Today I came across this bug: Error during execution of database downgrade https://bugs.launchpad.net/murano/+bug/1399151 We can resolve this bug by hardening SQLite support, in that case: - We need to fix migrations and make them support SQLite without bugs, and then continuously make some effort to maintain this support (manually writing migrations and test cases for them). - Also need to introduce migration tests run on SQLite. We also can drop SQLite support and in this case: - We just factor out all that related to SQLite from migrations one time and set this bug as Won't fix. Let's discuss that. -- With kind regards, Andrew Pashkin. cell phone - +7 (985) 898 57 59 Skype - waves_in_fluids e-mail - apash...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Review Day on Monday
Hi, I will join to review on Monday from US time zone. I hope someone will be in IRC to chat. Thanks Georgy On Fri, Jan 16, 2015 at 7:45 AM, Serg Melikyan smelik...@mirantis.com wrote: Hi Team, I would like to announce another Review Day schedule on Monday (Jan 19). During New Year Christmas holidays our CI was broken, and queue with change-requests is now quote long. And what is more important, many patches and specs related to Policy Guided Fulfillment are need to be reviewed, we had not so much time to review them, and I propose to do it on Monday. -- Serg Melikyan, Senior Software Engineer at Mirantis, Inc. http://mirantis.com | smelik...@mirantis.com +7 (495) 640-4904, 0261 +7 (903) 156-0836 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Remove deprecation properties
. A - as possible we may leave old deprecated property and mark it something like (removed), which will have similar behavior such as for implemented=False. I do not like it, because it means, that we never remove this support code, because wants to be compatible with old resources. (User may be not very lazy to do simple update or something else ...) - last way, which I have not tried yet, is usingA _stored_properties_data forA extraction necessary information. So now I have the questions: Should we support such case with backward compatibility?A If yes, how will be better to do it for us and user? May be we should create some strategy forA removingA A deprecated properties ? Yeah, other than the process issues I mentioned above, Angus has pointed out some technical challenges which may mean property removal breaks existing stacks. IMHO this is something we *cannot* do - folks must be able to upgrade heat over multiple versions without breaking their stacks. As you say, delete may work, but it's likely several scenarios around update will break if the stored stack definition doesn't match the schema of the resource, and maintaining the internal references to removed or obsolete properties doesn't seem like a good plan long term. Could we provide some sort of migration tool, which re-writes the definition of existing stacks (via a special patch stack update maybe?) before upgrading heat? Yeah, I thought about it. Probably it's good solution for upgrading. However one thing stops me to start doing it right now: If we upgrade old resources and stored templates we will come to situation, when user's template and stored are different. And in this case user's template looks like invalid and can not be used without updating wrong properties. If we deal with it, I look forward to make this solution work. Steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Regards, Sergey. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Oslo.messaging error
Hi,
Could you, please, check what is in your murano.conf file. There are two
sections for rabbitmq configurations. Both of them should have proper IP
address of RabbitMQ service as well as proper user\password and vhost.
Also you could check if RabbitMQ is actually up and running and listens on
this port\IP. netstat -ltpn command output will help to check if there is
process listening on port 5672.
Hope this help,
Gosha
On Wed, Dec 10, 2014 at 8:25 PM, raghavendra@accenture.com wrote:
HI Team,
I am installing Murano on the Ubuntu 14.04 Juno setup and when I try the
below install murano-api I encounter the below error. Please assist.
When I install
I am using the Murano guide link provided below:
https://murano.readthedocs.org/en/latest/install/manual.html
I am trying to execute the section 7
1.Open a new console and launch Murano API. A separate terminal is
required because the console will be locked by a running process.
2. $ cd ~/murano/murano
3. $ tox -e venv -- murano-api \
4. --config-file ./etc/murano/murano.conf
I am getting the below error : I have a Juno Openstack ready and trying to
integrate Murano
2014-12-10 12:10:30.396 7721 DEBUG murano.openstack.common.service [-]
neutron.endpoint_type = publicURL log_opt_values
/home/
ubuntu/murano/murano/.tox/venv/local/lib/python2.7/site-packages/oslo/config/cfg.py:2048
2014-12-10 12:10:30.397 7721 DEBUG murano.openstack.common.service [-]
neutron.insecure = False log_opt_values
/home/ubun
tu/murano/murano/.tox/venv/local/lib/python2.7/site-packages/oslo/config/cfg.py:2048
2014-12-10 12:10:30.397 7721 DEBUG murano.openstack.common.service [-]
log_opt_values
/home/ubuntu/murano/murano/.tox/venv/local/lib/python2.7/site-packages/oslo/config/cfg.py:2050
2014-12-10 12:10:30.400 7721 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on controller:5672
2014-12-10 12:10:30.408 7721 INFO oslo.messaging._drivers.impl_rabbit [-]
Connecting to AMQP server on controller:5672
2014-12-10 12:10:30.416 7721 INFO eventlet.wsgi [-] (7721) wsgi starting
up on http://0.0.0.0:8082/
2014-12-10 12:10:30.417 7721 DEBUG murano.common.statservice [-] Updating
statistic information. update_stats
/home/ubuntu/murano/muran
o/murano/common/statservice.py:57
2014-12-10 12:10:30.417 7721 DEBUG murano.common.statservice [-] Stats
object:
murano.api.v1.request_statistics.RequestStatisticsColle
ction object at 0x7fada950a510 update_stats
/home/ubuntu/murano/murano/murano/common/statservice.py:58
2014-12-10 12:10:30.417 7721 DEBUG murano.common.statservice [-] Stats:
Requests:0 Errors: 0 Ave.Res.Time 0.
Per tenant: {} update_stats
/home/ubuntu/murano/murano/murano/common/statservice.py:64
2014-12-10 12:10:30.433 7721 DEBUG oslo.db.sqlalchemy.session [-] MySQL
server mode set to
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZER
O_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
_check_effective_sql_mode /hom
e/ubuntu/murano/murano/.tox/venv/local/lib/python2.7/site-packages/oslo/db/sqlalchemy/session.py:509
2014-12-10 12:10:33.464 7721 ERROR oslo.messaging._drivers.impl_rabbit [-]
AMQP server controller:5672 closed the connection. Check
log in credentials: Socket closed
2014-12-10 12:10:33.465 7721 ERROR oslo.messaging._drivers.impl_rabbit [-]
AMQP server controller:5672 closed the connection. Check
log in credentials: Socket closed
2014-12-10 12:10:37.483 7721 ERROR oslo.messaging._drivers.impl_rabbit [-]
AMQP server controller:5672 closed the connection. Check
log in credentials: Socket closed
2014-12-10 12:10:37.484 7721 ERROR oslo.messaging._drivers.impl_rabbit [-]
AMQP server controller:5672 closed the connection. Check
log in credentials: Socket closed
Warm Regards,
*Raghavendra Lad*
--
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise confidential information. If you have
received it in error, please notify the sender immediately and delete the
original. Any other use of the e-mail by you is prohibited. Where allowed
by local law, electronic communications with Accenture and its affiliates,
including e-mail and instant messaging (including content), may be scanned
by our systems for the purposes of information security and assessment of
internal compliance with Accenture policy.
__
www.accenture.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Re: [openstack-dev] [Mistral] Query on creating multiple resources
Hi Sushma,
Did you explore Heat templates? As Zane mentioned you can do this via Heat
template without writing any workflows.
Do you have any specific use cases which you can't solve with Heat template?
Create VM workflow was a demo example. Mistral potentially can be used by
Heat or other orchestration tools to do actual interaction with API, but
for user it might be easier to use Heat functionality.
Thanks,
Georgy
On Mon, Dec 8, 2014 at 7:54 AM, Nikolay Makhotkin nmakhot...@mirantis.com
wrote:
Hi, Sushma!
Can we create multiple resources using a single task, like multiple
keypairs or security-groups or networks etc?
Yes, we can. This feature is in the development now and it is considered
as experimental -
https://blueprints.launchpad.net/mistral/+spec/mistral-dataflow-collections
Just clone the last master branch from mistral.
You can specify for-each task property and provide the array of data to
your workflow:
version: '2.0'
name: secgroup_actions
workflows:
create_security_group:
type: direct
input:
- array_with_names_and_descriptions
tasks:
create_secgroups:
for-each:
data: $.array_with_names_and_descriptions
action: nova.security_groups_create name={$.data.name}
description={$.data.description}
On Mon, Dec 8, 2014 at 6:36 PM, Zane Bitter zbit...@redhat.com wrote:
On 08/12/14 09:41, Sushma Korati wrote:
Can we create multiple resources using a single task, like multiple
keypairs or security-groups or networks etc?
Define them in a Heat template and create the Heat stack as a single task.
- ZB
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Best Regards,
Nikolay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Telco] [NFV] [Heat] Telco Orchestration
Hi Mathieu, Can you tell us more about those projects? Does it include mutli-datacenter use cases? Most of this work was done as a custom projects for customers. I have to ask them for a permission to share details. We do not support multi-datacenter placement officially, but this feature was developed for one of the customer and now is under review in upstream. Here is a review link: https://review.openstack.org/#/c/125717/ Technically we can create multiple Heat stacks in different regions and orchestrate Heat stack updates with proper resources through Murano workflows. Can you provide us a link to such a Murano Application, how you define dependencies with apps, and how you translate those dependencies in networking configuration? As I told, this was a custom work for customers, so they own these packages. The best example we have publically available is here: https://github.com/sergmelikyan/murano-app-incubator/blob/f5-loadbalancer/io.murano.traffic.f5.NeutronLoadBalancer/Classes/F5NeutronLoadBalancer.yaml As you see, we do not translate dependencies to network configs. Instead of translation we just provide a way to script necessary steps and expose them as workflows or functions which can be invoked by other applications. In this example we have F5LB which adds a Neutron resources to Heat template to create VIP and Pool Memebers and then extends F5 configuration by adding F5 specific LB method and adding IRule for redirect via calling BIGIP API directly. Here is an application wich has a dependency for LB: https://github.com/sergmelikyan/murano-app-incubator/blob/f5-loadbalancer/io.murano.apps.SimpleWebApp/Classes/SimpleWebApp.yaml Dependency is a generic loadBalancer:Contract: $.class(traffic:LoadBalancer) Based on which actual LoadBalancer implementation is selected by user during confutation step (NeutronLB or F5NeutronLB) the result of execution of these lines https://github.com/sergmelikyan/murano-app-incubator/blob/f5-loadbalancer/io.murano.apps.SimpleWebApp/Classes/SimpleWebApp.yaml#L42-L43 will be different. Thanks Georgy On Wed, Nov 26, 2014 at 4:58 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, On Wed, Nov 26, 2014 at 12:48 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, In Murano we did couple projects related to networking orchestration. As NFV Can you tell us more about those projects? Does it include mutli-datacenter use cases? is a quite broad term I can say that Murano approach fits into it too. In our case we had bunch of virtual appliances with specific networking capabilities and requirements. Some of these appliances had to work together to provide a required functionality. These virtual appliances were exposed as Murano applications with defined dependencies between apps and operators were able to create different networking configuration with these apps combining them according their requirements\capabilities. Underlying workflows were responsible to bind these virtual appliances together. Can you provide us a link to such a murano Application, how you define dependencies with apps, and how you translate those dependencies in networking configuration? I will be glad to participate in tomorrow meeting and answer any questions you have. Thanks Georgy On Tue, Nov 25, 2014 at 6:14 AM, Marc Koderer m...@koderer.com wrote: Hi Angus, Am 25.11.2014 um 12:48 schrieb Angus Salkeld asalk...@mirantis.com: On Tue, Nov 25, 2014 at 7:27 PM, Marc Koderer m...@koderer.comwrote: Hi all, as discussed during our summit sessions we would like to expand the scope of the Telco WG (aka OpenStack NFV group) and start working on the orchestration topic (ETSI MANO). Therefore we started with an etherpad [1] to collect ideas, use-cases and requirements. Hi Marc, You have quite a high acronym per sentence ratio going on that etherpad;) Haha, welcome to the telco world :) From Heat's perspective, we have a lot going on already, but we would love to support what you are doing. That’s exactly what we are planning. What we have is a long list of use-cases and requirements. We need to transform them into specs for the OpenStack projects. Many of those specs won’t be NFV specify, for instance a Telco cloud will be highly distributed. So what we need is a multi-region heat support (which is already a planned feature for Heat as I learned today). You need to start getting specific about what you need and what the missing gaps are. I see you are already looking at higher layers (TOSCA) also check out Murano as well. Yep, I will check Murano.. I never had a closer look to it. Regards Marc Regards -Angus Goal is to discuss this document and move it onto the Telco WG wiki [2] when it becomes stable. Feedback welcome ;) Regards Marc Deutsche Telekom [1] https://etherpad.openstack.org/p
Re: [openstack-dev] [Telco] [NFV] [Heat] Telco Orchestration
Hi, In Murano we did couple projects related to networking orchestration. As NFV is a quite broad term I can say that Murano approach fits into it too. In our case we had bunch of virtual appliances with specific networking capabilities and requirements. Some of these appliances had to work together to provide a required functionality. These virtual appliances were exposed as Murano applications with defined dependencies between apps and operators were able to create different networking configuration with these apps combining them according their requirements\capabilities. Underlying workflows were responsible to bind these virtual appliances together. I will be glad to participate in tomorrow meeting and answer any questions you have. Thanks Georgy On Tue, Nov 25, 2014 at 6:14 AM, Marc Koderer m...@koderer.com wrote: Hi Angus, Am 25.11.2014 um 12:48 schrieb Angus Salkeld asalk...@mirantis.com: On Tue, Nov 25, 2014 at 7:27 PM, Marc Koderer m...@koderer.comwrote: Hi all, as discussed during our summit sessions we would like to expand the scope of the Telco WG (aka OpenStack NFV group) and start working on the orchestration topic (ETSI MANO). Therefore we started with an etherpad [1] to collect ideas, use-cases and requirements. Hi Marc, You have quite a high acronym per sentence ratio going on that etherpad;) Haha, welcome to the telco world :) From Heat's perspective, we have a lot going on already, but we would love to support what you are doing. That’s exactly what we are planning. What we have is a long list of use-cases and requirements. We need to transform them into specs for the OpenStack projects. Many of those specs won’t be NFV specify, for instance a Telco cloud will be highly distributed. So what we need is a multi-region heat support (which is already a planned feature for Heat as I learned today). You need to start getting specific about what you need and what the missing gaps are. I see you are already looking at higher layers (TOSCA) also check out Murano as well. Yep, I will check Murano.. I never had a closer look to it. Regards Marc Regards -Angus Goal is to discuss this document and move it onto the Telco WG wiki [2] when it becomes stable. Feedback welcome ;) Regards Marc Deutsche Telekom [1] https://etherpad.openstack.org/p/telco_orchestration [2] https://wiki.openstack.org/wiki/TelcoWorkingGroup ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OVF/OVA support
HI Dmitry, I was not able to attend, by Alex was on this session. I will check what was discussed. Even if it was not discussed on the summit, we can continue to discuss it here in the mailing list. Thanks Gosha On Tue, Nov 11, 2014 at 4:39 AM, Dimitri Mazmanov dimitri.mazma...@ericsson.com wrote: Hello, I’m also interested in having OVF package support for applications. As it was described earlier, there are two main tracks to this – OVF artefacts in Glance (corresponding driver), and translating OVF descriptors to Heat templates. Is there any etherpad from the session? - Dimitri From: Bhandaru, Malini K malini.k.bhand...@intel.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday 7 November 2014 15:18 To: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com Cc: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] OVF/OVA support Gosha – this is wonderful news. Complements Intel interest. I am in the Glance area .. stopped by a couple of times, the room was available 2 pm onwards. Contact made and can continue via email and IRC. Malini *From:* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com gokrokvertsk...@mirantis.com] *Sent:* Friday, November 07, 2014 8:20 AM *To:* Bhandaru, Malini K *Cc:* OpenStack Development Mailing List *Subject:* Re: OVF/OVA support Hi Malini, I am interested in OVa support for applications. Specifically Ova to Heat as this is whay we usually do in Murano project. When is free format session for Glance? Should we add this to session etherpad? Thanks, Gosha On Nov 5, 2014 6:06 PM, Bhandaru, Malini K malini.k.bhand...@intel.com wrote: Please join us on Friday in the Glance track – free format session, to discuss supporting OVF/OVA in OpenStack. Poll: 1) How interested are you in this feature? 0 – 10 2) Interested enough to help develop the feature? Artifacts are ready for use. We are considering defining an artifact for OVF/OVA. What should the scope of this work be? Who are our fellow travelers? Intel is interested in parsing OVF meta data associated with images – to ensure that a VM image lands on the most appropriate hardware in the cloud instance, to ensure optimal performance. The goal is to remove the need to manually specify image meta data, allow the appliance provider to specify HW requirements, and in so doing reduce human error. Are any partners interested in writing an OVF/OVA artifact = stack deployment? Along the lines of heat? As a first pass, Intel we could at least 1) Defining artifact for OVA, parsing the OVF in it, pulling out the images therein and storing them in the glance image database and attaching meta data to the same. 2) Do not want to imply that OpenStack supports OVA/OVF -- need to be clear on this. 3) An OpenStack user could create a heat template using the images registered in step -1 4) OVA to Heat – there may be a loss in translation! Should we attempt this? 5) What should we do with multiple volume artifacts? 6) Are volumes read-only? Or on cloning, make copies of them? -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] OVF/OVA support
Hi Malini, I am interested in OVa support for applications. Specifically Ova to Heat as this is whay we usually do in Murano project. When is free format session for Glance? Should we add this to session etherpad? Thanks, Gosha On Nov 5, 2014 6:06 PM, Bhandaru, Malini K malini.k.bhand...@intel.com wrote: Please join us on Friday in the Glance track – free format session, to discuss supporting OVF/OVA in OpenStack. Poll: 1) How interested are you in this feature? 0 – 10 2) Interested enough to help develop the feature? Artifacts are ready for use. We are considering defining an artifact for OVF/OVA. What should the scope of this work be? Who are our fellow travelers? Intel is interested in parsing OVF meta data associated with images – to ensure that a VM image lands on the most appropriate hardware in the cloud instance, to ensure optimal performance. The goal is to remove the need to manually specify image meta data, allow the appliance provider to specify HW requirements, and in so doing reduce human error. Are any partners interested in writing an OVF/OVA artifact = stack deployment? Along the lines of heat? As a first pass, Intel we could at least 1) Defining artifact for OVA, parsing the OVF in it, pulling out the images therein and storing them in the glance image database and attaching meta data to the same. 2) Do not want to imply that OpenStack supports OVA/OVF -- need to be clear on this. 3) An OpenStack user could create a heat template using the images registered in step -1 4) OVA to Heat – there may be a loss in translation! Should we attempt this? 5) What should we do with multiple volume artifacts? 6) Are volumes read-only? Or on cloning, make copies of them? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Autoscaling][HA][Murano] Use cases for Murano actions feature. Autoscaling, HA and operations.
Hi Steve, WebHook authentication is one of the unresolved issue. Right now Murano expects to have a token supplied with he API requests even for actions. In our demo environment we added a simple proxy server which accepts POST requests with HTTP basic auth or NTLM for the action URL, does the authentication in keystone by using credentials stored in barbican and then pass a request to Murano auth. We plan to come up with some more elegant solution in Kilo release. We are working with our customers to figure out what solution will satisfy their security requirements. Once we have it we can use the same approach in Heat too. Thanks Gosha On Fri, Oct 31, 2014 at 4:11 AM, Steven Hardy sha...@redhat.com wrote: On Fri, Oct 31, 2014 at 03:23:20AM -0700, Georgy Okrokvertskhov wrote: Hi, In the Juno release Murano team added a new feature - Actions. This feature allows to declare actions as specific application methods which should be executed when an action is triggered. When Murano deploys an application with actions new web hooks will be created and exposed by Murano API. Can you provide links to any documentation which describes the auth scheme used for the web hooks please? I'm interested to see how you've approached it, vs AWS pre-signed URL, Swift TempURL's etc, as Heat needs an openstack-native solution to this problem as well. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano][Docker] Docker applications support in Murano
Hi Stackers, Murano Application Catalog is a project which is aimed to help OpenStack users to publish and run applications on top of OpenStack infrastructure. Murano Juno release supports two main application formats: HOT template apps and Murano packages. Today, I would like to announce an initial support of Docker images based application in Murano. It is possible to use Murano Application Catalog to publish Docker based applications and end users will be able to deploy these application on top of Docker Service VM provisioned by Murano. As usual, Murano uses Heat for doing the actual work. Initially, Murano generates a Heat template with networks, Nova server and Software config for Docker service VM. Once Docker Service is up and running Murano will update Heat stack with Docker resources provided by Docker plugin. Murano Docker Service VM workflows will help to create port bindings automatically so it is possible to host multiple Docker containers inside a Docker service VM. We plan to continue to significantly improve Docker containers integration in upcoming releases by adding support for Docker VM clusters, Nova Docker plugin support to place Docker containers on bare metal servers controlled by Nova adding integrating with monitoring tools and other 3rd party apps supported by Murano. Here is a link to a small demo video: https://www.youtube.com/watch?v=P51ZUIqS4n4 Thanks Georgy -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Autoscaling][HA][Murano] Use cases for Murano actions feature. Autoscaling, HA and operations.
Hi, In the Juno release Murano team added a new feature - Actions. This feature allows to declare actions as specific application methods which should be executed when an action is triggered. When Murano deploys an application with actions new web hooks will be created and exposed by Murano API. These web hooks could be used by any 3rd party tools like monitoring systems, schedulers, UI tools to execute a related action at any time. There are several use cases which could require Murano actions: 1. AutoScaling. There were couple discussions around AutoScaling implementation. The most well known solution is to use Heat AS resource. Heat autoscaling resource works perfectly with scaling other Heat resources and even Heat nested stacks. At the same time there are discussions about AS place in Heat and how it should be done. In Murano autoscaling is just a specific action which knows how to modify Heat stack in order to scale the application properly. It can just add a new instance or to do something more complex by scaling multiple resources simultaneously based on some calculations. Application author has a full control on what are specific steps to perform autoscaling for this particular application. 1. HA HA is another great example of a use case for a Murano actions feature. As Murano allows to bind different applications based on requirements, it is possible to select specific Monitoring tool for the application and configure this monitoring to call Murano API web hook generated for the application in case of failure. As all applications are different they usually require different steps performed for HA switchover. Murano actions allows to define different HA tactics like try to restart a service first, then reboot a VM, then evacuate a VM or recreate a VM. 1. Application operations Applications may expose different actions to perform specific operations. Database applications can expose ‘Backup” actions to perform DB backups. Some other application can expose action “Restart” or “Update” to perform related operations. Here is a link for a small recordings: http://www.youtube.com/watch?v=OvPpJd0EOFw Here is a code for the Java application with autoscaling actions: https://github.com/gokrokvertskhov/murano-app-incubator/blob/monitoring-latest/io.murano.apps.java.HelloWorldCluster/Classes/HelloWorldCluster.murano#L92-L99 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Introducing Re-Heat
Heat updates work pretty well and this is a right way to track all the changes you do with your infrastructure. Heat declarative templates define state of the OpenStack or any other application in a good, well designed abstract form of resources and their dependencies. If you use Heat updates, the sequence of Heat template diffs gives you the history of changes for free. Heat updates approach is used in multiple projects like TripleO, Murano, Solum and this is a proven way to control resources from a single point of control. We use Heat updates in Murano for almost over the year and we were able to cover almost every application life-cycle aspect with Heat updates. On Thu, Oct 2, 2014 at 2:51 PM, Zane Bitter zbit...@redhat.com wrote: Dredging up this thread because I was reminded of it today by a question on ask.openstack.org. On 18/07/14 09:19, Ayenson, Michael D. wrote: Hello All, My name is Mika Ayenson and I have to privilege to intern at Johns Hopkins - Applied Physics Lab. I'm really excited to release the latest proof of concept Re-Heat Re-Heat is a JHUAPL developed tool for OpenStack users to help them quickly rebuild their OpenStack environments via OpenStack's Heat . Here is a link to the Re-Heat paper: https://drive.google.com/open? id=0BzTq-ZB9F-b9b0ZXdy1PT2t3dk0authuser=0 Here is a link to Re-Heat: https://github.com/Mikaayenson/ReHeat I have included the abstract to our paper here: This makes me sad. Not because it isn't great work - I'm sure it is. It makes me sad because when I read statements like: In the context of “entire lifecycle” management, Heat is the “create” aspect of OpenStack orchestration. I realise that we have completely failed to communicate what Heat is :( To be clear, in the context of entire lifecycle management, Heat is the entire lifecycle aspect of OpenStack orchestration. I know I, and I suspect many of us, always hoped that this would be exactly the kind of application where Heat could make a difference, helping scientists to make their research more repeatable. Heat does that by allowing you to represent your infrastructure as code, and store it under version control. Messing with it behind Heat's back instead of by modifying the template is the infrastructure equivalent of connecting a debugger and messing with the machine code at runtime instead of changing the source. It's the opposite of repeatable. And developing tools to make using this broken pattern more convenient is a step in the wrong direction IMHO. I strongly recommend you try using the stack update mechanism instead. It's not perfect, but it's getting better all the time. We welcome any feedback you have. To be clear, I do think there is a really good use of this kind of technology, and it's the one that the Flame developers are targeting: bringing existing applications under Heat's management. cheers, Zane. Abstract OpenStack has experienced tremendous growth since its initial release just over four years ago. Many of the enhancements, such as the Horizon interface and Heat, facilitate making complex network environment deployments in the cloud from scratch easier. The Johns Hopkins University Applied Physics Lab (JHU/APL) has been using the OpenStack environment to conduct research, host proofs-of-concepts, and perform testing experimentation. Our experience reveals that during the environment development lifecycle users and network architects are constantly changing the environments (stacks) they originally deployed. Once development has reached a point at which experimentation and testing is prudent, scientific methodology requires recursive testing be conducted to determine the repetitiveness of the phenomena observed. This requires the same entry point (an identical environment) into the testing cycle. Thus, it was necessary to capture all the changes made to the initial ! environmen t during the development phase and modify the original Heat template. However, OpenStack has not had a tool to help automate this process. In response, JHU/APL developed a poof-of-concept automation tool called Re-Heat, which this paper describes in detail. I hope you all enjoy this as I have truly enjoyed playing with HEAT and developing Re-Heat. Cheers, Mika Ayenson ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman
Re: [openstack-dev] [Solum] Core Reviewer Change
+1 On Tue, Sep 30, 2014 at 10:03 AM, Adrian Otto adrian.o...@rackspace.com wrote: Solum Core Reviewer Team, I propose the following change to our core reviewer group: -lifeless (Robert Collins) [inactive] +murali-allada (Murali Allada) +james-li (James Li) Please let me know your votes (+1, 0, or -1). Thanks, Adrian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance][Heat] Murano split dsicussion
Hi, Let me comment on the reasons why we’ve suggested adding Murano engine to Orchestration program. If we consider the previous Murano incubation discussions, we see that an overlap with the Orchestration program was one of the TC’s concerns. We also find that it was the Heat team that proposed to split Murano into specific parts. As for items a) and b) highlighted by Zane, we definitely shared some of these concerns, but we were guided by TC feedback from the previous Murano incubation review that recommended splitting Murano into separate components. We are fine with having separate program or joining existing programs. In the current situation with Glance mission changed to more generic Catalog mission and Orchestration program mission covering everything it is better to joining existing programs rather than trying to add a new one stepping on everyone’s foot. If the Orchestration program team believes that Murano does not intersect with the mission of the Orchestration program and should start its own program, let’s send this message to the TC and Murano team is ready to go this route. Thanks Georgy On Fri, Aug 22, 2014 at 6:29 AM, Zane Bitter zbit...@redhat.com wrote: On 21/08/14 04:30, Thierry Carrez wrote: Georgy Okrokvertskhov wrote: During last Atlanta summit there were couple discussions about Application Catalog and Application space projects in OpenStack. These cross-project discussions occurred as a result of Murano incubation request [1] during Icehouse cycle. On the TC meeting devoted to Murano incubation there was an idea about splitting the Murano into parts which might belong to different programs[2]. Today, I would like to initiate a discussion about potential splitting of Murano between two or three programs. [...] I think the proposed split makes a lot of sense. Let's wait for the feedback of the affected programs to see if it's compatible with their own plans. I want to start out by saying that I am a big proponent of doing stuff that makes sense, and wearing my PTL hat I will support the consensus of the community on whatever makes the most sense. With the PTL hat off again, here is my 2c on what I think makes sense: * The Glance thing makes total sense to me. Murano's requirements should be pretty much limited to an artifact catalog with some metadata - that's bread and butter for Glance. Murano folks should join the Glance team and drive their requirements into the artifact catalog. * The Horizon thing makes some sense. I think at least part of the UI should be in Horizon, but I suspect there's also some stuff in there that is pretty specific to the domain that Murano is tackling and it might be better for that to live in the same program as the Murano engine. I believe that there's a close analogue here with Tuskar and the TripleO program, so maybe we could ask them about any lessons learned. Georgy suggested elsewhere that the Merlin framework should be in Horizon and the rest in the same program as the engine, and that would make total sense to me. * The Heat thing doesn't make a lot of sense IMHO. I now understand that apparently different projects in the same program can have different core teams - which just makes me more confused about what a program is for, since I thought it was a single team. Nevertheless, I don't think that the Murano project would be well-served by being represented by the Heat PTL (which is, I guess, the only meaning still attached to a program). I don't think they want the Heat PTL triaging their bugs, and I don't think it's even feasible for one person to do that for both projects (that is to say, I already have a negative amount of extra time available for Launchpad just handling Heat). I don't think they want the Heat PTL to have control over their design summit sessions, and if I were the PTL doing that I would *hate* to be in the position of trying to balance the interests of the two projects - *especially*, given that I am in Clint's camp of not seeing a lot of value in Murano, when one project has not gone through the incubation process and therefore there would be no guidance available from the TC or consensus in the wider community as to whether that project warranted any time at all devoted to it. In fact, I would go so far as to say that it's completely unreasonable to put a single PTL in that position. So, I don't think putting the Murano engine into the Orchestration program is being proposed because it makes sense. I think it's being proposed, despite not making sense, because people consider it unlikely that the TC would grant Murano a separate program due to some combination of: (a) People won't think Murano is a good (enough) idea - in which case we shouldn't do it (yet); and/or (b) People have an irrational belief that projects are lightweight but programs are heavyweight, when the reverse is true, and will block any new programs for fear of letting another person call themselves a PTL
Re: [openstack-dev] [Glance][Heat] Murano split dsicussion
*Murano UI to Dashboard Program* Application Catalog requires a UI focused on user experience. Currently there is a Horizon plugin for Murano App Catalog which adds Application catalog page to browse, search and filter applications. It also adds a dynamic UI functionality to render a Horizon forms without writing an actual code. Are we going to wait for the generic UI (Merlin) or get murano-dashboard into Horizon then work on Merlin? Merlin will be a generic library\framework in Horizon for Application projects (Heat, Murano, Solum). We still need to have specific implementations of UI for each project, but these projects will reuse the common code. We can put existing Murano UI to Dashboard or inside Catalog program as a separate repo. I think it might make sense to keep UI components closer to project rather then keep UI in a separate program. On Thu, Aug 21, 2014 at 6:35 PM, Angus Salkeld asalk...@mirantis.com wrote: On Thu, Aug 21, 2014 at 6:14 AM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: During last Atlanta summit there were couple discussions about Application Catalog and Application space projects in OpenStack. These cross-project discussions occurred as a result of Murano incubation request [1] during Icehouse cycle. On the TC meeting devoted to Murano incubation there was an idea about splitting the Murano into parts which might belong to different programs[2]. Today, I would like to initiate a discussion about potential splitting of Murano between two or three programs. *App Catalog API to Catalog Program* Application Catalog part can belong to Catalog program, the package repository will move to artifacts repository part where Murano team already participates. API part of App Catalog will add a thin layer of API methods specific to Murano applications and potentially can be implemented as a plugin to artifacts repository. Also this API layer will expose other 3rd party systems API like CloudFoundry ServiceBroker API which is used by CloudFoundry marketplace feature to provide an integration layer between OpenStack Application packages and 3rd party PaaS tools. Seems to make sense, tho' I am not a glance-core. *Murano Engine to Orchestration Program* Murano engine orchestrates the Heat template generation. Complementary to a Heat declarative approach, Murano engine uses imperative approach so that it is possible to control the whole flow of the template generation. The engine uses Heat updates to update Heat templates to reflect changes in applications layout. Murano engine has a concept of actions - special flows which can be called at any time after application deployment to change application parameters or update stacks. The engine is actually complementary to Heat engine and adds the following: - orchestrate multiple Heat stacks - DR deployments, HA setups, multiple datacenters deployment - Initiate and controls stack updates on application specific events - Error handling and self-healing - being imperative Murano allows you to handle issues and implement additional logic around error handling and self-healing. +1 Are the teams going to work as-is from a core reviewer PoV (I'd assume so, just clarifying). I am just wondering how we can get the Heat and Murano teams to know what each are doing - basically work at least somewhat together. *Murano UI to Dashboard Program* Application Catalog requires a UI focused on user experience. Currently there is a Horizon plugin for Murano App Catalog which adds Application catalog page to browse, search and filter applications. It also adds a dynamic UI functionality to render a Horizon forms without writing an actual code. Are we going to wait for the generic UI (Merlin) or get murano-dashboard into Horizon then work on Merlin? -Angus [1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html [2] http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance][Heat] Murano split dsicussion
During last Atlanta summit there were couple discussions about Application Catalog and Application space projects in OpenStack. These cross-project discussions occurred as a result of Murano incubation request [1] during Icehouse cycle. On the TC meeting devoted to Murano incubation there was an idea about splitting the Murano into parts which might belong to different programs[2]. Today, I would like to initiate a discussion about potential splitting of Murano between two or three programs. *App Catalog API to Catalog Program* Application Catalog part can belong to Catalog program, the package repository will move to artifacts repository part where Murano team already participates. API part of App Catalog will add a thin layer of API methods specific to Murano applications and potentially can be implemented as a plugin to artifacts repository. Also this API layer will expose other 3rd party systems API like CloudFoundry ServiceBroker API which is used by CloudFoundry marketplace feature to provide an integration layer between OpenStack Application packages and 3rd party PaaS tools. *Murano Engine to Orchestration Program* Murano engine orchestrates the Heat template generation. Complementary to a Heat declarative approach, Murano engine uses imperative approach so that it is possible to control the whole flow of the template generation. The engine uses Heat updates to update Heat templates to reflect changes in applications layout. Murano engine has a concept of actions - special flows which can be called at any time after application deployment to change application parameters or update stacks. The engine is actually complementary to Heat engine and adds the following: - orchestrate multiple Heat stacks - DR deployments, HA setups, multiple datacenters deployment - Initiate and controls stack updates on application specific events - Error handling and self-healing - being imperative Murano allows you to handle issues and implement additional logic around error handling and self-healing. *Murano UI to Dashboard Program* Application Catalog requires a UI focused on user experience. Currently there is a Horizon plugin for Murano App Catalog which adds Application catalog page to browse, search and filter applications. It also adds a dynamic UI functionality to render a Horizon forms without writing an actual code. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027736.html [2] http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-03-04-20.02.log.txt -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] ova support in glance
us your feedback. Regards Malini ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Core Reviewer Change
+1. Glad to see Pierre in Solum Core team! On Wed, Jul 9, 2014 at 2:55 AM, Julien Vey vey.jul...@gmail.com wrote: +1 Pierre always provide valuable feedback. Glad to see him in the core team 2014-07-09 11:26 GMT+02:00 Adrian Otto adrian.o...@rackspace.com: Solum Core Reviewer Team, I propose the following change to our core reviewer group: +stannie (Pierre Padrixe) Please let me know your votes (+1, 0, or -1). Thanks, Adrian ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Nominations to Murano core
+1 for both! Thanks for the great work! Regards, Gosha On Thu, Jun 26, 2014 at 7:05 AM, Timur Sufiev tsuf...@mirantis.com wrote: +1 for both. On Thu, Jun 26, 2014 at 3:29 PM, Stan Lagun sla...@mirantis.com wrote: +1 for both (or should I say +2?) Sincerely yours, Stan Lagun Principal Software Engineer @ Mirantis On Thu, Jun 26, 2014 at 1:49 PM, Alexander Tivelkov ativel...@mirantis.com wrote: +1 on both Serge and Steve -- Regards, Alexander Tivelkov On Thu, Jun 26, 2014 at 1:37 PM, Ruslan Kamaldinov rkamaldi...@mirantis.com wrote: I would like to nominate Serg Melikyan and Steve McLellan to Murano core. Serge has been a significant reviewer in the Icehouse and Juno release cycles. Steve has been providing consistent quality reviews and they continue to get more frequent and better over time. Thanks, Ruslan ___ 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 -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stateful Applications on OpenStack
Hi, You still can run legacy application on OpenStack with HA and DR using the same good old school tools like pacemaker, heartbeat, DRBD etc. There are all necessary features available in latest OpenStack. The most important feature for HA - secondary IP address was implemented in Havana. Now you can assign multiple IP addresses to the single VM port. Secondary IP can be used as a VIP in pacemaker so it is possible to create classic Active-Passive setup for any application. HAProxy is still there an you can use it for any application which uses IP based transport for communication. This secondary IP feature allows you to run even Windows cluster applications without any significant changes in setup in comparison to the running cluster on physical nodes. There is no shared volumes (yet as I know) but you can use DRBD on VM to sync two volumes attached to two different VMs and shared network filesystems as a service is almost there. Using these approaches it is possible to have data resilience for legacy applications too. There is no automagic things which make legacy apps resilient, but it is still possible to do with using known tools as there are no limitations from OpenStack infrastructure side for that. As I know there were discussions about exposing HA clusters on hypervisors that will allow some kind of resilience automatically (through automatic migrations or evacuation) but there is no active work on it visible. Thanks Georgy On Mon, Jun 9, 2014 at 7:16 AM, Matthew Farina m...@mattfarina.com wrote: In my experience building apps that run in OpenStack, you don't give up state. You shift how you handle state. For example, instead of always routing a user to the same instance and that instance holding the session data there is a common session store for the app (possibly synced between regions). If you store session on each instance and loose an instance you'll run into problems. If sessions is more of a service for each instance than an instance coming and going isn't a big deal. A good database as a service, swift (object storage), and maybe a microservice architecture may be helpful. Legacy applications might have some issues with the architecture changes and some may not be a good fit for cloud architectures. One way to help legacy applications is to use block storage, keep the latest snapshot of the instance in glance (image service), and monitor an instance. If an instance goes offline you can easily create a new one from the image and mount block storage with the data. - Matt On Mon, Jun 9, 2014 at 7:27 AM, hossein zabolzadeh zabolza...@gmail.com wrote: Hi OpenStack Development Community, I know that the OpenStack interest is to become a cloud computing operating system. And this simple sentence means: Say goodbye to Statefull Applications. But, as you know we are in the transition phase from stateful apps to stateless apps(Remember Pets and Cattle Example). Legacy apps are still in used and how openstack can address the problems of running stateful applications(e.g. HA, DR, FT, R,...)? HA: High Availability DR: Disaster Recovery FT: Fault Tolerance R: Resiliancy! ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Stateful Applications on OpenStack
Hi Hossein, In additions you may check the following: Heat OS::Heat::HARestarter resource http://docs.openstack.org/developer/heat/template_guide/openstack.html This blog entry about clustering: http://vmtrooper.com/openstack-your-windows-cluster-with-neutron-allowed-address-pairs/ Mistral project, specifically for Live migration: https://wiki.openstack.org/wiki/Mistral#Live_migration Murano project for legacy app management and composing: https://wiki.openstack.org/wiki/Murano/ProjectOverview Thanks, Georgy On Mon, Jun 9, 2014 at 9:30 AM, hossein zabolzadeh zabolza...@gmail.com wrote: Really thanks Georgy for your complete answer. My major concern on openstack was HA on my legacy apps(I wanted to use cloudstack instead of openstack becasue of its more attention to legacy apps and more HA features). But now, I will check your listed HA solutions on openstack and come back as soon as possible. On Mon, Jun 9, 2014 at 8:53 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, You still can run legacy application on OpenStack with HA and DR using the same good old school tools like pacemaker, heartbeat, DRBD etc. There are all necessary features available in latest OpenStack. The most important feature for HA - secondary IP address was implemented in Havana. Now you can assign multiple IP addresses to the single VM port. Secondary IP can be used as a VIP in pacemaker so it is possible to create classic Active-Passive setup for any application. HAProxy is still there an you can use it for any application which uses IP based transport for communication. This secondary IP feature allows you to run even Windows cluster applications without any significant changes in setup in comparison to the running cluster on physical nodes. There is no shared volumes (yet as I know) but you can use DRBD on VM to sync two volumes attached to two different VMs and shared network filesystems as a service is almost there. Using these approaches it is possible to have data resilience for legacy applications too. There is no automagic things which make legacy apps resilient, but it is still possible to do with using known tools as there are no limitations from OpenStack infrastructure side for that. As I know there were discussions about exposing HA clusters on hypervisors that will allow some kind of resilience automatically (through automatic migrations or evacuation) but there is no active work on it visible. Thanks Georgy On Mon, Jun 9, 2014 at 7:16 AM, Matthew Farina m...@mattfarina.com wrote: In my experience building apps that run in OpenStack, you don't give up state. You shift how you handle state. For example, instead of always routing a user to the same instance and that instance holding the session data there is a common session store for the app (possibly synced between regions). If you store session on each instance and loose an instance you'll run into problems. If sessions is more of a service for each instance than an instance coming and going isn't a big deal. A good database as a service, swift (object storage), and maybe a microservice architecture may be helpful. Legacy applications might have some issues with the architecture changes and some may not be a good fit for cloud architectures. One way to help legacy applications is to use block storage, keep the latest snapshot of the instance in glance (image service), and monitor an instance. If an instance goes offline you can easily create a new one from the image and mount block storage with the data. - Matt On Mon, Jun 9, 2014 at 7:27 AM, hossein zabolzadeh zabolza...@gmail.com wrote: Hi OpenStack Development Community, I know that the OpenStack interest is to become a cloud computing operating system. And this simple sentence means: Say goodbye to Statefull Applications. But, as you know we are in the transition phase from stateful apps to stateless apps(Remember Pets and Cattle Example). Legacy apps are still in used and how openstack can address the problems of running stateful applications(e.g. HA, DR, FT, R,...)? HA: High Availability DR: Disaster Recovery FT: Fault Tolerance R: Resiliancy! ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
Re: [openstack-dev] [Glance] [Heat] Glance Metadata Catalog for Capabilities and Tags
I think this is a great feature to have it in Glance. Tagging mechanism for objects which are not owned by Glance is complimentary to artifact catalog\repository in Glance. As soon as we keep tags and artifacts metadata close to each other the end-user will be able to use them seamlessly. Artifacts also can use tags to find objects outside of artifact repository which is always good to have. In Murano project we use Glance tags to find correct images which are required by specific applications. It will be great to extend this to other objects like networks, routers and flavors so that application write can specify kind of object are required for his application. Thanks, Georgy On Fri, May 30, 2014 at 11:45 AM, Zane Bitter zbit...@redhat.com wrote: On 29/05/14 18:42, Tripp, Travis S wrote: Hello everyone! At the summit in Atlanta we demonstrated the “Graffiti” project concepts. We received very positive feedback from members of multiple dev projects as well as numerous operators. We were specifically asked multiple times about getting the Graffiti metadata catalog concepts into Glance so that we can start to officially support the ideas we demonstrated in Horizon. After a number of additional meetings at the summit and working through ideas the past week, we’ve created the initial proposal for adding a Metadata Catalog to Glance for capabilities and tags. This is distinct from the “Artifact Catalog”, but we do see that capability and tag catalog can be used with the artifact catalog. We’ve detailed our initial proposal in the following Google Doc. Mark Washenberger agreed that this was a good place to capture the initial proposal and we can later move it over to the Glance spec repo which will be integrated with Launchpad blueprints soon. https://docs.google.com/document/d/1cS2tJZrj748ZsttAabdHJDzkbU9nM L5S4oFktFNNd68 Please take a look and let’s discuss! Also, the following video is a brief recap of what was demo’ d at the summit. It should help to set a lot of understanding behind the ideas in the proposal. https://www.youtube.com/watch?v=Dhrthnq1bnw Thank you! Travis Tripp (HP) Murali Sundar (Intel) *A Few Related Blueprints * https://blueprints.launchpad.net/horizon/+spec/instance- launch-using-capability-filtering https://blueprints.launchpad.net/horizon/+spec/tagging https://blueprints.launchpad.net/horizon/+spec/faceted-search https://blueprints.launchpad.net/horizon/+spec/host- aggregate-update-metadata https://blueprints.launchpad.net/python-cinderclient/+spec/ support-volume-image-metadata +1, this is something that will be increasingly important to orchestration. The folks working on the TOSCA (and others) - HOT translator project might be able to comment in more detail, but basically as people start wanting to write templates that run on multiple clouds (potentially even non-OpenStack clouds) some sort of catalog for capabilities will become crucial. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [murano] Proposal to add Ruslan Kamaldinov to murano-core team
+1 On Thu, Apr 17, 2014 at 6:01 AM, Dmitry Teselkin dtesel...@mirantis.comwrote: +1 Agree On Thu, Apr 17, 2014 at 4:51 PM, Alexander Tivelkov ativel...@mirantis.com wrote: +1 Totally agree -- Regards, Alexander Tivelkov On Thu, Apr 17, 2014 at 4:37 PM, Timur Sufiev tsuf...@mirantis.comwrote: Guys, Ruslan Kamaldinov has been doing a lot of things for Murano recently (including devstack integration, automation scripts, making Murano more compliant with OpenStack standards and doing many reviews). He's actively participating in our ML discussions as well. I suggest to add him to the core team. Murano folks, please say your +1/-1 word. -- Timur Sufiev ___ 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 -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Working in devstack?
Hi Mark, Thank you for a detailed report. As I know Murano team is working on fixing devstack scripts. As for DB setup it should be done by a command: tox -evenv -- murano-manage --config-file etc/murano/murano-api.conf db-sync It works in my testing environment. Thanks Georgy On Tue, Apr 15, 2014 at 4:11 PM, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: Hi all, There is some interest here in making use of Murano for Samba ADDC a service...so we've been (attempting) to get it up and running in devstack. In the process I've managed to get myself confused about the correct instructions for doing this: - the docs suggest http://murano-docs.github.io/latest/getting-started/ content/ch04s03.html - the project provides murano-deployment/devstack-scripts/README.rst) ...which are markedly different approaches (it *looks* like the project README.rst is out of date, as it the scripts it runs try to get heat-horizon from repos that do not exist anymore). If this approach is not longer workable, we should really remove (or correct these instructions). So following http://murano-docs.github.io/latest/getting-started/ content/ch04s03.html inside a Ubuntu 12.04 VM I stumbled into a few bugs: - several missing deps in various murano-*/requirements.txt (see attached) - typo in /murano-api/setup.sh (db_sync vs db-sync) Fixing these seems to get most things going (some tabs crash with missing tables, so I need to dig a bit more to find where they get created...). Any pointers/etc would be much appreciated! Cheers Mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
/HOT, Python, etc, but none of them was designed with ALM in mind as a goal. Solum[3] is specifically designed for ALM and purpose built for OpenStack... It has declared that it will generate HOT templates and setup other services, including putting together or executing supplied workflow definition (using Mistral if applicable). Like Murano, Solum is also not an OpenStack incubated project, but it has been designed with community collaboration (based on shared pain across multiple contributors) with the ALM goal in mind from the very beginning. I think that the HOT template generation is not a key feature of Solum. It is just a details of implementation. Other services like TripleO also generates Heat templates but it does not mean that it is their primary goal. ALM is a broad term. I think Solum has a different area of responsibility covering the Application Development area which does covered in OpenStack yet. The high level goals listed on Solum.io are: - Provisioning Speed - CI/CD - Git Push - Integration with common IDE's (Eclipse, IntelliJ, etc) - Application lifecycle management(connected environments - Dev, Test, Prod) Given that I don't see the huge overlap here with Murano functionality as even if Solum stated that as a part of solution Heat template will be generated it does not necessarily mean that Solum itself will do this. From what is listed on the Solum page, in Solum sense - ALM is a way how the application build from source promoted between different CI\CD environments Dev, QA, Stage, Production. Solum can use other service to do this keeping its own focus on the target area. Specifically to the environments - Solum can use Murano environments which for Murano is just a logical unity of multiple applications. Solum can add CI\CD specific stuff on top of it keeping using Murano API for the environment management under the hood. Again, this is a typical OpenStack approach to have different services integrated to achieve the larger goal, keeping services itself very focused. -Keith [1] I regularly speak with DevOps, Application Specialists, and cloud customers, specifically about Orchestration and Heat.. HOT is somewhat simple enough for the most technical of them (DevOps App Specialists) to grasp and have interest in adopting, but their is strong push back from the folks I talk to about having to learn one more thing... Since Heat adopters are exactly the same people who have the knowledge to define the overall system capabilities including component connectivity and how UI should be rendered, I'd like to keep it simple for them. The more we can do to have the Orchestration service look/feel like one thing (even if it's Engine + Other things under the hood), or reuse other OpenStack core components (e.g. Glance) the better for adoption. [2] https://wiki.openstack.org/wiki/Heat/htr [3] http://solum.io ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Hi Thomas, I think we went to the second loop of the discussion about generic language concepts. Murano does not use a new language for the sole purpose of having parameters, constraints and polymorphism. These are generic concepts which are common for different languages, so keeping arguing about these generic concepts is just like a holy war like Python vs. C. Keeping these arguments is just like to say that we don't need Python as functions and parameters already exists in C which is used under the hood in Python. Yes Murano DSL have some generic concepts similar to HOT. I think this is a benefit as user will see the familiar syntax constructions and it will be a lower threshold for him to start using Murano DSL. In a simplified view Murano uses DSL for application definition to solve several particular problems: a) control UI rendering of Application Catalog b) control HOT template generation These aspects are not covered in HOT and probably should not be covered. I don't like an idea of expressing HOT template generation in HOT as it sounds like a creation another Lisp like language :-) I don't think that your statement that most of the people in the community are against new DSL is a right summary. There are some disagreements how it should look like and what are the goals. You will be probably surprised but we are not the first who use DSL for HOT templates generation. Here is an e-mail thread right about Ruby based DSL used in IBM for the same purpose: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html The term Orchestration is quite generic. Saying that orchestration should be Heat job sounds like a well know Henry Ford's phrase You can have any colour as long as it's black.. I think this is again a lack of understanding of the difference between Orchestration program and Heat project. There are many aspects of Orchestration and OpenStack has the Orchestration program for the projects which are focused on some aspects of orchestration. Heat is one of the project inside Orchestration program but it does not mean that Heat should cover everything. That is why we discussed in this thread how workflows aspects should be aligned and how they should be placed into this Orchestration program. Thanks Georgy On Mon, Mar 24, 2014 at 8:28 AM, Dmitry mey...@gmail.com wrote: MuranoPL supposed to provide a solution for the real needs to manage services in the centralized manner and to allow cloud provider customers to create their own services. The application catalog similar to AppDirect (www.appdirect.com) natively supported by OpenStack is a huge step forward. Think about Amazon which provides different services for the different needs: Amazon Cloud Formation, Amazon OpsWorks and Amazon Beanstalk. Following the similar logic (which is fully makes sense for me), OpenStack should provide resource reservation and orchestration (Heat and Climate), Application Catalog (Murano) and PaaS (Solum). Every project can live in harmony with other and contribute for the cloud service provider service completeness. This is my opinion and i would happy to use Murano in our internal solution. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 On Mon, Mar 24, 2014 at 5:13 AM, Thomas Herve thomas.he...@enovance.comwrote: Hi Stan, Comments inline. Zane, I appreciate your explanations on Heat/HOT. This really makes sense. I didn't mean to say that MuranoPL is better for Heat. Actually HOT is good for Heat's mission. I completely acknowledge it. I've tried to avoid comparison between languages and I'm sorry if it felt that way. This is not productive as I don't offer you to replace HOT with MuranoPL (although I believe that certain elements of MuranoPL syntax can be contributed to HOT and be valuable addition there). Also people tend to protect what they have developed and invested into and to be fair this is what we did in this thread to great extent. What I'm trying to achieve is that you and the rest of Heat team understand why it was designed the way it is. I don't feel that Murano can become full-fledged member of OpenStack ecosystem without a bless from Heat team. And it would be even better if we agree on certain design, join our efforts and contribute to each other for sake of Orchestration program. Note that I feel that most people outside of the Murano project are against the idea of using a DSL. You should feel that it could block the integration in OpenStack. I'm sorry for long mail texts written in not-so-good English and appreciate you patience reading and answering them. Having said that let me step backward and explain our design
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
On Tue, Mar 25, 2014 at 3:32 AM, Thomas Herve thomas.he...@enovance.comwrote: Hi Thomas, I think we went to the second loop of the discussion about generic language concepts. Murano does not use a new language for the sole purpose of having parameters, constraints and polymorphism. These are generic concepts which are common for different languages, so keeping arguing about these generic concepts is just like a holy war like Python vs. C. Keeping these arguments is just like to say that we don't need Python as functions and parameters already exists in C which is used under the hood in Python. Yes Murano DSL have some generic concepts similar to HOT. I think this is a benefit as user will see the familiar syntax constructions and it will be a lower threshold for him to start using Murano DSL. In a simplified view Murano uses DSL for application definition to solve several particular problems: a) control UI rendering of Application Catalog b) control HOT template generation These aspects are not covered in HOT and probably should not be covered. I don't like an idea of expressing HOT template generation in HOT as it sounds like a creation another Lisp like language :-) I'm not saying that HOT will cover all your needs. I think it will cover a really good portion. And I'm saying that for the remaining part, you can use an existing language and not create a new one. As a user can't run arbitrary python code in openstack we used Python language to create a new API for the remaining parts. This API service accepts a yaml based description of what should be done. There is no intention to create a new generic programming language. We used OpenStack approach and created a service for specific functions around Application Catalog features. Due to dynamic nature of applications we had to add a bit of dynamics to the service input just because of the same reason why Heat uses templates. I don't think that your statement that most of the people in the community are against new DSL is a right summary. There are some disagreements how it should look like and what are the goals. You will be probably surprised but we are not the first who use DSL for HOT templates generation. Here is an e-mail thread right about Ruby based DSL used in IBM for the same purpose: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html The term Orchestration is quite generic. Saying that orchestration should be Heat job sounds like a well know Henry Ford's phrase You can have any colour as long as it's black.. That worked okay for him :). Not really. The world acknowledged his inventions and new approaches. Other manufacturers adopted his ideas and moved forward, providing more variety, while Ford stuck with his model-T, which was very successful though. The history shows that variety won the battle over single approach and now we have different colors, shapes, engines :-) I think this is again a lack of understanding of the difference between Orchestration program and Heat project. There are many aspects of Orchestration and OpenStack has the Orchestration program for the projects which are focused on some aspects of orchestration. Heat is one of the project inside Orchestration program but it does not mean that Heat should cover everything. That is why we discussed in this thread how workflows aspects should be aligned and how they should be placed into this Orchestration program. Well, today Heat is the one and only program in the Orchestration program. If and when you have orchestration needs not covered, we are there to make sure Heat is not the best place to handle them. The answer will probably not Heat forever, but we need good use cases to delegate those needs to another project. That is exactly the reason why we have these discussions :-) We have the use cases for new functionality and we are trying to find a place for it. -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
to integrate more with HOT and eliminate all duplications between projects. I think that Murano and Heat are complimentary products that can effectively coexist. Murano provides access to all HOT features and relies on Heat for most of its activities. I believe that we need to find an optimal way to integrate Heat, Murano, Mistral, Solum, Heater, TOSCA, do some integration between ex-Thermal and Murano Dashboard, be united regarding Glance usage for metadata and so on. +1 To me that implies that Murano should be a relatively thin wrapper that ties together HOT and Mistral's DSL. We are okay with throwing MuranoPL out if the issues it solves would be addressed by HOT. If you have a vision on how HOT can address the same domain MuranoPL does or any plans for such features in upcoming Heat releases I would ask you to share it. [1] https://wiki.openstack.org/__wiki/Murano/DSL/Blueprint#__ Object_model https://wiki.openstack.org/wiki/Murano/DSL/Blueprint# Object_model ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Hi, I think notification mechanism proposed in Heat will work fine for integration with external workflows. The approach which uses workflows outside of Heat engine sounds consistent with our current approach in Murano. I am looking into new TOSCA yaml format and I also ask Mirantis management to consider joining OASIS. The decision is not made yet, but hopefully will be made on next week. We eager to jump onto TOSCA standard work and contribute plan related parts. Thanks Georgy On Wed, Mar 19, 2014 at 1:38 PM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: Excerpts from Zane Bitter's message on 19/03/2014 18:18:34: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Date: 19/03/2014 18:21 Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions? On 19/03/14 05:00, Stan Lagun wrote: Steven, Agree with your opinion on HOT expansion. I see that inclusion of imperative workflows and ALM would require major Heat redesign and probably would be impossible without loosing compatibility with previous HOT syntax. It would blur Heat mission, confuse current users and rise a lot of questions what should and what should not be in Heat. Thats why we chose to built a system on top of Heat rather then expending HOT. +1, I agree (as we have discussed before) that it would be a mistake to shoehorn workflow stuff into Heat. I do think we should implement the hooks I mentioned at the start of this thread to allow tighter integration between Heat and a workflow engine (i.e. Mistral). +1 on not putting workflow stuff into Heat. Rather let's come up with a nice way of Heat and a workflow service to work together. That could be done in two ways: (1) let Heat hand off to a workflow service for certains tasks or (2) let people define workflow tasks that can easily work on Heat deployed resources. Maybe both make sense, but right now I am more leaning towards (2). So building a system on top of Heat is good. Building it on top of Mistral as well would also be good, and that was part of the feedback from the TC. To me, building on top means building on top of the languages (which users will have to invest a lot of work in learning) as well, rather than having a completely different language and only using the underlying implementation(s). That all sounds logical to me and would keep things clean, i.e. keep the HOT language clean by not mixing it with imperative expression, and keep the Heat engine clean by not blowing it up to act as a workflow engine. When I think about the two aspects that are being brought up in this thread (declarative description of a desired state and workflows) my thinking is that much (and actually as much as possible) can be done declaratively the way Heat does it with HOT. Then for bigger lifecycle management there will be a need for additional workflows on top, because at some point it will be hard to express management logic declaratively in a topology model. Those additional flows on-top will have to be aware of the instance created from a declarative template (i.e. a Heat stack) because it needs to act on the respective resources to do something in addition. So when thinking about a domain specific workflow language, it should be possible to define tasks (in a template aware manner) like on resource XYZ of the template, do something, or update resource XYZ of the template with this state, then do this etc. At runtime this would resolve to the actual resource instances created from the resource templates. Making such constructs available to the workflow authors would make sense. Having a workflow service able to execute this via the right underlying APIs would be the execution part. I think from an instance API perspective, Heat already brings a lot for this with the stack model, so workflow tasks could be written to use the stack API to access instance information. Things like update of resources is also something that is already there. BTW, we have a similar concept (or are working on a refinement of it based on latest discussions) in TOSCA and call it the plan portability API, i.e. an API that a declarative engine would expose so that fit-for-purpose workflow tasks can be defined on-top. Regards, Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
cannot have Python code as a part of your DSL if you need to evaluate that DSL on server-side. Using Python's eval() is not secure. And you don't have enough control on what evaled code is allowed to do. MuranoPL on the contrary are fully sandboxed. You have absolute control over what functions/methods/APIs are exposed to DSL and DSL code can do nothing except for what it allowed to do. Besides you typically do want your DSL to be domain-specific so general-purpose language like Python can be suboptimal. I don't say MuranoPL is good for all projects. It has many Murano-specific things after all. In most cases you don't need all those OOP features that MuranoPL has. But the code organization, how it uses YAML, block structures and especially YAQL expressions can be of a great value to many projects For examples of MuranoPL classes you can browse https://github.com/istalker2/MuranoDsl/tree/master/meta folder. This is my private repository that I was using to develop PoC for MuranoPL engine. We are on the way to create production-quality implementation with unit-tests etc. in regular Murano repositories on stackforge On Sun, Mar 9, 2014 at 7:33 AM, Joshua Harlow harlo...@yahoo-inc.com mailto:harlo...@yahoo-inc.com wrote: To continue from other thread Personally I believe that YAQL-based DSLs similar (but probably simlet than) MuranoPL can be of a great value for many OpenStack projects that have DSLs of different kind. Murano for App Catatalog, Mistral for workflows, Heat for HOT templates, Ceilometer for alarms counter aggregation rules, Nova for customizable resource scheduling and probably many more. Isn't python a better host language for said DSLs than muranoPL? I am still pretty weary of a DSL that starts to grow so many features to encompass other DSLs since then it's not really a DSL but a non-DSL, and we already have one that everyone is familiar with (python). Are there any good examples if muranoPL that I can look at that take advantage of muranoPL classes, functions, namespaces which can be compared to there python equivalents. Has such an analysis/evaluation been done? Sent from my really tiny device... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours Stanislav (Stan) Lagun Senior Developer Mirantis 35b/3, Vorontsovskaya St. Moscow, Russia Skype: stanlagun www.mirantis.com http://www.mirantis.com/ sla...@mirantis.com mailto:sla...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Murano] New API methods for App Catalog UI
Hi, Murano is moving towards App Catalog functionality and in order to support this new aspect in the UI we need to add new API methods to cover App Catalog operations. Currently the vision for App Catalog API is the following: 1) All App create operations will be covered by metadata repository API which will eventually be a part of Glance Artifacts functionality. New application creation will be technically a creation of a new artifact and uploading it to metadata repository. The sharing and distribution aspects will be covered by the same artifact repository functionality. 2) App Listing and App Catalog rendering will be covered by a new Murano API. The reason for that is to keep UI thin and keep package representation aspects out of the general artifacts repository. The list of new API functions is available here: https://etherpad.openstack.org/p/MuranoAppCatalogAPI This is a first draft to cover minimal UI rendering requirements. Thanks Georgy -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat][Murano][TOSCA] Murano team contrib. to Heat TOSCA activities
Hi, Thomas and Zane initiated a good discussion about Murano DSL and TOSCA initiatives in Heat. I think will be beneficial for both teams to contribute into TOSCA. While Mirantis is working on organizational part for OASIS. I would like to understand what is the current view on the TOSCA and HOT relations. It looks like TOSCA can cover all aspects of declarative components HOT templates and imperative workflows which can be covered by Murano. What do you think about that? I think TOSCA format can be used a a descriptions of Applications and heat-translator can actually convert TOSCA descriptions to both HOT and Murano files which can be then used for actual Application deployment. Both Het and Murano workflows can coexist in Orchestration program and cover both declarative templates and imperative workflows use cases. -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][Murano][TOSCA] Murano team contrib. to Heat TOSCA activities
Hi Randall, I saw only the original XML based TOSCA 1.0 standard, I heard that there is a new YAML based version but I did not see it. The original TOSCA standard covered all aspects with TOSCA topology templates (Heat templates) and TOSCA Plans (workflows). I hope they will still use this approach. Mirantis is going to join OASIS and participate in TOSCA standard development too. As for Mistral, then it will have its own format for defining a tasks and flows. Murano can perfectly coexists with Mistral as it provides an application specific workflows. It is possible to define different actions for Application like Application.backup and this action can be called by Mistral to run a backup on schedule. Thanks, Georgy On Mon, Mar 10, 2014 at 11:51 AM, Randall Burt randall.b...@rackspace.comwrote: On Mar 10, 2014, at 1:26 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi, Thomas and Zane initiated a good discussion about Murano DSL and TOSCA initiatives in Heat. I think will be beneficial for both teams to contribute into TOSCA. Wasn't TOSCA developing a simplified version in order to converge with HOT? While Mirantis is working on organizational part for OASIS. I would like to understand what is the current view on the TOSCA and HOT relations. It looks like TOSCA can cover all aspects of declarative components HOT templates and imperative workflows which can be covered by Murano. What do you think about that? Aren't workflows covered by Mistral? How would this be different than including mistral support in Heat? I think TOSCA format can be used a a descriptions of Applications and heat-translator can actually convert TOSCA descriptions to both HOT and Murano files which can be then used for actual Application deployment. Both Het and Murano workflows can coexist in Orchestration program and cover both declarative templates and imperative workflows use cases. -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] oslo.messaging on VMs
Hi Julien, I there are valid reasons why we can consider MQ approach for communicating with VM agents. The first obvious reason is scalability and performance. User can ask infrastructure to create 1000 VMs and configure them. With HTTP approach it will lead to a corresponding number of connections to a REST API service. Taking into account that cloud has multiple clients the load on infrastructure will be pretty significant. You can address this with introducing Load Balancing for each service, but it will significantly increase management overhead and complexity of OpenStack infrastructure. The second issue is connectivity and security. I think that in typical production deployment VMs will not have an access to OpenStack infrastructure services. It is fine for core infrastructure services like Nova and Cinder as they do not work directly with VM. But it makes a huge problem for VM level services like Savanna, Heat, Trove and Murano which have to be able to communicate with VMs. The solution here is to put an intermediary to create a controllable way of communication. In case of HTTP you will need to have a proxy with QoS and Firewalls or policies, to be able to restrict an access to some specific URLS or services, to throttle the number of connections and bandwidth to protect services from DDoS attacks from VM sides. In case of MQ usage you can have a separate MQ broker for communication between service and VMs. Typical brokers have throttling mechanism, so you can protect service from DDoS attacks via MQ. Using different queues and even vhosts you can effectively segregate different tenants. For example we use this approach in Murano service when it is installed by Fuel. The default deployment configuration for Murano produced by Fuel is to have separate RabbitMQ instance for Murano-VM communications. This configuration will not expose the OpenStack internals to VM, so even if someone broke the Murano rabbitmq instance, the OpenSatck itself will be unaffected and only the Murano part will be broken. Thanks Georgy On Thu, Mar 6, 2014 at 7:46 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Mar 06 2014, Dmitry Mescheryakov wrote: So, messaging people, what is your opinion on that idea? I've already raised that question in the list [1], but seems like not everybody who has something to say participated. So I am resending with the different topic. For example, yesterday we started discussing security of the solution in the openstack-oslo channel. Doug Hellmann at the start raised two questions: is it possible to separate different tenants or applications with credentials and ACL so that they use different queues? My opinion that it is possible using RabbitMQ/Qpid management interface: for each application we can automatically create a new user with permission to access only her queues. Another question raised by Doug is how to mitigate a DOS attack coming from one tenant so that it does not affect another tenant. The thing is though different applications will use different queues, they are going to use a single broker. What about using HTTP and the REST APIs? What's what supposed to be the world facing interface of OpenStack. If you want to receive messages, it's still possible to use long polling connections. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] oslo.messaging on VMs
On Thu, Mar 6, 2014 at 8:59 AM, Julien Danjou jul...@danjou.info wrote: On Thu, Mar 06 2014, Georgy Okrokvertskhov wrote: I there are valid reasons why we can consider MQ approach for communicating with VM agents. The first obvious reason is scalability and performance. User can ask infrastructure to create 1000 VMs and configure them. With HTTP approach it will lead to a corresponding number of connections to a REST API service. Taking into account that cloud has multiple clients the load on infrastructure will be pretty significant. You can address this with introducing Load Balancing for each service, but it will significantly increase management overhead and complexity of OpenStack infrastructure. Uh? I'm having trouble imagining any large OpenStack deployment without load-balancing services. I don't think we ever designed OpenStack to run without load-balancers at large scale. Not all services require LoadBalancer instances. It makes sense to use LB for API services but even in Nova there are components which use MQ RPC for communication and one doesn't need to put them behind LB as they scale naturally just using MQ concurrently. I believe this change to MQ RPC was exactly done to address the problems of scalability for internal services. I agree that LBs are supposed to be in production grade deployment but this solution is not a silver bullet and has lot of limitations and overall design implications. The second issue is connectivity and security. I think that in typical production deployment VMs will not have an access to OpenStack infrastructure services. Why? Should they be different than other VM? Are you running another OpenStack cloud to run your OpenStack cloud? There are use cases and security requirements that usually enforce to have very limited access to OpenStack infrastructure components. As cloud admins do not control the workloads on VMs there is a significant security risk of being attacked from VM. The common requirements we see in production deployment is to enable SSL for everything including MySQL, MQ and nova metadata service. I also would like to highlight that even Nova\Neutron for working with cloud-init enables an access to metadata temporary by managing routes on the VM. So for design purpose it is better to assume that there will be no access to OpenStack services from VM side and if you need is, you will have to configure this properly. It is fine for core infrastructure services like Nova and Cinder as they do not work directly with VM. But it makes a huge problem for VM level services like Savanna, Heat, Trove and Murano which have to be able to communicate with VMs. The solution here is to put an intermediary to create a controllable way of communication. In case of HTTP you will need to have a proxy with QoS and Firewalls or policies, to be able to restrict an access to some specific URLS or services, to throttle the number of connections and bandwidth to protect services from DDoS attacks from VM sides. This really sounds like weak arguments. You probably already do need firewall, QoS, and throttling for your users if you're deploying a cloud and want to mitigate any kind of attack. I don't argue about existence of such components in OpenStack deployment. I just show that with increasing number of services one will have to manage the complexity of such configuration. Taking into account number of possible Neutron configurations, possibility of overlapping subnets in virtual networks, and existence of fully private network which are not attached through the router to external network the connectivity and access control looks like a real complex task which will be a headache for cloud admins and devops. In case of MQ usage you can have a separate MQ broker for communication between service and VMs. Typical brokers have throttling mechanism, so you can protect service from DDoS attacks via MQ. Yeah and I'm pretty sure a lot of HTTP servers have throttling for connection rate and/or bandwidth limitation. I'm not really convinced. Yes, some of them have and you will need to configure them properly. Using different queues and even vhosts you can effectively segregate different tenants. Sounds like could do the same thing the HTTP protocol. For example we use this approach in Murano service when it is installed by Fuel. The default deployment configuration for Murano produced by Fuel is to have separate RabbitMQ instance for Murano-VM communications. This configuration will not expose the OpenStack internals to VM, so even if someone broke the Murano rabbitmq instance, the OpenSatck itself will be unaffected and only the Murano part will be broken. It really sounds like you already settled on the solution being RabbitMQ, so I'm not sure what/why you ask in the first place. :) Is there any problem with starting VMs on a network that is connected to your internal
Re: [openstack-dev] [Oslo] [Marconi] oslo.messaging on VMs
the communication. Bootstrapping seems like a second obvious problem with this model. I prefer a point to point model, much as the metadata service works today. Although rpc.messaging is a really nice framework (I know, I just ported heat to oslo.messaging!) it doesn't fit this problem well because of the security implications. Regards -steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request: Murano
Hi Steve, Thank you for sharing your thoughts. I believe that is what we were trying to receive as a feedback form TC. The current definition of program actually suggest the scenario you described. A new project will appear under Orchestration umbrella. Let say there will be two project one is Heat and another is Workflow (no specific name here, probably some part of Murano). Program will have one PTL (current Heat PTL) and two separate code team for each project. That was our understanding of what we want. I am not sure that this was enough stressed out on TC meeting. There were no any intentions to add anything to Heat. Not at all. We just discussed a possibility to split current Murano App Catalog into two parts. Catalog part would go to Catalog program to land App Catalog code near Glance project and integrate them as Glance will store application packages for Murano App Catalog service. The second part of Murano related to environment processing (deployment, life cycle management, events) would go to Orchestration program as a new project like Murano workflows or Murano environment control or anything else. As I mentioned in one of the previous e-mails, we already discussed with the heat team workflows Heat before HK summit. We understand this very well that workflows will not fit Heat and we perfectly understand reasons why. I think that the good result of last TC was the official mandate to discuss alignment and integration between projects Glance, Heat, Murano and probably other projects. Right now we consider the following: 1) Continue discussion around Catalog program mission and how Murano App Catalog will fit into this program. 2) Start conversation with the Heat team in two directions: a) TOSCA and its implementation. How Murano can extend TOSCA and how TOSCA can help Murano to define an application package. Murano should reuse as much as possible from TOSCA to implement this open standard b) Define the alignment between Heat and Murano. How workflows can coexist with HOT. What will be the best way to develop both Heat and Workflows within Orchestration program. 3) Explore Application space for OpenStack. As Thierry mentioned on TC meeting, there are concerns that it is probably to early for OpenStack to make a new step up to the stack. Thanks, Georgy On Wed, Mar 5, 2014 at 7:47 PM, Steven Dake sd...@redhat.com wrote: On 03/05/2014 02:16 AM, Thomas Spatzier wrote: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote on 05/03/2014 00:32:08: From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 05/03/2014 00:34 Subject: Re: [openstack-dev] Incubation Request: Murano Hi Thomas, Zane, Thank you for bringing TOSCA to the discussion. I think this is important topic as it will help to find better alignment or even future merge of Murano DSL and Heat templates. Murano DSL uses YAML representation too, so we can easily merge use constructions from Heat and probably any other YAML based TOSCA formats. I will be glad to join TOSCA TC. Is there any formal process for that? The first part is that your company must be a member of OASIS. If that is the case, I think you can simply go to the TC page [1] and click a button to join the TC. If your company is not yet a member, you could get in touch with the TC chairs Paul Lipton and Simon Moser and ask for the best next steps. We recently had people from GigaSpaces join the TC, and since they are also doing very TOSCA aligned implementation in Cloudify, their input will probably help a lot to advance TOSCA. I also would like to use this opportunity and start conversation with Heat team about Heat roadmap and feature set. As Thomas mentioned in his previous e-mail TOSCA topology story is quite covered by HOT. At the same time there are entities like Plans which are covered by Murano. We had discussion about bringing workflows to Heat engine before HK summit and it looks like that Heat team has no plans to bring workflows into Heat. That is actually why we mentioned Orchestration program as a potential place for Murano DSL as Heat+Murano together will cover everything which is defined by TOSCA. I remember the discussions about whether to bring workflows into Heat or not. My personal opinion is that workflows are probably out of the scope of Heat (i.e. everything but the derived orchestration flows the Heat engine implements). So there could well be a layer on-top of Heat that lets Heat deal with all topology-related declarative business and adds workflow-based orchestration around it. TOSCA could be a way to describe the respective overarching models and then hand the different processing tasks to the right engine to deal with it. My general take is workflow would fit in the Orchestration program, but not be integrated into the heat repo specifically. It would be a different repo
Re: [openstack-dev] Incubation Request: Murano
Hi, Here is an etherpad page with current Murano status http://etherpad.openstack.org/p/murano-incubation-status. Thanks Georgy On Mon, Mar 3, 2014 at 9:04 PM, Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote: Hi Zane, Thank you very much for this question. First of all let me highlight that Murano DSL was much inspired by TOSCA. We carefully read this standard before our movement to Murano DSL. TOSCA standard has a lot f of very well designed concepts and ideas which we reused in Murano. There is one obvious draw back of TOSCA - very heavy and verbose XML based syntax. Taking into account that OpenStack itself is clearly moving from XML based representations, it will be strange to bring this huge XML monster back on a higher level. Frankly, the current Murano workflows language is XML based and it is quite painful to write a workflows without any additional instrument like IDE. Now let me remind that TOSCA has a defined scope of its responsibility. There is a list of areas which are out of scope. For Murano it was important to see that the following items are out of TOSCA scope: Citations from [1]: ... 2. The definition of concrete plans, i.e. the definition of plans in any process modeling language like BPMN or BPEL. 3. The definition of a language for defining plans (i.e. a new process modeling language). ... Plans in TOSCA understanding is something similar to workflows. This is what we address by Murano workflow. Not let me go through TOSCA ideas and show how they are reflected in Murano. It will be a long peace of text so feel free to skip it. Taking this into account lets review what we have in Murano as an application package. Inside application package we have: 1. Application metadata which describes application, its relations and properties 2. Heat templates snippets 3. Scripts for deployment 4. Workflow definitions In TOSCA document in section 3.2.1 there are Service Templates introduced. These templates are declarative descriptions of services components and service Topologies. Service templates can be stored in catalog to be found and used by users. This service template description is abstracted from actual infrastructure implementation and each cloud provider maps this definition to actual cloud infrastructure. This is definitely a part which is already covered by Heat. The same section says the following: Making a concrete instance of a Topology Template can be done by running a corresponding Plan (so-called instantiating management plan, a.k.a. build plan). This build plan could be provided by the service developer who also creates the Service Template. This plan part which is out of scope of TOSCA is essentially what Murano adds as a part of application definition. Section 3.3 of TOSCA document introduces an new entity - artifacts. Artifact is a name for content which is needed for service deployment including (scripts, executables, binaries and images). That is why Murano has a metadata service to store artifacts as a part of application package. Moreover, Murano works with Glance team to move this metadata repository from Murano to Glance providing generic artifact repository which can be used not only by Murano but by any other services. Sections 3.4 and 3.5 explain the idea of Relationships with Compatibilities and Service Composition. Murano actually implements all these high level features. Application definition has a section with contract definitions. This contract syntax is not just a declaration of the relations and capabilities but also a way to make assertions and on-the fly type validation and conversion if needed. Section 10 reveals details of requirements. It explains that requirements can be complex: inherit each other and be abstract to define a broad set of required values. Like when service requires relation database it will require type=RDMS without assuming the actual DB implementation MySQL, PostgreSQL or MSSQL. In order to solve the problem of complex requirements, relations and service composition we introduced classes in our DSL. It was presented and discussed in this e-mail thread [3]. Murano DSL syntax allows application package writer to compose applications from existing classes by using inheritance and class properties with complex types like classes. It is possible to define a requirement with using abstract classes to define specific types of applications and services like databases, webservers and other. Using class inheritance Murano will be able to satisfy the requirement by specific object which proper parent class by checking the whole hierarchy of objects parent classes which can be abstract. I don't want to cover all entities defined in TOSCA as most important were discussed already. There are implementations of many TOSCA concepts in Murano, like class properties for TOSCA Properties, class methods for TOSCA Operations etc. TL;DR Summarizing
Re: [openstack-dev] Incubation Request: Murano
Hi Thomas, Zane, Thank you for bringing TOSCA to the discussion. I think this is important topic as it will help to find better alignment or even future merge of Murano DSL and Heat templates. Murano DSL uses YAML representation too, so we can easily merge use constructions from Heat and probably any other YAML based TOSCA formats. I will be glad to join TOSCA TC. Is there any formal process for that? I also would like to use this opportunity and start conversation with Heat team about Heat roadmap and feature set. As Thomas mentioned in his previous e-mail TOSCA topology story is quite covered by HOT. At the same time there are entities like Plans which are covered by Murano. We had discussion about bringing workflows to Heat engine before HK summit and it looks like that Heat team has no plans to bring workflows into Heat. That is actually why we mentioned Orchestration program as a potential place for Murano DSL as Heat+Murano together will cover everything which is defined by TOSCA. I think TOSCA initiative can be a great place to collaborate. I think it will be possible then to use Simplified TOSCA format for Application descriptions as TOSCA is intended to provide such descriptions. Is there a team who are driving TOSCA implementation in OpenStack community? I feel that such team is necessary. Thanks Georgy On Tue, Mar 4, 2014 at 2:36 PM, Thomas Spatzier thomas.spatz...@de.ibm.comwrote: Excerpt from Zane Bitter's message on 04/03/2014 23:16:21: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org Date: 04/03/2014 23:20 Subject: Re: [openstack-dev] Incubation Request: Murano On 04/03/14 00:04, Georgy Okrokvertskhov wrote: It so happens that the OASIS's TOSCA technical committee are working as we speak on a TOSCA Simple Profile that will hopefully make things easier to use and includes a YAML representation (the latter is great IMHO, but the key to being able to do it is the former). Work is still at a relatively early stage and in my experience they are very much open to input from implementers. Nice, I was probably also writing a mail with this information at about the same time :-) And yes, we are very much interested in feedback from implementers and open to suggestions. If we can find gaps and fill them with good proposals, now is the right time. I would strongly encourage you to get involved in this effort (by joining the TOSCA TC), and also to architect Murano in such a way that it can accept input in multiple formats (this is something we are making good progress toward in Heat). Ideally the DSL format for Murano+Heat should be a trivial translation away from the relevant parts of the YAML representation of TOSCA Simple Profile. Right, having a straight-forward translation would be really desirable. The way to get there can actually be two-fold: (1) any feedback we get from the Murano folks on the TOSCA simple profile and YAML can help us to make TOSCA capable of addressing the right use cases, and (2) on the other hand make sure the implementation goes in a direction that is in line with what TOSCA YAML will look like. cheers, Zane. ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request: Murano
will be a requirement it can be done with Murano engine as it has all necessary concepts and this is a question of translation between different syntax. There are probably some parts still missed, but we use pragmatic approach by introducing new concepts and ideas when it is necessary. Zane, thanks again for this question. I think my explanation of Murano and TOSCA relations will help to understand what value Murano adds for OpenStack. In this e-mail we actually discussed only one Murano component which is responsible for application package processing. I did not touch the Application Catalog part as this is not a part of TOSCA standard. [1] - TOSCA TC Scope of work: https://www.oasis-open.org/committees/tosca/charter.php [2] - TOSCA standard document: http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html [3] - DSL discussion e-mail thread: http://lists.openstack.org/pipermail/openstack-dev/2014-February/027938.html On Mon, Mar 3, 2014 at 6:33 PM, Zane Bitter zbit...@redhat.com wrote: On 25/02/14 05:08, Thierry Carrez wrote: The second challenge is that we only started to explore the space of workload lifecycle management, with what looks like slightly overlapping solutions (Heat, Murano, Solum, and the openstack-compatible PaaS options out there), and it might be difficult, or too early, to pick a winning complementary set. I'd also like to add that there is already a codified OASIS standard (TOSCA) that covers application definition at what appears to be a similar level to Murano. Basically it's a more abstract version of what Heat does plus workflows for various parts of the lifecycle (e.g. backup). Heat and TOSCA folks have been working together since around the time of the Havana design summit with the aim of eventually getting a solution for launching TOSCA applications on OpenStack. Nothing is set in stone yet, but I would like to hear from the Murano folks how they are factoring compatibility with existing standards into their plans. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Object-oriented approach for defining Murano Applications
, defines a machine which can join an Active Directory. Adds a join domain workflow step 4. DomainController - inherits Windows instance, adds an Install AD Role workflow steps and extends the Deploy step to call it. 5. PrimaryController - inherits DomainContoller, adds a Configure as Primary DC workflow step and extends Deploy step to call it. Also adds a domainIpAddress property which is set during the deployment. 6. SecondaryController, inherits both DomainMember and DomainController. Adds a Configure as Secondary DC worflow step and extends Deploy() step to call it and the join domain step inherited from the Domain Member class. 7. ActiveDirectory - a primary class which defines an Active Directory application. Defines properties for PrimaryController and SecondaryControllers and a Deploy workflow which call appropriate workflows on the controllers. The simplified class diagram may look like this: So, this approach allows to decompose the AD deployment workflow into simple isolated parts, explicitly manage the state and create reusable entities (of course classes like Instance, WindowsInstance, DomainMember may be used by other Murano Applications). For me this looks much, much better than the current implicit state machine which we run based on XML rules. What do you think about this approach, folks? Do you think it will be easily understood by application developers? Will it be easy to write workflows this way? Do you see any drawbacks here? Waiting for your feedback. -- Regards, Alexander Tivelkov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours Stanislav (Stan) Lagun Senior Developer Mirantis 35b/3, Vorontsovskaya St. Moscow, Russia Skype: stanlagun www.mirantis.com sla...@mirantis.com ___ 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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Incubation Request: Murano
projects ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Plugin architecture for custom actions?
Hi Winson, I think this is a good idea to support pluggable interface for actions. I think you can submit a BP for that. There is a python library stevedore developed in OpenStack community. I don't know the details but it looks like this library is intended to help build plugins. Thanks Georgy On Mon, Feb 24, 2014 at 5:43 PM, W Chan m4d.co...@gmail.com wrote: Will Mistral be supporting custom actions developed by users? If so, should the Actions module be refactored to individual plugins with a dynamic process for action type mapping/lookup? Thanks. Winson ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Incubation Request: Murano
All, Murano is the OpenStack Application Catalog service which has been developing on stackforge almost 11 months. Murano has been presented on HK summit on unconference track and now we would like to apply for incubation during Juno release. As the first step we would like to get feedback from TC on Murano readiness from OpenStack processes standpoint as well as open up conversation around mission and how it fits OpenStack ecosystem. Murano incubation request form is here: https://wiki.openstack.org/wiki/Murano/Incubation As a part of incubation request we are looking for an advice from TC on the governance model for Murano. Murano may potentially fit to the expanding scope of Image program, if it will be transformed to Catalog program. Also it potentially fits Orchestration program, and as a third option there might be a value in creation of a new standalone Application Catalog program. We have pros and cons analysis in Murano Incubation request form. Murano team has been working on Murano as a community project. All our code and bugs/specs are hosted at OpenStack Gerrit and Launchpad correspondingly. Unit tests and all pep8/hacking checks are run at OpenStack Jenkins and we have integration tests running at our own Jenkins server for each patch set. Murano also has all necessary scripts for devstack integration. We have been holding weekly IRC meetings for the last 7 months and discussing architectural questions there and in openstack-dev mailing lists as well. Murano related information is here: Launchpad: https://launchpad.net/murano Murano Wiki page: https://wiki.openstack.org/wiki/Murano Murano Documentation: https://wiki.openstack.org/wiki/Murano/Documentation Murano IRC channel: #murano With this we would like to start the process of incubation application review. Thanks Georgy -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Automatic Evacuation
Hi, If I am not mistaken Mistral team listed Live migration as a potential use case for workflow engine. There is no much details though. https://wiki.openstack.org/wiki/Mistral#Live_migration As I know Mistral plan to implement generic event handling mechanism when one can bind any kind of workflow with external event triggered by Ceilometer or other monitoring system. This bound workflow can actually define live migration logic. Thanks Georgy On Thu, Feb 20, 2014 at 3:04 PM, Sean Dague s...@dague.net wrote: On 02/20/2014 05:32 PM, Russell Bryant wrote: On 02/20/2014 05:05 PM, Costantino, Leandro I wrote: Hi, Would like to know if there's any interest on having 'automatic evacuation' feature when a compute node goes down. I found 3 bps related to this topic: [1] Adding a periodic task and using ServiceGroup API for compute-node status [2] Using ceilometer to trigger the evacuate api. [3] Include some kind of H/A plugin by using a 'resource optimization service' Most of those BP's have comments like 'this logic should not reside in nova', so that's why i am asking what should be the best approach to have something like that. Should this be ignored, and just rely on external monitoring tools to trigger the evacuation? There are complex scenarios that require lot of logic that won't fit into nova nor any other OS component. (For instance: sometimes it will be faster to reboot the node or compute-nova than starting the evacuation, but if it fail X times then trigger an evacuation, etc ) Any thought/comment// about this? Regards Leandro [1] https://blueprints.launchpad.net/nova/+spec/vm-auto-ha-when-host-broken [2] https://blueprints.launchpad.net/nova/+spec/evacuate-instance-automatically [3] https://blueprints.launchpad.net/nova/+spec/resource-optimization-service My opinion is that I would like to see this logic done outside of Nova. Right now Nova is the only service that really understands the compute topology of hosts, though it's understanding of liveness is really not sufficient to handle this kind of HA thing anyway. I think that's the real problem to solve. How to provide notifications to somewhere outside of Nova on host death. And the question is, should Nova be involved in just that part, keeping track of node liveness and signaling up for someone else to deal with it? Honestly that part I'm more on the fence about. Because putting another service in place to just handle that monitoring seems overkill. I 100% agree that all the policy, reacting, logic for this should be outside of Nova. Be it Heat or somewhere else. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] Need a new DSL for Murano
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 -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Regarding language pack database schema
That is exactly option #2 which propose to store attributes in columns. So there will be a limited set of attributes and each of them will have its own column in a table. Thanks Georgy On Tue, Feb 18, 2014 at 10:55 AM, Paul Montgomery paul.montgom...@rackspace.com wrote: Maybe a crazy idea butŠ What if we simply don't store the JSON blob data for M1 instead of putting storing it in a way we don't like long term? This way, there is no need to remember to change something later even though a bug could be created anyways. I believe the fields that would be missing/not stored in the blob are: * Compiler version * Language platform * OS platform Can we live with that for M1? On 2/18/14 12:07 PM, Adrian Otto adrian.o...@rackspace.com wrote: I agree. Let's proceed with option #2, and submit a wishlist bug to track this as tech debt. We would like to come back to this later and add an option to use a blob store for the JSON blob content, as Georgy mentioned. These could be stored in swift, or a K/V store. It might be nice to have a thin get/set abstraction there to allow alternates to be implemented as needed. I'm not sure exactly where we can track Paul Czarkowski's suggested restriction. We may need to just rely on reviewers to prevent this, because if we ever start introspecting the JSON blob, we will be using an SQL anti-pattern. I'm generally opposed to putting arbitrary sized text and blob entries into a SQL database, because eventually you may run into the maximum allowable size (ie: max-allowed-packet) and cause unexpected error conditions. Thanks, Adrian On Feb 18, 2014, at 8:48 AM, Paul Czarkowski paul.czarkow...@rackspace.com wrote: I'm also a +1 for #2.However as discussed on IRC, we should clearly spell out that the JSON blob should never be treated in a SQL-like manner. The moment somebody says 'I want to make that item in the json searchable' is the time to discuss adding it as part of the SQL schema. On 2/13/14 4:39 PM, Clayton Coleman ccole...@redhat.com wrote: I like option #2, simply because we should force ourselves to justify every attribute that is extracted as a queryable parameter, rather than making them queryable at the start. - Original Message - Hi Arati, I would vote for Option #2 as a short term solution. Probably later we can consider using NoSQL DB or MariaDB which has Column_JSON type to store complex types. Thanks Georgy On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane arati.mahim...@rackspace.com wrote: Hi All, I have been working on defining the Language pack database schema. Here is a link to my review which is still a WIP - https://review.openstack.org/#/c/71132/3 . There are a couple of different opinions on how we should be designing the schema. Language pack has several complex attributes which are listed here - https://etherpad.openstack.org/p/Solum-Language-pack-json-format We need to support search queries on language packs based on various criteria. One example could be 'find a language pack where type='java' and version1.4' Following are the two options that are currently being discussed for the DB schema: Option 1: Having a separate table for each complex attribute, in order to achieve normalization. The current schema follows this approach. However, this design has certain drawbacks. It will result in a lot of complex DB queries and each new attribute will require a code change. Option 2: We could have a predefined subset of attributes on which we would support search queries. In this case, we would define columns (separate tables in case of complex attributes) only for this subset of attributes and all other attributes will be a part of a json blob. With this option, we will have to go through a schema change in case we decide to support search queries on other attributes at a later stage. I would like to know everyone's thoughts on these two approaches so that we can take a final decision and go ahead with one approach. Suggestions regarding any other approaches are welcome too! Thanks, Arati ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ 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
Re: [openstack-dev] [solum] async / threading for python 2 and 3
Hi Angus, I think that we need to keep python 2 as a lot of enterprise customers still use python 2.x versions. If you target Solum only for python 3 users you will significantly reduce potential customer adoption. I would rather spend some time and research round option #3. I saw in openstack-dev mailing list that there is a work around asyncio native in py3 and its port for python2. Here is related BP https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio Here is the e-mail thread: http://lists.openstack.org/pipermail/openstack-dev/2014-February/026237.html Thanks Gosha On Tue, Feb 18, 2014 at 4:53 PM, Angus Salkeld angus.salk...@rackspace.comwrote: Hi all I need to use some async / threaded behaviour to solum for image creation (all I need right now is to run a job asyncronously). eventlet is python 2 only tulip is python 3 only tornado (supports 2 + 3) http://www.tornadoweb.org twisted pyev etc... Options: 1) use eventlet and have the same path of migration as the rest of openstack. Basically give up python 3 for now. 2) use tulip and give up python 2 3) choose an existing framework that supports both py2+3 Thoughts? Since we are starting out fresh, I'd suggest 2). This will mean some learning, but that is always fun and would be benefical to other projects to see how this code looks. I am not sure how important support for python 2 is, I'd suggest supporting python 3 is more important. -Angus ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Regarding language pack database schema
Hi Arati, I would vote for Option #2 as a short term solution. Probably later we can consider using NoSQL DB or MariaDB which has Column_JSON type to store complex types. Thanks Georgy On Thu, Feb 13, 2014 at 8:12 AM, Arati Mahimane arati.mahim...@rackspace.com wrote: Hi All, I have been working on defining the Language pack database schema. Here is a link to my review which is still a WIP - https://review.openstack.org/#/c/71132/3. There are a couple of different opinions on how we should be designing the schema. Language pack has several complex attributes which are listed here - https://etherpad.openstack.org/p/Solum-Language-pack-json-format We need to support search queries on language packs based on various criteria. One example could be 'find a language pack where type='java' and version1.4' Following are the two options that are currently being discussed for the DB schema: *Option 1:* Having a separate table for each complex attribute, in order to achieve normalization. The current schema follows this approach. However, this design has certain drawbacks. It will result in a lot of complex DB queries and each new attribute will require a code change. *Option 2:* We could have a predefined subset of attributes on which we would support search queries. In this case, we would define columns (separate tables in case of complex attributes) only for this subset of attributes and all other attributes will be a part of a json blob. With this option, we will have to go through a schema change in case we decide to support search queries on other attributes at a later stage. I would like to know everyone's thoughts on these two approaches so that we can take a final decision and go ahead with one approach. Suggestions regarding any other approaches are welcome too! Thanks, Arati ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] non-trivial example - IBM Connections [and Murano]
Hi Mike, Thank you for clarification. I like your approach with Ruby and I think this is a right way to solve such tasks like DSL creation. In Murano we use Yaml and python just to avoid introduction of a whole new language like Ruby to OpenStack. As for software configurations in heat, we are eager to have it available for use. We use Heat in Murano and we want to pass as much as possible work to Heat engine. Murano itself is intended to be an Application Catalog for managing available application packages and focuses on UI and user experience rather then on deployment details. We still use DSL for several things, have something working while waiting for Heat implementations, and to have imperative workflow engine which is useful when you need to orchestrate complex workflows. The last part is very powerful when you need to have an explicit control on deployment sequence with conditional branches orchestration among several different instances. When Mistral will be available we plan to use its workflow engine for task orchestration. Again, thank you for sharing the work you are doing in IBM. This is very good feedback for OpenStack community and helps to understand how OpenStack components used in enterprise use cases. Thanks Georgy On Sat, Feb 8, 2014 at 10:52 AM, Mike Spreitzer mspre...@us.ibm.com wrote: From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com ... Thank you for sharing this. It looks pretty impressive. Could you, please some details about DSL syntax, if it is possible? I will respond briefly, and pass your request along to the people working on that. In the Weaver language there are distinct concepts for software configuration vs. things (such as VMs) that can host software configs. As in the current software config work, there are distinct concepts for defining a software configuration vs. applying one to some particular infrastructure. Weaver supposes that local configuration is described in Chef; Weaver adds a way of connecting chef variables across machines. So you see, there are a lot of similarities with the current work on software config, which I support. Weaver takes advantage of the power of Ruby metaprogramming to add pretty natural and concise constructs for modeling infrastructure and software config. The source does not look like it is one level off, it looks like it is describing a thing rather than describing how to build a model of the thing (even though that is what it is actually doing). Embedding in Ruby adds powerful and familiar support for abstraction and customized repetition in descriptions of distributed systems. This is going to be hard to do nicely in a language (regardless of whether it uses JSON or YAML syntax) that is primarily for data representation. One of the points of sharing this example was to show a system for which you would like such power. What is the unique problem that Murano is addressing? The current software config work can deploy multiple configs to a target. Supposing that the local config (the non-distributed base configuration management tool involved, which is open in the current software config work) is expressed using something sufficiently powerful (chef and bash are examples), the local config language can do abstraction and composition in the description of local configuration. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] non-trivial example - IBM Connections
Hi Mike, Thank you for sharing this. It looks pretty impressive. Could you, please some details about DSL syntax, if it is possible? In our Murano project we are also solving the problem of Heat template generation. At his moment we are working on a new DSL for Murano to move from XMLs based DSL to simplified lightweight Yaml based DSL syntax. Here is an example how this new DSL looks like. https://github.com/istalker2/MuranoDsl/blob/master/meta/com.mirantis.murano.services.windows.activeDirectory.PrimaryController/manifest.yaml Using Murano DSL it is possible to combine multiple Applications defined by their manifests and then Murano engine will create Heat template for the whole environment by using Heat snippets available in Murano. Thanks Georgy On Thu, Feb 6, 2014 at 11:16 PM, Mike Spreitzer mspre...@us.ibm.com wrote: Thanks to work by several colleagues, I can share a non-trivial Heat template for a system that we have been using as an example to work. It is in the TAR archive here: https://drive.google.com/file/d/0BypF9OutGsW3Z2JqVTcxaW1BeXc/edit?usp=sharing Start at connections.yaml. Also in the archive are other files referenced from that template. The system described is a non-trival J2EE application, IBM Connections. It is a suite of collaboration applications, including things like wiki, file sharing, blogs, and directory of people. It is deployed into a system of WebSphere application servers. The servers are organized into four clusters of four servers each; each server is a VM with a single application server. The applications are partitioned among the four clusters. There is also a deployment manager, a VM and process used to manage the application servers. There is also a pair of HTTP servers --- the IBM Http Server (IHS), basically the Apache httpd. There is also a database server, running DB2. This system makes reference to an external (not deployed by the template) NFS server and an extenal LDAP server. The template describes both the VMs and the configuration of the software on them. The images used have the IBM software installed but not configured. This template (and the referenced files) were produced by automatic translation from sources expressed in Weaver into a Heat template that is ready to run. Weaver is a system for describing both infrastructure and software configuration (based on Chef). A Weaver description is a modular Ruby program that computes a model of the infrastructure and software; Weaver includes certain constructs tailored to this job, you may think of this as a DSL embedded in Ruby. The cross-machine dependencies are described abstractly in the source, connected to things in the Chef. Weaver uses an implementation that is different from the one being implemented now; Weaver's is based on communication through Zookeeper. You will see in the Heat the convolution of the user's input and Weaver's implementation (as Heat has no built in support for this mechanism). (I say these things not as a sales pitch, but to explain what you will see.) You will not be able to instantiate this template, as it has several references to external servers that are part of our environment, including those mentioned above. In fact, I have edited the external references to remove some private details. This template is presented as an example to look at. Regards, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] How to model resources in Heat
Hi,
There is a stackforge project Mistral which is aimed to provide generic
workflow service. I believe Zane mentioned it in his previous e-mail.
Currently, this project is at a pilot stage. Mistral has working pilot with
all core components implemented and right now we are finalizing DSL syntax
for task definitions. Mistral can call any API endpoint which is defined in
a task and Mistral exposes hooks to trig workflow execution on some
external event.
There will be a meetup where Renat Akhmerov (Mistral lead) will present
Mistral, its use cases and current status of the project followed by a
demo. Here is a link: http://www.meetup.com/openstack/events/163020092/
We plan to finish Mistral core development during Icehouse release and
apply for an incubation. I think in J release Mistral can be used by other
OpenStack projects as all bits an pieces will be available at this time.
Thanks
Georgy
On Fri, Jan 31, 2014 at 4:53 AM, Hugh Brock hbr...@redhat.com wrote:
On Jan 31, 2014, at 1:30 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Zane Bitter's message of 2014-01-30 19:30:40 -0800:
On 30/01/14 16:54, Clint Byrum wrote:
I'm pretty sure it is useful to model images in Heat.
Consider this scenario:
resources:
build_done_handle:
type: AWS::CloudFormation::WaitConditionHandle
build_done:
type: AWS::CloudFormation::WaitCondition
properties:
handle: {Ref: build_done_handle}
build_server:
type: OS::Nova::Server
properties:
image: build-server-image
userdata:
join [ ,
- #!/bin/bash\n
- build_an_image\n
- cfn-signal -s SUCCESS
- {Ref: build_done_handle}
- \n]
built_image:
type: OS::Glance::Image
depends_on: build_done
properties:
fetch_url: join [ , [http://;, {get_attribute: [
build_server, fixed_ip ]}, /image_path]]
actual_server:
type: OS::Nova::Server
properties:
image: {Ref: built_image}
Anyway, seems rather useful. Maybe I'm reaching.
Well, consider that when this build is complete you'll still have the
server you used to build the image still sitting around. Of course you
can delete the stack to remove it - and along with it will go the image
in Glance. Still seem useful?
No, not as such. However I have also discussed with other users having
an OS::Heat::TemporaryServer which is deleted after a wait condition is
signaled (resurrected on each update). This would be useful for hosting
workflow code as the workflow doesn't actually need to be running all
the time. It would also be useful for heat resources that want to run
code that needs to be contained into their own VM/network such as the
port probe thing that came up a few weeks ago.
Good idea? I don't know. But it is the next logical step my brain keeps
jumping to for things like this.
(I'm conveniently ignoring the fact that you could have set
DeletionPolicy: Retain on the image to hack your way around this.)
What you're looking for is a workflow service (I think it's called
Mistral this week?). A workflow service would be awesome, and Heat is
pretty awesome, but Heat is not a workflow service.
Totally agree. I think workflow and orchestration have an unusual
relationship though, because orchestration has its own workflow that
users will sometimes need to defer to. This is why we use wait
conditions, right?
So yeah, Glance images in Heat might be kinda useful, but at best as a
temporary hack to fill in a gap because the Right Place to implement it
doesn't exist yet. That's why I feel ambivalent about it.
I think you've nudged me away from optimistic at least closer to
ambivalent as well.
We (RH tripleo folks) were having a similar conversation around Heat and
stack upgrades the other day. There is unquestionably a workflow involving
stack updates when a user goes to upgrade their overcloud, and it's awkward
trying to shoehorn it into Heat (Steve Dake agreed). Our first thought was
Tuskar should do that, but our second thought was Whatever the workflow
service is should do that, and Tuskar should maybe provide a shorthand API
for it.
I feel like we (tripleo) need to take a harder look at getting a working
workflow thing available for our needs, soon...
--Hugh
___
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
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev
Re: [openstack-dev] [Solum] Oslo Context and SecurityContext
Hi Angus, Let me share my view on this. I think we need to distinguish implementation and semantics. Context means that you provide an information for method but method will not keep or store this information. Method does not own context but can modify it. Context does not explicitly define what information will be used by method. Context usually used when you keep some state and this state is shared between methods. Parameters in contrary are part of method definition and strictly define that method requires them. So semantically there is a difference between context and parameters, while implementation can be the same. Lets take this example: https://review.openstack.org/#/c/69308/5/solum/objects/plan.py There is a class Plan which defines a model for specific entity. The method definition def create(self, context): shows us that there is no required parameters but method result might be affected by context and the context itself might be affected by this method. It does not say what will be the behavior and what will be a resulting plan, but even with empty context it will return something meaningful. Also it will be reasonable to expect that I will have mostly the same result for different contexts like RequestContext in API call and ExecutionContext in a working code when worker executes this plan. Now I am reading test https://review.openstack.org/#/c/69308/5/solum/tests/objects/test_plan.pytest case test_check_data. From what I see here I can figure out is that Plan actually stores all values from context inside plan object as its attributes and just adds additional attribute id. There is a question: Is plan just a copy of Context with id? Why do we need it? What are the functions of plan and what it consist of? If plan needs parameters and context its really just a container for parameters, lets use **kwargs or something more meaningful which clearly defines how to use Plan and what are its methods. We want to define a data model for a Plan entity. Lets clearly express what data is mandatory for a plan object like Plan.create(project_id, user_id, raw_data, context). Let's keep data model clear and well defined instead of blur it with meaningless contexts. On Tue, Jan 28, 2014 at 3:26 PM, Angus Salkeld angus.salk...@rackspace.comwrote: On 28/01/14 07:13 -0800, Georgy Okrokvertskhov wrote: Hi, From my experience context is usually bigger then just a storage for user credentials and specifics of request. Context usually defines an area within the called method should act. Probably the class name RequestContext is a bit confusing. The actual goal of the context should be defined by a service design. If you have a lot of independent components you will probably will ned to pass a lot of parameters to specify specifics of work, so it is just more convenient to have dictionary like object which carry all necessary information about contextual information. This context can be used to pass information between different components of the service. I think we should be using the nova style objects for passing data between solum services (they can be serialized for rpc). But you hit on a point - this context needs to be called something else, it is not a RequestContext (we need the RequestContext regardless). I'd also suggest we don't build it until we know we need it (I am just suspicious as the other openstack services I have worked on don't have such a thing). Normally we just pass arguments to methods. How about we keep things simple and don't get into designing a boeing, we can always add these things later if they are really needed. I get the feeling we are being distracted from our core problem of getting this service functional by nice to haves. -Angus On Mon, Jan 27, 2014 at 4:27 PM, Angus Salkeld angus.salk...@rackspace.comwrote: On 27/01/14 22:53 +, Adrian Otto wrote: On Jan 27, 2014, at 2:39 PM, Paul Montgomery paul.montgom...@rackspace.com wrote: Solum community, I created several different approaches for community consideration regarding Solum context, logging and data confidentiality. Two of these approaches are documented here: https://wiki.openstack.org/wiki/Solum/Logging A) Plain Oslo Log/Config/Context is in the Example of Oslo Log and Oslo Context section. B) A hybrid Oslo Log/Config/Context but SecurityContext inherits the RequestContext class and adds some confidentiality functions is in the Example of Oslo Log and Oslo Context Combined with SecurityContext section. None of this code is production ready or tested by any means. Please just examine the general architecture before I polish too much. I hope that this is enough information for us to agree on a path A or B. I honestly am not tied to either path very tightly but it is time that we reach a final decision on this topic IMO. Thoughts? I have a strong preference for using the SecurityContext approach. The main reason for my
Re: [openstack-dev] [Solum] Oslo Context and SecurityContext
Hi,
From my experience context is usually bigger then just a storage for user
credentials and specifics of request. Context usually defines an area
within the called method should act. Probably the class name RequestContext
is a bit confusing. The actual goal of the context should be defined by a
service design. If you have a lot of independent components you will
probably will ned to pass a lot of parameters to specify specifics of work,
so it is just more convenient to have dictionary like object which carry
all necessary information about contextual information. This context can be
used to pass information between different components of the service.
On Mon, Jan 27, 2014 at 4:27 PM, Angus Salkeld
angus.salk...@rackspace.comwrote:
On 27/01/14 22:53 +, Adrian Otto wrote:
On Jan 27, 2014, at 2:39 PM, Paul Montgomery
paul.montgom...@rackspace.com
wrote:
Solum community,
I created several different approaches for community consideration
regarding Solum context, logging and data confidentiality. Two of these
approaches are documented here:
https://wiki.openstack.org/wiki/Solum/Logging
A) Plain Oslo Log/Config/Context is in the Example of Oslo Log and Oslo
Context section.
B) A hybrid Oslo Log/Config/Context but SecurityContext inherits the
RequestContext class and adds some confidentiality functions is in the
Example of Oslo Log and Oslo Context Combined with SecurityContext
section.
None of this code is production ready or tested by any means. Please
just
examine the general architecture before I polish too much.
I hope that this is enough information for us to agree on a path A or B.
I honestly am not tied to either path very tightly but it is time that we
reach a final decision on this topic IMO.
Thoughts?
I have a strong preference for using the SecurityContext approach. The
main reason for my preference is outlined in the Pro/Con sections of the
Wiki page. With the A approach, leakage of confidential information mint
happen with *any* future addition of a logging call, a discipline which may
be forgotten, or overlooked during future code reviews. The B approach
handles the classification of data not when logging, but when placing the
data into the SecurityContext. This is much safer from a long term
maintenance perspective.
I think we seperate this out into:
1) we need to be security aware whenever we log information handed to
us by the user. (I totally agree with this general statement)
2) should we log structured data, non structured data or use the
notification mechanism (which is structured)
There have been some talks at summit about the potential merging of
the logging and notification api, I honestly don't know what
happened to that but have no problem with structured logging. We
should use the notification system so that ceilometer can take
advantage of the events.
3) should we use a RequestContext in the spirit of the olso-incubator
(and inherited from it too). OR one different from all other
projects.
IMHO we should just use oslo-incubator RequestContext. Remember the
context is not a generic dumping ground for I want to log stuff so
lets put it into the context. It is for user credentials and things
directly associated with the request (like the request_id). I don't
see why we need a generic dict style approach, this is more likely
to result in programming error context.set_priv('userid', bla)
instead of:
context.set_priv('user_id', bla)
I think my point is: We should very quickly zero in on the
attributes we need in the context and they will seldom change.
As far as security goes Paul has shown a good example of how to
change the logging_context_format_string to achieve structured and
secure logging of the context. oslo log module does not log whatever
is in the context but only what is configured in the solum.conf (via
logging_context_format_string). So I don't believe that the
new/different RequestContext provides any improved security.
-Angus
Adrian
___
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
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Meetup Schedule Posted!
Hi Mark, Happy Martin Luther King Jr. Day! Will Google hangout or skype meeting available for remote participants? I know few engineers who will not be able to attend this mini-summit in person but they will be happy to join remotely. Thanks, Georgy On Mon, Jan 20, 2014 at 1:22 AM, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks, First things first: Happy Martin Luther King Jr. Day! Our mini summit / meetup for the Icehouse cycle will take place in one week's time. To ensure we are all ready and know what to expect, I have started a wiki page tracking the event details and a tentative schedule. Please have a look if you plan to attend. https://wiki.openstack.org/wiki/Glance/IcehouseCycleMeetup I have taken the liberty of scheduling several of the topics we have already discussed. Let me know if anything in the existing schedule creates a conflict for you. There are also presently 4 unclaimed slots in the schedule. If your topic is not yet scheduled, please tell me the time you want and I will update accordingly. EXTRA IMPORTANT: If you plan to attend the meetup but have not spoken with me, please respond as soon as possible to let me know your plans. We have a limited number of seats remaining. Cheers, markwash Our only hope today lies in our ability to recapture the revolutionary spirit and go out into a sometimes hostile world declaring eternal hostility to poverty, racism, and militarism. I knew that I could never again raise my voice against the violence of the oppressed in the ghettos without having first spoken clearly to the greatest purveyor of violence in the world today, my own government. - Martin Luther King, Jr. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Architect, OpenStack Platform Products, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum][Keystone] Best practices for storing keystone trusts information
Hi, In Solum project we want to use Keystone trusts to work with other OpenStack services on behalf of user. Trusts are long term entities and a service should keep them for a long time. I want to understand what are best practices for working with trusts and storing them in a service? What are the options to keep trust? I see obvious approaches like keep them in a service DB or keep them in memory. Are there any other approaches? Is there a proper way to renew trust? For example if I have a long term task which is waiting for external event, how to keep trust fresh for a long and unpredicted period? Thanks Georgy ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status
Hi Travis, I think it will be discussed on the mini-summit which will be on Jan 27th-28th in Washington DC. Here is an etherpad with the summit agenda: https://etherpad.openstack.org/p/glance-mini-summit-agenda I hope that after F2F discussion all BPs will have priority and assignment. Thanks Georgy On Fri, Jan 17, 2014 at 10:11 AM, Tripp, Travis S travis.tr...@hp.comwrote: Hello All, I just took a look at this blueprint and see that it doesn’t have any priority. Was there a discussion on priority? Any idea what, if any of this will make it into Icehouse? Also, are there going to be any further design sessions on it? Thanks, Travis *From:* Georgy Okrokvertskhov [mailto:gokrokvertsk...@mirantis.com] *Sent:* Friday, December 20, 2013 3:43 PM *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [Glance] [Metadatarepository] Metadata repository initiative status Hi, Metadata repository meeting occurred this Tuesday in #openstack-glance channel. Main item that was discussed was an API for a new metadata functions and where this API should appear. During discussion it was defined that the main functionality will be a storage for different objects and metadata associated with them. Initially all objects will have a specific type which defines specific attributes in metadata. There will be also a common set of attributes for all objects stored in Glance. During the discussion there was an input from different projects (Hest, Murano, Solum) what kind of objects should be stored for each project and what kind functionality is minimally required. Here is a list of potential objects: Heat: · HOT template Potential Attributes: version, tag, keywords, etc. *Required Features:* · Object and metadata versioning · Search by specific attribute\attributes value *Murano* · *Murano files* o UI definition o workflow definition o HOT templates o Scripts *Required Features:* · Object and metadata versioning · Search by specific attribute Solum · Solum Language Packs *Potential Attributes:* name, build_toolchain, OS, language platform, versions *Required Features:* · Object and metadata versioning · Search by specific attribute After a discussion it was concluded that the best way will be to add a new API endpoint /artifacts. This endpoint will be used to work with object’s common attributes while type specific attributes and methods will be accessible through /artifact/object-type endpoint. The endpoint /artifacts will be used for filtering objects by searching for specific attributes value. Type specific attributes search should also be possible via /artifacts endpoint. For each object type there will be a separate table for attributes in a database. Currently it is supposed that metadata repository API will be implemented inside Glance within v2 version without changing existing API for images. In the future, v3 Glance API can fold images related API to the common artifacts API. New artifact’s API will reuse as much as possible from existing Glance functionality. Most of the stored objects will be non-binary, so it is necessary to check how Glance code handle this. AI All projects teams should start submit BPs for new functionality in Glance. These BPs will be discussed in ML and on Glance weekly meetings. Related Resources: Etherpad for Artifacts API design: https://etherpad.openstack.org/p/MetadataRepository-ArtifactRepositoryAPI Heat templates repo BP for Heat: https://blueprints.launchpad.net/heat/+spec/heat-template-repo Initial API discussion Etherpad: https://etherpad.openstack.org/p/MetadataRepository-API Thanks Georgy ___ 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
