Re: [openstack-dev] [Swift] code changes feedback

Alex, Probably you can use git review -D and follow https://wiki.openstack.org/wiki/Gerrit_Workflow#Drafts. But it seems you need to invite some reviewers to see your patch. I don't know whether that works for you, if you need feedback from a community group. Best Regards. -- Shane James E. Bl

Re: [openstack-dev] [networking][ml2] ML2 Mechanism Driver API proposal

12 jun 2013 kl. 09:25 skrev Andre Pech: > As promised at the ml2 kickoff meeting last week, attached is our basic > proposal for the ml2 mechanism driver API. Great, that is fast work! > After getting more familiar with the ml2 plugin code and looking at some of > the other blueprints that ar

Re: [openstack-dev] The future of run_tests.sh

On 06/18/2013 01:01 AM, Joe Gordon wrote: Hi All, A patch to move the run_tests.sh script into oslo-incubator (https://review.openstack.org/#/c/32736/), has brought up the bigger question of what is the future of './run_tests.sh.' This seems like a topic that directly affects all developers, so

[openstack-dev] Add IDE specific directories to .gitignore

Greetings fellows, There are several IDEs that are widely used for working on OpenStack. I can name PyCharm, Eclipse(PyDev) and Rope (Vim, Emacs). The IDEs mentioned above create specific folders to store project-related settings. Those folders then are displayed as untracked in git, i.e.: # On

Re: [openstack-dev] Add IDE specific directories to .gitignore

On Tue, Jun 18, 2013 at 9:50 AM, Roman Prykhodchenko wrote: > Of course, it's possible to modify local .git/info/exclude but isn't it > reasonable to include the most common folders to our .gitignore? Why the user is not setting this up in his global exclude git file https://help.github.com/art

[openstack-dev] [Oslo] Common testtool wrapper

Hi stackers, During my work on BP Common testtools wrapper I've prepared a patch, which adds new file to oslo library. I took tests/utils.py from Oslo as basis and then added few classes from Nova. Could somebody review my patch? The l

Re: [openstack-dev] The future of run_tests.sh

Joe Gordon wrote: > Reasons to keep run_tests.sh: > > * there is no possibility to run tests with testtools instead of testr. > This feature allows us to use the debugger. > * in some projects tox doesn't use a testr wrapper to report progress > while tests are running > * building the sdist can

Re: [openstack-dev] Add IDE specific directories to .gitignore

Chmouel, Yes, it's possible to set up excluded directories in several ways. My question was why not make those directories excluded by default? - Roman On Jun 18, 2013, at 11:14 , Chmouel Boudjnah wrote: > On Tue, Jun 18, 2013 at 9:50 AM, Roman Prykhodchenko > wrote: >> Of course, it's possi

Re: [openstack-dev] Add IDE specific directories to .gitignore

On 18/06/13 12:14 +0300, Roman Prykhodchenko wrote: Chmouel, Yes, it's possible to set up excluded directories in several ways. My question was why not make those directories excluded by default? I'd rather let the user ignore those dirs locally instead of putting them in project's .gitignor

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

I'm not sure I understand why the user might want to access the disk_config value from within the guest? This seems to be something they could infer from the partition structure - i.e. if the whole drive is partitioned then disk_config was AUTO when the instance was created. Bob From: Navneet

Re: [openstack-dev] [Oslo] Common testtool wrapper

On 18 June 2013 20:23, Alexander Gorodnev wrote: > Hi stackers, > > During my work on BP Common testtools wrapper I've prepared a patch, which > adds new file to oslo library. I took tests/utils.py from Oslo as basis and > then added few classes from Nova. Could somebody review my patch? The link

Re: [openstack-dev] [tripleo] new reviewers?

On 18 June 2013 17:57, Mark McLoughlin wrote: > On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote: >> So, I've been pretty happy with reviews from Chris Jones and Clint >> Byrum - would like to propose them for the tripleo review team(s). > > FWIW, it's not clear what team you mean - the tri

Re: [openstack-dev] [Quantum] Cannot run complete set of unit tests

Hi, I have the same problem with Quantum test. I don't even know what it depends on, but I get the different result every time I run unittests using "tox -epy27". My latest result is: Ran 4548 (-721) tests in 205.026s (-63.932s) PASSED (id=8, skips=201) As you can see amount of test decreased, b

[openstack-dev] [quantum] current biggest cause of gate failures is quantum race condition

The gate has been terribly broken of the last couple of weeks, and right now people running 'recheck no bug' aren't helping, as it keeps papering over *real* issues. There was a glance one, which is fixed. However the current biggest issue is probably this one - https://bugs.launchpad.net/nova

Re: [openstack-dev] Compute node stats sent to the scheduler

Hi, I am new in this area. I got an idea but didn't know whether that works. Fanout_cast is expensive and DB could be a burden. Can we maintain the stat data at nodes, and when and only when a scheduler needs to do any scheduling, the scheduler proactively to ask nodes their stats? The assumptio

Re: [openstack-dev] unittests on devstack hosts

On Tue, Jun 18 2013, Monty Taylor wrote: […] > I argue yes. I see absolutely no reason why it shouldn't work - all of > the depends should be installed - and openstack itself is installed - > why wouldn't running the unittests using the repos that are on the host > work? > > Thoughts? Agreement?

Re: [openstack-dev] The future of run_tests.sh

FWIW, I think we never really had a run_tests.sh in Ceilometer like other projects might have, and we don't have one anymore for weeks, and that never looked like a problem. We just rely on tox and on a good working listing in requirements.txt and test-requirements.txt, so you can build a venv you

[openstack-dev] Configuring Quantum REST Proxy Plugin

Hi. We're trying to configure Quantum REST Proxy Plugin to use an external Network service developed by ourselves in the context of OpenNaaS Project [1]. We have developed a REST server to listen Proxy requests. We want to modify Plugin configuration as described in OpenStack official documentatio

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

On 06/18/13 at 09:31am, Bob Ball wrote: I'm not sure I understand why the user might want to access the disk_config value from within the guest? I have this same feeling. It really has no bearing on the guest once it's running. It's has an effect on API calls and is readily available in th

Re: [openstack-dev] [networking][ml2] ML2 Mechanism Driver API proposal

On Jun 18, 2013, at 2:41 AM, Luke Gorrie wrote: > > > 12 jun 2013 kl. 09:25 skrev Andre Pech: > >> As promised at the ml2 kickoff meeting last week, attached is our basic >> proposal for the ml2 mechanism driver API. > > Great, that is fast work! > >> After getting more familiar with the ml2

Re: [openstack-dev] The future of run_tests.sh

On 13-06-18 04:59 AM, Thierry Carrez wrote: Personally I would introduce a TESTING file that would describe all available methods for running tests, and rename/move run_tests.sh to something less discoverable... so that people looking for ways to run tests would find TESTING first. Then if deve

Re: [openstack-dev] [networking][ml2] ML2 Mechanism Driver API proposal

Thanks Luke, Nothing against subnets :) happy to add those. Andre On Jun 18, 2013 6:36 AM, "Kyle Mestery (kmestery)" wrote: > On Jun 18, 2013, at 2:41 AM, Luke Gorrie wrote: > > > > > > 12 jun 2013 kl. 09:25 skrev Andre Pech: > > > >> As promised at the ml2 kickoff meeting last week, attached

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

