Re: [openstack-dev] [Requirements] Freeze

No worries, good to know I did not miss anything about release procedures :-) Thanks, Dmitry On Mon, Jan 30, 2017 at 6:51 PM, Matthew Thode wrote: > On 01/30/2017 03:24 AM, Dmitry Mescheryakov wrote: > > Hello Matthew, > > > > I see that you have frozen my > > CR h

Re: [openstack-dev] [Requirements] Freeze

Hello Matthew, I see that you have frozen my CR https://review.openstack.org/#/c/425132/ , but it is for stable/newton. Should not freeze apply to master only? Thanks, Dmitry On Wed, Jan 25, 2017 at 12:22 AM, Matthew Thode wrote: > We are going to be freezing Thursday at ~20:00 UTC. > > So if

Re: [openstack-dev] [fuel][plugins] Detached components plugin update requirement

Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Wed, Jan 20, 2016 at 6:41 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> Sergii, >> >> I am curious - does it mean that the plugins will stop working with older &g

Re: [openstack-dev] [fuel][plugins] Detached components plugin update requirement

Sergii, I am curious - does it mean that the plugins will stop working with older versions of Fuel? Thanks, Dmitry 2016-01-20 19:58 GMT+03:00 Sergii Golovatiuk : > Hi, > > Recently I merged the change to master and 8.0 that moves one task from > Nailgun to Library [1]. Actually, it replaces [2

Re: [openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"

days > > > > [1] https://wiki.openstack.org/wiki/FeatureFreeze > > [2] > > > http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html > > [3] > > > http://lists.openstack.org/pipermail/openstack-dev/2015-December/081149.html > >

[openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"

Hello folks, I'd like to request extension of current FFE for the feature [1]. During the three FFE days we merged the spec [2] after big discussion and made a couple iterations over the implementation [3]. We had a chat with Bogdan on how to progress and here are the action items still need to be

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

2015-12-02 16:52 GMT+03:00 Jordan Pittier : > > On Wed, Dec 2, 2015 at 1:05 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> >> >> My point is simple - lets increase our architecture scalability by 2-3 >> times by _maybe_ causing

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

y. Overall, I think current results are already enough to consider the change useful. What is left is to confirm that it does not make our failover worse. > > > > 2015-12-01 20:53 GMT+01:00 Sergii Golovatiuk : > >> Hi, > >> > >> -1 for FFE for disabling HA f

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

I'm uncertain about the stability impact of this change, yet >> I see a reasoning worth discussing behind it. >> >> 2015-12-01 20:53 GMT+01:00 Sergii Golovatiuk : >> > Hi, >> > >> > -1 for FFE for disabling HA for RPC queue as we do not know all si

[openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

Folks, I would like to request feature freeze exception for disabling HA for RPC queues in RabbitMQ [1]. As I already wrote in another thread [2], I've conducted tests which clearly show benefit we will get from that change. The change itself is a very small patch [3]. The only thing which I want

[openstack-dev] [Fuel] Disabling HA for RPC queues in RabbitMQ

Hello guys, I would like to propose to disable HA for OpenStack RPC queues. The rationale is to reduce load on RabbitMQ by removing necessity for it to replicate messages across the cluster. You can find more details about proposal in spec [1]. To what is in the spec I can add that I've ran a tes

Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions

Hello folks, I second Patrick's idea. In our case we would like to install standalone RabbitMQ cluster with Fuel reference architecture to perform destructive tests on it. Requirement to install controller is an excessive burden in that case. Thanks, Dmitry 2015-10-19 13:44 GMT+03:00 Patrick Pe

Re: [openstack-dev] [Fuel][RabbitMQ][puppet] Kilo status of the heartbeats implementation

Bogdan, Answering your questions, in MOS 7.0 source code heartbeats are enabled by default (with heartbeat_timeout_threshold value set to 60). We patched our version of upstream stable/kilo to do so. So, in installed env heartbeats are enabled for every component except Neutron, for which puppet m

Re: [openstack-dev] [Fuel] Default templates for Sahara feature in 6.0

really want to have 5.1.1. Thanks, Dmitry 2014-11-15 3:04 GMT+03:00 Dmitry Borodaenko : > +286 lines a week after Feature Freeze, IMHO it's too late to make an > exception for this one. > > On Wed, Nov 12, 2014 at 7:37 AM, Dmitry Mescheryakov > wrote: > > Hello fueler

Re: [openstack-dev] [Fuel] Default templates for Sahara feature in 6.0

Oops, the last line should be read as "On the other side, it is a nice UX feature we really want to have 6.0" Dmitry 2014-11-15 3:50 GMT+03:00 Dmitry Mescheryakov : > Dmitry, > > Lets review the CR from the point of danger to current deployment process: > in the essence it

[openstack-dev] [Fuel] Default templates for Sahara feature in 6.0

Hello fuelers, I would like to request you merging CR [1] which implements blueprint [2]. It is a nice UX feature we really would like to have in 6.0. On the other side, the implementation is really small: it is a small piece of puppet which runs a shell script. The script always exits with 0, so

Re: [openstack-dev] [keystone][swift] Has anybody considered storing tokens in Swift?

Hey Jay, Did you consider Swift's eventual consistency? The general use case for many OpenStack application is: 1. obtain the token from Keystone 2. perform some operation in OpenStack providing token as credentials. As a result of operation #1 the token will be saved into Swift by the Keystone

Re: [openstack-dev] [Sahara][Doc] Updating documentation for overview; Needs changing image

Hello, I used google docs to create the initial image. If you want to edit that one, copy the doc[1] to your drive and edit it. It is not the latest version of the image, but the only difference is that this one has the very first project name EHO in place of Sahara. Thanks, Dmitry [1] https://

[openstack-dev] [Fuel] Working on 6.0 and new releases in general

Hello Fuelers, Right now we have the following policy in place: the branches for a release are opened only after its 'parent' release have reached hard code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and 6.0. And that is the problem: if parent release is delayed, we can't properl

[openstack-dev] [Fuel] Doc team working with bugs

Hello Fuelers, On the previous meeting a topic was raised on how Fuel doc team should work with bugs, see [1] for details. We agreed to move the discussion into the mailing list. The thing is there are two members in the team at the moment (Meg and Irina) and they need to distribute work among th

Re: [openstack-dev] [Sahara] Swift authentication and backwards compatibility

Hello people, >> I think backward compatibility is a good idea. We can make the >> user/pass inputs for data objects optional (they are required >> currently), maybe even gray them out in the UI with a checkbox to turn >> them on, or something like that. > > > This is similar to what I was thinki

[openstack-dev] [sahara] team meeting minutes July 3

Again, thanks everyone who have joined Sahara meeting. Below are the logs from the meeting. Minutes: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.html Logs: http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-07-03-18.06.log.html Thanks, Dmitry _

Re: [openstack-dev] [sahara] 2014.1.1 preparation

I agree with Andrew and actually think that we do need to have https://review.openstack.org/#/c/87573 (Fix running EDP job on transient cluster) fixed in stable branch. We also might want to add https://review.openstack.org/#/c/93322/ (Create trusts for admin user with correct tenant name). This i

[openstack-dev] [Sahara] Split sahara-api into api and engine

Hello people, The following patch set splits monolithic sahara-api process into two - sahara-api and sahara-engine: https://review.openstack.org/#/c/90350/ After the change is merged, there will be three binaries to run Sahara: * sahara-all - runs Sahara all-in-one (like sahara-api does right no

Re: [openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs

On Wed, Apr 09, 2014 at 03:19:10PM +0400, > Dmitry Mescheryakov wrote: > >> Hello Isaku, >> >> Thanks for sharing this! Right now in Sahara project we think to use >> Marconi as a mean to communicate with VM. Seems like you are familiar >> with the di

Re: [openstack-dev] [olso][neutron] proxying oslo.messaging from management network into tenant network/VMs

Hello Isaku, Thanks for sharing this! Right now in Sahara project we think to use Marconi as a mean to communicate with VM. Seems like you are familiar with the discussions happened so far. If not, please see links at the bottom of UnifiedGuestAgent [1] wiki page. In short we see Marconi's support

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

14-03-25 0:33 GMT+04:00 Chris Friesen : > On 03/24/2014 01:27 PM, Dmitry Mescheryakov wrote: >> >> I see two possible explanations for these 5 remaining queues: >> >> * They were indeed recreated by 'compute' services. I.e. controller >> service send

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

ly = wait_for_reply(queue=self.reply_q, msg_id=msg_id) Dmitry 2014-03-24 19:52 GMT+04:00 Chris Friesen : > On 03/24/2014 02:59 AM, Dmitry Mescheryakov wrote: >> >> Chris, >> >> In oslo.messaging a single reply queue is used to gather results from >> all the call

Re: [openstack-dev] auto-delete in amqp "reply_*" queues in OpenStack

Chris, In oslo.messaging a single reply queue is used to gather results from all the calls. It is created lazily on the first call and is used until the process is killed. I did a quick look at oslo.rpc from oslo-incubator and it seems like it uses the same pattern, which is not surprising since o

Re: [openstack-dev] [Oslo] [Marconi] oslo.messaging on VMs

, Steven Dake wrote: >> >> On 03/06/2014 10:24 AM, Daniel P. Berrange wrote: >>> >>> On Thu, Mar 06, 2014 at 07:25:37PM +0400, Dmitry Mescheryakov wrote: >>>> >>>> Hello folks, >>>> >>>> A number of OpenStack and related

Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud

For what it's worth in Sahara (former Savanna) we inject the second key by userdata. I.e. we add echo "${public_key}" >> ${user_home}/.ssh/authorized_keys to the other stuff we do in userdata. Dmitry 2014-03-10 17:10 GMT+04:00 Jiří Stránský : > On 7.3.2014 14:50, Imre Farkas wrote: >> >> On 03/0

Re: [openstack-dev] [nova][novaclient] How to get user's credentials for using novaclient API?

Hello Nader, You should use python-keystoneclient [1] to obtain the token. You can find example usage in helper script [2]. Dmitry [1] https://github.com/openstack/python-keystoneclient [2] https://github.com/openstack/savanna/blob/master/tools/get_auth_token.py#L74 2014-03-10 21:25 GMT+04:00

Re: [openstack-dev] I am taking sick leave for today

Ooops, sorry, wrong recepient :-) 7 марта 2014 г., 14:13 пользователь Dmitry Mescheryakov написал: > Коллеги, > > Сегодня я опять беру выходной по болезни. Начал поправляться но все > еще чувствую себя неуверенно. Надеюсь вылечиться целиком ко вторнику.

[openstack-dev] I am taking sick leave for today

Коллеги, Сегодня я опять беру выходной по болезни. Начал поправляться но все еще чувствую себя неуверенно. Надеюсь вылечиться целиком ко вторнику. Дмитрий ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bi

[openstack-dev] [Oslo] oslo.messaging on VMs

Hello folks, A number of OpenStack and related projects have a need to perform operations inside VMs running on OpenStack. A natural solution would be an agent running inside the VM and performing tasks. One of the key questions here is how to communicate with the agent. An idea which was discuss

[openstack-dev] Unified Guest Agent in Savanna

Hello folks, Not long ago we had a discussion on unified guest agent [1] - a way for performing actions 'inside' VMs. Such thing is needed for PaaS projects for tasks such as application reconfiguration and user requests pass-through. As a proof of concept I've made os_collect_config as a guest a

Re: [openstack-dev] [savanna] Choosing provisioning engine during cluster launch

I agree with Andrew. I see no value in letting users select how their cluster is provisioned, it will only make interface a little bit more complex. Dmitry 2014/1/30 Andrew Lazarev > Alexander, > > What is the purpose of exposing this to user side? Both engines must do > exactly the same thing

[openstack-dev] Unified Guest Agent, PoC for os-collect-config

Hello folks, At the end of the previous discussion on the topic [1] I've decided to make a PoC based on oslo.messaging. Clint suggested and I agreed to make it for os-collect-config. Actually I've made a PoC for Savanna first :-) but anyway here is the one for os-collect-config [2]. I've made a c

Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

he Infra team, and newbies to OpenStack wouldn't have > to deal with dozens of different ways of doing things, but the important > thing is that other methods of communication would still be possible. > > Thanks, > > Tim > > > From: Dmitry Mescheryakov [mailto:dmescherya...@mi

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

'm ok with these ideas, and while I still > disagree with having a single, forced standard for RPC communication, I > should probably let things pan out a bit before being too concerned. > > - Tim > > > > From: Dmitry Mescheryakov [dmesc

Re: [openstack-dev] [Heat] [Trove] [Savanna] [Oslo] Unified Agents - what is the actual problem?

I agree that enabling communication between guest and cloud service is a common problem for most agent designs. The only exception is agent based on hypervisor provided transport. But as far as I understand many people are interested in network-based agent, so indeed we can start a thread (or conti

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

n out a bit before being too concerned. > > - Tim > > > ------ > *From:* Dmitry Mescheryakov [dmescherya...@mirantis.com] > *Sent:* Wednesday, December 18, 2013 11:51 AM > *To:* OpenStack Development Mailing List (not for usage questions) > > *Su

Re: [openstack-dev] Unified Guest Agent proposal

That sounds like a very good idea, I'll do it. 2013/12/18 Clint Byrum > Excerpts from Dmitry Mescheryakov's message of 2013-12-18 09:32:30 -0800: > > Clint, do you mean > > * use os-collect-config and its HTTP transport as a base for the PoC > > or > > * migrate os-collect-config on PoC aft

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

2013/12/18 Steven Dake > On 12/18/2013 08:34 AM, Tim Simpson wrote: > > I've been following the Unified Agent mailing list thread for awhile now > and, as someone who has written a fair amount of code for both of the two > existing Trove agents, thought I should give my opinion about it. I like

Re: [openstack-dev] [trove] My thoughts on the Unified Guest Agent

Tim, The unified agent we proposing is based on the following ideas: * the core agent has _no_ functionality at all. It is a pure RPC mechanism with the ability to add whichever API needed on top of it. * the API is organized into modules which could be reused across different projects. * th

Re: [openstack-dev] Unified Guest Agent proposal

Clint, do you mean * use os-collect-config and its HTTP transport as a base for the PoC or * migrate os-collect-config on PoC after it is implemented on oslo.messaging I presume the later, but could you clarify? 2013/12/18 Clint Byrum > Excerpts from Dmitry Mescheryakov's message of 2013-

Re: [openstack-dev] Unified Guest Agent proposal

Hello Thomas, I do understand your feelings. The problem is there were already many points raised both pro and contra adopting Salt as an agent. And so far no consensus was reached on that matter. Maybe someone else is willing to step out and write a PoC for Salt-based agent? Then we can agree on

Re: [openstack-dev] Unified Guest Agent proposal

Folks, The discussion didn't result in a consensus, but it did revealed a great number of things to be accounted. I've tried to summarize top-level points in the etherpad [1]. It lists only items everyone (as it seems to me) agrees on, or suggested options where there was no consensus. Let me know

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Alessandro Pilotti > Hi guys, > > This seems to become a pretty long thread with quite a lot of ideas. What > do you think about setting up a meeting on IRC to talk about what direction > to take? > IMO this has the potential of becoming a completely separated project to > be hosted on

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Sylvain Bauza > Why the notifications couldn't be handled by Marconi ? > > That would be up to Marconi's team to handle security issues while it is > part of their mission statement to deliver a messaging service in between > VMs. > Sylvain, very interesting suggestion! Marconi defini

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/13 Fox, Kevin M > Yeah, I think the extra nic is unnecessary too. There already is a working > route to 169.254.169.254, and a metadata proxy -> server running on it. > > So... lets brainstorm for a minute and see if there are enough pieces > already to do most of the work. > > We already

Re: [openstack-dev] Unified Guest Agent proposal

Still, what about one more server process users will have to run? I see unified agent as library which can be easily adopted by both exiting and new OpenStack projects. The need to configure and maintain Salt server process is big burden for end users. That idea will definitely scare off adoption o

Re: [openstack-dev] Unified Guest Agent proposal

Vladik, Thanks for the suggestion, but hypervisor-dependent solution is exactly what scares off people in the thread :-) Thanks, Dmitry 2013/12/11 Vladik Romanovsky > > Maybe it will be useful to use Ovirt guest agent as a base. > > http://www.ovirt.org/Guest_Agent > https://github.com/oVir

Re: [openstack-dev] Unified Guest Agent proposal

Clint, Kevin, Thanks for reassuring me :-) I just wanted to make sure that having direct access from VMs to a single facility is not a dead end in terms of security and extensibility. And since it is not, I agree it is much simpler (and hence better) than hypervisor-dependent design. Then return

Re: [openstack-dev] Unified Guest Agent proposal

>> What is the exact scenario you're trying to avoid? It is DDoS attack on either transport (AMQP / ZeroMQ provider) or server (Salt / Our own self-written server). Looking at the design, it doesn't look like the attack could be somehow contained within a tenant it is coming from. In the current

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/10 Clint Byrum > Excerpts from Dmitry Mescheryakov's message of 2013-12-10 08:25:26 -0800: > > And one more thing, > > > > Sandy Walsh pointed to the client Rackspace developed and use - [1], [2]. > > Its design is somewhat different and can be expressed by the following > > formulae: > >

Re: [openstack-dev] Unified Guest Agent proposal

ents-unix [2] https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver [3] https://wiki.openstack.org/wiki/GuestAgent 2013/12/10 Dmitry Mescheryakov > Guys, > > I see two major trends in the thread: > > * use Salt > * write our own solution with architecture sim

Re: [openstack-dev] Unified Guest Agent proposal

Region/Cell/Availability Zone will be left out of service. Do you think that is solvable, or maybe I overestimate the threat? Thanks, Dmitry 2013/12/9 Dmitry Mescheryakov > > > > 2013/12/9 Kurt Griffiths > >> This list of features makes me *very* nervous from a securi

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/9 Kurt Griffiths > This list of features makes me *very* nervous from a security > standpoint. Are we talking about giving an agent an arbitrary shell command > or file to install, and it goes and does that, or are we simply triggering > a preconfigured action (at the time the agent itse

Re: [openstack-dev] Unified Guest Agent proposal

2013/12/9 Clint Byrum > Excerpts from Steven Dake's message of 2013-12-09 09:41:06 -0800: > > On 12/09/2013 09:41 AM, David Boucha wrote: > > > On Sat, Dec 7, 2013 at 11:09 PM, Monty Taylor > > > wrote: > > > > > > > > > > > > On 12/08/2013 07:36 AM, Robert Colli

[openstack-dev] Unified Guest Agent proposal

Hello all, We would like to push further the discussion on unified guest agent. You may find the details of our proposal at [1]. Also let me clarify why we started this conversation. Savanna currently utilizes SSH to install/configure Hadoop on VMs. We were happy with that approach until recently

Re: [openstack-dev] [savanna] Anti-affinity

No, anti-affinity does not work that way. It allows to distribute nodes running the same process, but you can't separate nodes running different processes (i.e. master and workers). Dmitry 2013/12/5 Arindam Choudhury > Hi, > > Is it possible using anti-affinity to reserve a compute node only f

Re: [openstack-dev] [savanna] This request was rate-limited. (HTTP 413)

Hmm, not sure, I am not an expert in Nova. By the way the link I gave you is for Grizzly. If you are running a different release, take a look at that release doc as configuration might look different here. Dmitry 2013/12/5 Arindam Choudhury > Hi, > > I introduced this in my nova api-paste.ini:

Re: [openstack-dev] [savanna] Anti-affinity

Arindam, It is not achievable with the current Savanna. The anti-affinity feature allows to run one VM per compute-node only. It can not evenly distribute VMs in case the number of compute nodes is lower than the desired size of Hadoop cluster. Dmitry 2013/12/5 Arindam Choudhury > HI, > > I h

Re: [openstack-dev] [savanna] This request was rate-limited. (HTTP 413)

Hello Arindam, While deploying Hadoop cluster Savanna does pretty many API requests to Nova. Naturally, the number of requests is directly proportional to the size of the cluster. On the other hand Nova has a protection agains users abusing API with too many requests. It is called rate limiting.

Re: [openstack-dev] [heat][hadoop][template] Does anyone has a hadoop template

Hello Jay, Just in case you've missed it, there is a project Savanna dedicated to deploying Hadoop clusters on OpenStack: https://github.com/openstack/savanna http://savanna.readthedocs.org/en/0.3/ Dmitry 2013/11/29 Jay Lau > Hi, > > I'm now trying to deploy a hadoop cluster with heat, just

Re: [openstack-dev] [savanna] Loading of savanna.conf properties

; > On Nov 10, 2013, at 3:53 AM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > > Hey Jon, > > Can you post your code as a work in progress review? Maybe we can perceive > from the code what is wrong. > > Thanks, > > Dmitry > > > 2013/11/10

Re: [openstack-dev] [savanna] Loading of savanna.conf properties

Hey Jon, Can you post your code as a work in progress review? Maybe we can perceive from the code what is wrong. Thanks, Dmitry 2013/11/10 Jon Maron > Hi, > > I am debugging an issue with the swift integration - I see os_auth_url > with a value of 127.0.0.1, indicating that at the time the

Re: [openstack-dev] Fwd: [Openstack-Dev] Announcement of the Compass Deployment project

I've noticed you list "Remote install and configure a Hadoop cluster (synergy with Savanna?)" among possible use cases. Recently there was a discussion about Savanna on bare metal provisioning through Nova (see thread [1]). Nobody tested that yet, but it was concluded that it should work without an

Re: [openstack-dev] [Savanna] Savanna on Bare Metal and Base Requirements

Hello Travis, We didn't researched Savanna on bare metal, though we considered it some time ago. I know little of bare metal provisioning, so I am rather unsure what problems you might experience. My main concern are images: does bare metal provisioning work with qcow2 images? Vanilla plugin (whi

Re: [openstack-dev] [Savanna] error in cluster launch: instance count gets to three, status=waiting, before going to error status

Kesten, The error occurs at the following line: https://github.com/stackforge/savanna/blob/master/savanna/service/instances.py#L293 The reason is that Savanna detects that one of instances it spawned entered 'Error' state. I.e. the problem is either in your OpenStack or in a way Savanna spawns in

Re: [openstack-dev] [savanna] Program name and Mission statement

Mike, and if you looked up 'compute' in dictionary, you would never guess what OpenStack Compute does :-). I think that 'Data Processing' is a good name which in short describes what Savanna is going to be. The name 'MapReduce' for the program does not cover whole functionality provided by Savanna

Re: [openstack-dev] [Savanna] Cluster launch error

Linus, Sorry for taking so long to respond. The cluster machines were removed by rollback which was caused by exception: 2013-08-04 11:08:33.907 3542 INFO savanna.service.instances [-] Cluster 'cluster-test-01' creation rollback (reason: unexpected type for addr arg) Looks like currently code h

Re: [openstack-dev] [Savanna] How to manage Hadoop configurations

Arindam, You may find examples of REST requests here: https://github.com/stackforge/savanna/tree/master/etc/rest-api-samples To get the full list of supported configs, send GET request to the following URL /v1.0/$TENANT/plugins/vanilla/1.1.2 Note that each config has 'scope' parameter. Configs w