Bob, They could do extra deduction/guessing work to infer that, but it's a valid piece of metadata from the base image, so I'm concerned why there's so much discussion about exposing it? Seems like a provider could have a reason for exposing any number of metadata bits in the Store for their im

Re: [openstack-dev] Compute node stats sent to the scheduler

Well, (not in any kind of priority order), the issues/ideas I've heard are: 1) Don't send data to scheduler, have the scheduler poll each compute node on each schedule request. I'm pretty sure that, in a large cloud with 100s if not 1000s of compute nodes, this would add too much latency to th

Re: [openstack-dev] unittests on devstack hosts

On 2013-06-17 18:06, Monty Taylor wrote: - Should unittests work outside of a venv on a devstack host. I argue yes. I see absolutely no reason why it shouldn't work - all of the depends should be installed - and openstack itself is installed - why wouldn't running the unittests using the repos t

Re: [openstack-dev] The future of run_tests.sh

On 13-06-18 09:34 AM, Anita Kuno wrote: On 13-06-18 04:59 AM, Thierry Carrez wrote: Personally I would introduce a TESTING file that would describe all available methods for running tests, and rename/move run_tests.sh to something less discoverable... so that people looking for ways to run tes

Re: [openstack-dev] The future of run_tests.sh

On 06/18/2013 04:59 AM, Thierry Carrez wrote: > The issue here is not really the burden of maintaining an alternate > testing method in the tree... it's that by default newcomers use the > alternate method rather than the one used by our CI infrastructure, > which should be their default choice. >

[openstack-dev] Hyper-V meeting canceled for today

Hi Everyone, Due to multiple individuals travelling, I will be cancelling the meeting today. We will resume next week at the usual time. P ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/lis

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

I don't have any objections to this being exposed - but the question was should we expose it, and I don't see any benefit to the user for this particular key. Of course, as you say, a provider may want to expose many specific metadata keys. Perhaps we should look at how to do this generically

Re: [openstack-dev] The future of run_tests.sh

On 13-06-18 11:14 AM, John Dennis wrote: On 06/18/2013 04:59 AM, Thierry Carrez wrote: The issue here is not really the burden of maintaining an alternate testing method in the tree... it's that by default newcomers use the alternate method rather than the one used by our CI infrastructure, whic

Re: [openstack-dev] The future of run_tests.sh

On 13-06-18 11:14 AM, Anita Kuno wrote: On 13-06-18 09:34 AM, Anita Kuno wrote: On 13-06-18 04:59 AM, Thierry Carrez wrote: Personally I would introduce a TESTING file that would describe all available methods for running tests, Actually I should point out that in my approach, I went with the m

Re: [openstack-dev] [tripleo] new reviewers?

Excerpts from Robert Collins's message of 2013-06-18 03:06:40 -0700: > On 18 June 2013 17:57, Mark McLoughlin wrote: > > On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote: > >> So, I've been pretty happy with reviews from Chris Jones and Clint > >> Byrum - would like to propose them for the

Re: [openstack-dev] [Quantum] Cannot run complete set of unit tests

On Tue, Jun 18, 2013 at 4:26 AM, Alexander Gorodnev wrote: > Hi, > > I have the same problem with Quantum test. I don't even know what it depends > on, but I get the different result every time I run unittests using "tox > -epy27". > My latest result is: > > Ran 4548 (-721) tests in 205.026s (-63.

Re: [openstack-dev] The future of run_tests.sh

Excerpts from Thierry Carrez's message of 2013-06-18 01:59:57 -0700: > Joe Gordon wrote: > > Reasons to keep run_tests.sh: > > > > * there is no possibility to run tests with testtools instead of testr. > > This feature allows us to use the debugger. > > * in some projects tox doesn't use a testr

[openstack-dev] Problem with dhcp-agent

Hi, I'm trying to configure an Openstack installation with only 2 hosts: Controller-Network node and Compute node. My problems came when I tried to configure the quantum-dhcp-agent. In my dhcp.agent.log I have the following error: RROR [quantum.agent.dhcp_agent] Failed reporting state! Traceback

Re: [openstack-dev] [Quantum] Cannot run complete set of unit tests

On 19 June 2013 03:56, Clark Boylan wrote: > I finally got around to looking into this today. I ran `tox -epy27` > locally a couple times and noticed that test numbers did vary (but not > as wildly as reported earlier). My next step was to source the tox > py27 virtualenv then to `testr list-test

Re: [openstack-dev] The future of run_tests.sh

Excerpts from Sascha Peilicke's message of 2013-06-18 00:48:23 -0700: > On 06/18/2013 01:01 AM, Joe Gordon wrote: > > Hi All, > > > > A patch to move the run_tests.sh script into oslo-incubator > > (https://review.openstack.org/#/c/32736/), has brought up the bigger > > question of what is the futu

Re: [openstack-dev] [tripleo] new reviewers?

+1 for Chris and Clint in both teams. (2013/06/19 0:54), Clint Byrum wrote: Excerpts from Robert Collins's message of 2013-06-18 03:06:40 -0700: On 18 June 2013 17:57, Mark McLoughlin wrote: On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote: So, I've been pretty happy with reviews from

[openstack-dev] Gerrit's Jenkins should stop running tests after first failure

Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of them are failing. I propose that it should fail and stop all of the other tests once there is a failure in a voting test. For non-voting test

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 12:49 PM, Jay Pipes wrote: On 06/18/2013 12:43 PM, Martina Kollarova wrote: Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of them are failing. I propose that it should fail and

Re: [openstack-dev] The future of run_tests.sh

On 2013-06-18 08:58:21 -0700 (-0700), Clint Byrum wrote: > Excerpts from Thierry Carrez's message of 2013-06-18 01:59:57 -0700: [...] > > "tox -epy27". > > Just to clarify, you're better off running 'tox'. [...] Though it's worth noting that tox will reuse existing virtual environments to save ti

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 12:43 PM, Martina Kollarova wrote: Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of them are failing. I propose that it should fail and stop all of the other tests once there is

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 12:43 PM, Martina Kollarova wrote: Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of them are failing. I propose that it should fail and stop all of the other tests once there is

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 2013-06-18 18:43:58 +0200 (+0200), Martina Kollarova wrote: [...] > I propose that it should fail and stop all of the other tests once > there is a failure in a voting test. For non-voting tests, it should > stop only itself, not the others. [...] We did this for a while (ran pep8 first in the

Re: [openstack-dev] [Quantum] Cannot run complete set of unit tests

Robert Collins wrote: > On 19 June 2013 03:56, Clark Boylan wrote: > > > I finally got around to looking into this today. I ran `tox -epy27` > > locally a couple times and noticed that test numbers did vary (but not > > as wildly as reported earlier). My next step was to source the tox > > py2

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On Tue, Jun 18, 2013 at 9:49 AM, Sean Dague wrote: > On 06/18/2013 12:43 PM, Martina Kollarova wrote: >> >> Jenkins keeps running all the tests, even if the basic pep8 test fails, >> and runs all of the (very slow) Tempest Quantum tests, even though >> almost all of them are failing. >> >> I propo

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 01:17 PM, Jeremy Stanley wrote: > On 2013-06-18 18:43:58 +0200 (+0200), Martina Kollarova wrote: > [...] >> I propose that it should fail and stop all of the other tests once >> there is a failure in a voting test. For non-voting tests, it should >> stop only itself, not the others.

Re: [openstack-dev] [tripleo] new reviewers?

On Jun 18, 2013 3:09 AM, "Robert Collins" wrote: > > On 18 June 2013 17:57, Mark McLoughlin wrote: > > On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote: > >> So, I've been pretty happy with reviews from Chris Jones and Clint > >> Byrum - would like to propose them for the tripleo review te

Re: [openstack-dev] [Quantum] Cannot run complete set of unit tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2013 01:19 PM, Roman Bogorodskiy wrote: > Robert Collins wrote: > >> On 19 June 2013 03:56, Clark Boylan >> wrote: >> >>> I finally got around to looking into this today. I ran `tox >>> -epy27` locally a couple times and noticed that test

Re: [openstack-dev] [tripleo] new reviewers?

On 06/18/2013 06:06 AM, Robert Collins wrote: > On 18 June 2013 17:57, Mark McLoughlin wrote: >> On Tue, 2013-06-18 at 13:17 +1200, Robert Collins wrote: >>> So, I've been pretty happy with reviews from Chris Jones and Clint >>> Byrum - would like to propose them for the tripleo review team(s).

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

Bob, If the user is cognizant of the extension, they may want to do post-build activities based on the value. I think that's the use for this particular case. As for exposing them in a more general fashion, I agree with both of your points: there can be use to expose them, and also reasons to k

Re: [openstack-dev] Expired tokens in Keystone

The important point I want to make is availability of service, if there are too many client requests to keystone, it ends up creating too many tokens. Under such circumstances, when user runs keystone command like user role add which makes keystone to revoke tokens for given user id and tenant id

[openstack-dev] openvswitch induced kernel panic

Greetings, I'm running grizzly on ubuntu 12.04 with quantum and GRE. After running for about 24 hours, my system panics. Attached is a screenshot of message. What's the process by which I can create a bug report, add needed log files, etc...? Thanks JR <>__

Re: [openstack-dev] The future of run_tests.sh

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2013 08:44 AM, Julien Danjou wrote: > FWIW, I think we never really had a run_tests.sh in Ceilometer > like other projects might have, and we don't have one anymore for > weeks, and that never looked like a problem. > > We just rely on tox

Re: [openstack-dev] Discussion around blueprint https://blueprints.launchpad.net/nova/+spec/add-disk-config-to-xenstore

That's fair enough. There might be a further use case where the user wants to understand how this flag will impact them on a resize? Not sure if we check it on resize, but it might make sense to check it in future. Thinking about it a little more, I'm not sure how the general case would work.

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 12:43 PM, Martina Kollarova wrote: Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of them are failing. I propose that it should fail and stop all of the other tests once there is

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

On 06/18/2013 03:14 PM, David Ripton wrote: > On 06/18/2013 12:43 PM, Martina Kollarova wrote: >> Jenkins keeps running all the tests, even if the basic pep8 test fails, >> and runs all of the (very slow) Tempest Quantum tests, even though >> almost all of them are failing. >> >> I propose that i

Re: [openstack-dev] unittests on devstack hosts

On 06/18/2013 10:35 AM, Ben Nemec wrote: > On 2013-06-17 18:06, Monty Taylor wrote: >> - Should unittests work outside of a venv on a devstack host. >> >> I argue yes. I see absolutely no reason why it shouldn't work - all of >> the depends should be installed - and openstack itself is installed

[openstack-dev] [Heat] Meeting agenda for Wed June 19th at 2000 UTC

The Heat team holds a weekly meeting in #openstack-meeting, see https://wiki.openstack.org/wiki/Meetings/HeatAgenda for more details The next meeting is on Wed June 19th at 2000 UTC Current topics for discussion: - Review last week's actions - h2 blueprint status - Open discussion If anyone

Re: [openstack-dev] [Infra] Meeting Tuesday June 18th at 19:00 UTC

On Mon, Jun 17, 2013 at 11:18 AM, Elizabeth Krumbach Joseph wrote: > The OpenStack Infrastructure (Infra) team is hosting our weekly > meeting tomorrow, Tuesday June 18th at 19:00 UTC in #openstack-meeting Meeting minutes+logs: Minutes: http://eavesdrop.openstack.org/meetings/infra/2013/infra.2

Re: [openstack-dev] unittests on devstack hosts

+1 on both A and B, I do this currently by installing test-requires via my setup script. IMO it's quite nice to do feature dev, function and unit testing all in one shot. On Tue, Jun 18, 2013 at 1:49 PM, Monty Taylor wrote: > > > On 06/18/2013 10:35 AM, Ben Nemec wrote: > > On 2013-06-17 18:06

Re: [openstack-dev] unittests on devstack hosts

best, Joe sent on the go On Jun 18, 2013 1:06 PM, "John Griffith" wrote: > > +1 on both A and B, I do this currently by installing test-requires via my setup script. IMO it's quite nice to do feature dev, function and unit testing all in one shot. +1 on both as well, we do call it devstack not

Re: [openstack-dev] New hypervisor to manage LXC containers on Nova with Docker

On Thu, Jun 06, 2013 at 10:33:12AM -0700, Sam Alba wrote: > Hi all, > > I work for dotCloud and I wanted to share our recent work on Nova[1]. > We've been using LXC containers on our PaaS product for more than 2 > years now and we recently released the Docker project[2] that you may > have heard a

Re: [openstack-dev] Add IDE specific directories to .gitignore

best, Joe sent on the go On Jun 18, 2013 2:29 AM, "Flavio Percoco" wrote: > > On 18/06/13 12:14 +0300, Roman Prykhodchenko wrote: >> >> Chmouel, >> >> Yes, it's possible to set up excluded directories in several ways. My question was why not make those directories excluded by default? >> > > I'd

Re: [openstack-dev] New hypervisor to manage LXC containers on Nova with Docker

On 06/18/2013 05:24 PM, Daniel P. Berrange wrote: > On Thu, Jun 06, 2013 at 10:33:12AM -0700, Sam Alba wrote: >> Hi all, >> >> I work for dotCloud and I wanted to share our recent work on Nova[1]. >> We've been using LXC containers on our PaaS product for more than 2 >> years now and we recently

[openstack-dev] [Heat] Does it make sense to have a resource-create API?

tl;dr POST /$tenant/stacks/$stack/resources/ ? == background == While thinking about the Autoscaling API, Thomas Hervé and I had the following consideration: - autoscaling is implemented as a set of Heat Resources - there are already general APIs for looking at resources generically: - resour

[openstack-dev] Quantum in Full Gate Issues (was Re: Gerrit's Jenkins should stop running tests after first failure)

On 06/18/2013 03:32 PM, Monty Taylor wrote: On 06/18/2013 03:14 PM, David Ripton wrote: On 06/18/2013 12:43 PM, Martina Kollarova wrote: Jenkins keeps running all the tests, even if the basic pep8 test fails, and runs all of the (very slow) Tempest Quantum tests, even though almost all of the

[openstack-dev] [Horizon] Hacking Standards for Javascript

Do we have any standards for Javascript? ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

Yes. I think having a POST method in the API makes perfect sense. Assuming we reach agreement on that, the next question that comes up is: How to do you modify resources that have been created with a POST? You mention HTTP PUT as an answer to that. Unfortunately PUT is only really useful for do

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

On 18/06/13 23:32 +, Adrian Otto wrote: Yes. I think having a POST method in the API makes perfect sense. Assuming we reach agreement on that, the next question that comes up is: Err, I am not convinced. Before that, I think it's worth highlighting the different proposals/requirements he

[openstack-dev] FW: [Keystone][Folsom] Token re-use

The issue with having un-managed number of tokens for same credential is that it can be easily exploited. Getting a token is one of initial step (gateway) to get access to services. A rogue client can keep creating unlimited number of tokens and possibly create denial of service attack on services.

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

On 06/18/2013 09:13 PM, Kant, Arun wrote: The issue with having un-managed number of tokens for same credential is that it can be easily exploited. Getting a token is one of initial step (gateway) to get access to services. A rogue client can keep creating unlimited number of tokens and possi

Re: [openstack-dev] Gerrit's Jenkins should stop running tests after first failure

Good idea. I have the same feeling. +1 Best Regards. -- Shane Martina Kollarova wrote on 2013-06-19: > Jenkins keeps running all the tests, even if the basic pep8 test fails, > and runs all of the (very slow) Tempest Quantum tests, even though > almost all of them are failing. > > I propose tha

[openstack-dev] [tripleo] structuring configuration setup

So in a running OpenStack there are several categories of config. - per user - e.g. ssh key registration with nova: we repeat this sort of config everytime we add a user. - per node - e.g. nova.conf or ovs-vsctl add-br br-ex : settings that apply individually to machines - application state - e

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

Hi Adrian, thanks for the response. I'll just respond to one thing right now (since it's way after hours for me ;) On Tue, Jun 18, 2013 at 6:32 PM, Adrian Otto wrote: > On Jun 18, 2013, at 3:44 PM, Christopher Armstrong > > wrote: > >> tl;dr POST /$tenant/stacks/$stack/resources/ ? > > Yes. [

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

On Jun 18, 2013, at 8:18 PM, Christopher Armstrong wrote: > Hi Adrian, thanks for the response. I'll just respond to one thing > right now (since it's way after hours for me ;) > > On Tue, Jun 18, 2013 at 6:32 PM, Adrian Otto > wrote: >> On Jun 18, 2013, at 3:44 PM, Christopher Armstrong >

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

Angus, I'm glad you are asking good questions. I have additional input for you to consider below. On Jun 18, 2013, at 6:09 PM, Angus Salkeld wrote: > On 18/06/13 23:32 +, Adrian Otto wrote: >> Yes. I think having a POST method in the API makes perfect sense. Assuming >> we reach agreement

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

On Tue, Jun 18, 2013 at 11:01 PM, Adrian Otto wrote: > On Jun 18, 2013, at 6:09 PM, Angus Salkeld wrote: > > To me one of the most powerful and apealing things of Heat is the > > ability to reproducibly re-create a stack from a template. This > > new public API is going to make this difficult. >

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

I agree we need a way to overcome these rogue clients but by rate limiting genuine requests will get effected. Then one would need retries and some times critical operations gets failed. It beats the whole logic of being available. About the keyrings, How do we tackle if a service is using JSON A

Re: [openstack-dev] [heat] as-update-policy implementation questions

Is the expectation here that the update policy for the auto-scaling group is enforced only when either the launch configuration or subnet group membership is changed in the auto-scaling group? The LaunchConfigurationName is not currently listed as an update_allowed_properties in the AutoScaling

Re: [openstack-dev] [networking][ml2] ML2 Mechanism Driver API proposal

18 jun 2013 kl. 15:28 skrev Kyle Mestery (kmestery): >> Kyle, do you guys have the same issue with the OpenDaylight plugin? >> > We will want subnets for the ODL ML2 driver as well, so I think we'll want > them here as well. Luke, maybe add these comments into the MechanismDriver > review here

Re: [openstack-dev] [networking][ml2] ML2 Mechanism Driver API proposal

18 jun 2013 kl. 15:28 skrev Kyle Mestery (kmestery): >> Kyle, do you guys have the same issue with the OpenDaylight plugin? >> > We will want subnets for the ODL ML2 driver as well, so I think we'll want > them here as well. Luke, maybe add these comments into the MechanismDriver > review here

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

1) Token Caching is not always going to help. It depends on the application.E.g A user writes a cron job to check the health of swift by listing a predefined container every 1 minute.This will obviously create a token every minute. 2) Also I like to understand how rate

Re: [openstack-dev] [Heat] Does it make sense to have a resource-create API?

Angus Salkeld wrote on 19.06.2013 03:09:34: > From: Angus Salkeld > To: [email protected], > Date: 19.06.2013 03:19 > Subject: Re: [openstack-dev] [Heat] Does it make sense to have a > resource-create API? > > On 18/06/13 23:32 +, Adrian Otto wrote: > >Yes. I think having a P