Hi,
Currently there are 2 VMware drivers:
* VMwareVCDriver – this lets nova compute communicate with a vCenter server
(which manages the ESX hosts)
* VMwareESXDriver – this lets nova compute manage the ESX host
Thanks
Gary
From: Ray Sun xiaoq...@gmail.commailto:xiaoq...@gmail.com
Ray,
Actually, you can. There is an ESX driver in OpenStack as well as vCenter.
However, it does not have benefits of vSphere/vCenter, like DRS.
It would probably help if you described your use case and specify why you
want to identify every ESXi host.
--
Best regards,
Oleg Gelbukh
Mirantis
Hi All,
I have a openstack Havana setup running on Ubuntu 12.04 via Devstack.
I want to test the icehouse-1 milestone release (cinder and nova) on the
setup. I looked for the instructions in the docs but could not find.
Could anyone help me with the instructions or steps i should follow to
Hi, stackers,
I know only little about Heat, and I can't wholly follow recent
discussions around multi-region support in this mailing list.
Please help me understand the roadmap or plan about hybrid cloud
and bursting in particular.
I'd like to ask the following questions to the developers
Le 17/12/2013 14:59, Thierry Carrez a écrit :
Mark McLoughlin wrote:
On Tue, 2013-12-17 at 13:44 +0100, Thierry Carrez wrote:
Mark McLoughlin wrote:
How about if we had an emerging projects page where the TC feedback on
each project would be listed?
That would give visibility to our
On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote:
On 2013/13/12 23:11, Jordan OMara wrote:
On 13/12/13 16:20 +1300, Robert Collins wrote:
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova boot gets you an instance, nova delete gets
rid of an instance,
Hi Ryan,
I've just replied with some comments on the changeset itself
Regards,
Chris
On Wed, Dec 18, 2013 at 7:38 AM, Ryan Petrello
ryan.petre...@dreamhost.comwrote:
So any additional feedback on this patch? I’d love to start working on
porting some of the other extensions to pecan, but
Bhandaru, Malini K wrote:
Barbican, key manager is essential to openstack, paves the way to greater
security.
Instead of rejecting the project because of its current existence owed so
heavily to Rackspace and to John Wood, why not we adopt it, code review,
contribute code etc. We can have
At the design summit we had a discussion[1] about redesigning Neutron
resources to avoid the need for hidden dependencies (that is to say,
dependencies which cannot be inferred from the template).
Since then we've got close to fixing one of those issues[2] (thanks
Bartosz!), but the patch
On 13/12/13 09:41 -0500, Jay Dobies wrote:
* ability to 'preview' changes going to the scheduler
What does this give you? How detailed a preview do you need? What
information is critical there? Have you seen the proposed designs for
a heat template preview feature - would that be sufficient?
Sylvain Bauza wrote:
Well, correct me if I'm wrong, but Stackforge is already the place for
promising projects ? If so, why creating a wikipage for listing them ?
Not really. Any project can be in stackforge. It doesn't have to be
promising or to want to ever be part of the integrated openstack
I would copy that question. Looks like integration plan didn't work out,
and healthnmon development either stalled or gone shadow..
Anyone have information on that?
--
Best regards,
Oleg Gelbukh
Mirnatis Inc.
On Tue, Dec 17, 2013 at 11:29 PM, David S Taylor da...@bluesunrise.comwrote:
Could
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a number of different developers involved
before they apply for incubation, mostly to raise the bus factor. But we
also currently require some level of
Le 18/12/2013 11:25, Thierry Carrez a écrit :
Sylvain Bauza wrote:
Well, correct me if I'm wrong, but Stackforge is already the place for
promising projects ? If so, why creating a wikipage for listing them ?
Not really. Any project can be in stackforge. It doesn't have to be
promising or to
I attempted this in keystone as part of a very simple extension [1]. I
understand that it is a much simpler case but nesting the Pecan within the
existing routing infrastructure, rather than have a single Pecan app was fairly
simple (though there are some limiting situations).
Any reason you
Le 18/12/2013 11:40, Thierry Carrez a écrit :
I guess there are 3 options:
1. Require diversity for incubation, but find ways to bless or recommend
projects pre-incubation so that this diversity can actually be achieved
2. Do not require diversity for incubation, but require it for
graduation,
On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a number of different developers involved
before they apply for incubation, mostly to
Hey Shixiong,
This is intended as a replacement for [1], correct? Do you have code for
this already, or should we work with Sean's patch?
There's a discussion document at [2], which is intended to be more specific
behind the reasoning for the choices we make, and the interface offered to
the
I think we're all happy that if a project *does* have a broad support base
we're good; this is only the case for projects in one of two situations:
- support is spread so thinly that each company involved in the area has
elected to support a different solution
- the project is just not that
Hi All,
After yesterday's weekly meeting it seems that majority of us is leaning
towards this approach (codebase merge). However there are few concerns
regarding speed of development and resources especially for reviews.
With this e-mail, I'd like to kick off discussion about how we might
On 12/18/2013 06:28 AM, Oleg Gelbukh wrote:
I would copy that question. Looks like integration plan didn't work out,
and healthnmon development either stalled or gone shadow..
Anyone have information on that?
I think that's the case. There was no mention of Healthnmon at the last
summit.
Oleg,
Thanks for your response.
The minimal requirement of our customer is to know the status of each ESXI
server on the OpenStack, also they want to know where is the vm running
now. In short, they want OpenStack as the single portal of their cloud and
can manage all their resource, but they
Jaromir Coufal jcou...@redhat.com wrote:
Hi All,
After yesterday's weekly meeting it seems that majority of us is leaning
towards this approach (codebase merge). However there are few concerns
regarding speed of development and resources especially for reviews.
With this e-mail, I'd like to
On Wed, Dec 18, 2013 at 10:44:46AM +0100, Ladislav Smola wrote:
On 12/17/2013 04:20 PM, Tzu-Mainn Chen wrote:
On 2013/13/12 23:11, Jordan OMara wrote:
On 13/12/13 16:20 +1300, Robert Collins wrote:
However, on instance - 'instance' is a very well defined term in Nova
and thus OpenStack: Nova
-Original Message-
From: Sylvain Bauza [mailto:sylvain.ba...@bull.net]
Sent: Wednesday, December 18, 2013 5:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Diversity as a requirement for incubation
Le 18/12/2013 11:40, Thierry
Hi, Ian:
I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I
was trying to leverage and enhance those definitions so when dnsmasq is
launched, it knows which mode it should run in.
That being said, I see the value of your points and I also had lengthy
discussion
Hi
Looking at
https://github.com/openstack/neutron/tree/master/neutron/tests/unit/db I see
that the way we currently test the DB layer is via the REST API layer.
Why do we mix those 2 layers in one UT?
Those 2 layers are not related to each other and the DB UT should run directly
against the
Greetings, OpenStack DBaaS community.
I'd like to start discussion around a new feature in Trove. The feature
I would like to propose covers manipulating database log files.
Main idea. Give user an ability to retrieve database log file for any
purposes.
Goals to achieve.
On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote:
Hi, Ian:
I won’t say the intent here is to replace dnsmasq-mode-keyword BP.
Instead, I was trying to leverage and enhance those definitions so when
dnsmasq is launched, it knows which mode it should run in.
That
I replied some comments on the gerrit also. If we have patch for
demonstrate pecan style extension, that will be great.
Thanks
Alex
On 2013年12月18日 05:08, Ryan Petrello wrote:
So any additional feedback on this patch? I’d love to start working on porting
some of the other extensions to pecan,
I would vote for the approach number 2. I think there are some distinct
advantages for one company driving the development of a certain feature
sets early in the life of the project, typically, the speed of development
is faster, and it is easier to achieve focus early on.
Allowing important
Daniel P. Berrange wrote:
On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote:
I guess there are 3 options:
1. Require diversity for incubation, but find ways to bless or recommend
projects pre-incubation so that this diversity can actually be achieved
2. Do not require diversity
On Wed, Dec 18, 2013 at 3:20 AM, Ganpat Agarwal gans.develo...@gmail.comwrote:
I want to test the icehouse-1 milestone release (cinder and nova) on the
setup. I looked for the instructions in the docs but could not find.
Since you don't say I will assume you have your current setup from a
On Wed, Dec 18, 2013 at 8:14 AM, Dean Troyer dtro...@gmail.com wrote:
On Wed, Dec 18, 2013 at 3:20 AM, Ganpat Agarwal
gans.develo...@gmail.comwrote:
I want to test the icehouse-1 milestone release (cinder and nova) on the
setup. I looked for the instructions in the docs but could not find.
On Wed, Dec 18, 2013 at 6:04 AM, Sylvain Bauza sylvain.ba...@bull.netwrote:
Le 18/12/2013 11:40, Thierry Carrez a écrit :
I guess there are 3 options:
1. Require diversity for incubation, but find ways to bless or recommend
projects pre-incubation so that this diversity can actually be
On Wed, Dec 18, 2013 at 6:18 AM, Daniel P. Berrange berra...@redhat.comwrote:
On Wed, Dec 18, 2013 at 11:40:21AM +0100, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a
Greetings,
The weekly Nova meeting [1] has been held on Thursdays at 2100 UTC.
I've been getting some requests to offer an alternative meeting time.
I'd like to try out alternating the meeting time between two different
times to allow more people in our global development team to attend
meetings
On Wed, Dec 18, 2013 at 8:06 AM, Jarret Raim jarret.r...@rackspace.comwrote:
-Original Message-
From: Sylvain Bauza [mailto:sylvain.ba...@bull.net]
Sent: Wednesday, December 18, 2013 5:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re:
+1 here too - I'd love to be able to attend alternate weeks.
Bob
-Original Message-
From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: 18 December 2013 14:36
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] Future meeting times
Sounds like what I’m hearing is “Let’s see something that uses this (that
works)”? I’ll work on that :)
---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com
On Dec 18, 2013, at 9:45 AM, Ryan Petrello ryan.petre...@dreamhost.com wrote:
Jamie:
Your approach makes sense,
On Wed, Dec 18, 2013 at 8:23 AM, Anne Gentle
annegen...@justwriteclick.comwrote:
Also, Dean correct me if I'm wrong, but I don't believe devstack does a
precise milestone release. To guestimate it, you could figure out what
This is correct, only stable/* releases.
devstack looked like on
+1. The current meeting time works well for me but I would attend both.
On 12/18/13 at 09:29am, Russell Bryant wrote:
Greetings,
The weekly Nova meeting [1] has been held on Thursdays at 2100 UTC.
I've been getting some requests to offer an alternative meeting time.
I'd like to try out
On 12/13/2013 03:50 AM, Thierry Carrez wrote:
Russell Bryant wrote:
$ git shortlog -s -e | sort -n -r
172 John Wood john.w...@rackspace.com
150 jfwood john.w...@rackspace.com
65 Douglas Mendizabal douglas.mendiza...@rackspace.com
39 Jarret Raim jarret.r...@rackspace.com
It is a difficult thing to measure, and I don't think the intent is to set
a hard %
for contributions. I think the numbers for Barbican were just illustrating
the
fact that the concrete contributions are very coming very heavily from one
source. That's only one data point, though, and as
-Original Message-
From: Steven Dake [mailto:sd...@redhat.com]
In this particular case, I believe Barbican is not ready for incubation
because
of their dependence on celery, but ultimately I don't make the decision :)
We've landed the PR that removes celery and replaces it with
Hello,
I get the following error when I run stack.sh on Devstack
Traceback (most recent call last):
File /usr/local/bin/ceilometer-dbsync, line 6, in module
from ceilometer.storage import dbsync
File /opt/stack/ceilometer/ceilometer/storage/__init__.py, line 23, in
module
from
I replied on the review itself but here's what I know.
The v3 documentation is still underway, there's a long thread on the
openstack-docs list from October that should help explain the question's
base. Sounds like this patch does indeed affect the way docs are generated
potentially.
I am newbie here and I am from +5:30 GMT. Can any one direct me how to
attend this meeting?
On Wed, Dec 18, 2013 at 12:46 PM, Krishna Raman kra...@gmail.com wrote:
Hi,
The next Git-workflow meeting is tomorrow at 8 AM PST. (
If you are behind corporate proxy, make sure the proxy is set.
On Wed, Dec 18, 2013 at 8:56 PM, Sayali Lunkad sayali.92...@gmail.comwrote:
Hello,
I get the following error when I run stack.sh on Devstack
Traceback (most recent call last):
File /usr/local/bin/ceilometer-dbsync, line 6,
Unless you need ceilometer, you can try in your localrc of eliminating
ceilometer from the ENABLED_SERVICES. I know thats not the ulimate fix, but
it will get you up and running with devstack.
On Wed, Dec 18, 2013 at 8:26 AM, Sayali Lunkad sayali.92...@gmail.comwrote:
Hello,
I get the
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 the idea of a
unified agent, but believe that forcing Trove to adopt this
04:00 or 05:00 UTC would basically preclude European participation for
most people... that's 4 am for Dosaboy and myself for example.
Alternating meetings on different weeks would probably work, though we
would need to encourage people to get stuff on the agenda in advance
rather than an hour
On 12/18/2013 03:40 AM, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a number of different developers involved
before they apply for incubation, mostly to raise the bus factor. But
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the 'instance_type' key with 'flavor' per the associated blueprint.
[1] https://review.openstack.org/#/c/62430/
--
Thanks,
Matt Riedemann
Use IRC to connect to irc.freenode.nethttp://irc.freenode.net
Join the #solum channel
The meeting starts in roughly 15 minutes from now.
On Dec 18, 2013, at 7:30 AM, iKhan
ik.ibadk...@gmail.commailto:ik.ibadk...@gmail.com
wrote:
I am newbie here and I am from +5:30 GMT. Can any one direct me
Hi Ibad,
The Solum Git workflow meeting will be on #solum channel on IRC (freenode).
—Kr
On Dec 18, 2013, at 7:30 AM, iKhan ik.ibadk...@gmail.com wrote:
I am newbie here and I am from +5:30 GMT. Can any one direct me how to attend
this meeting?
On Wed, Dec 18, 2013 at 12:46 PM, Krishna
Hey,
I do need ceilometer so making changes to localrc won't help me here.
And no corporate proxy!
What could possibly be the issue because my Devstack had been working fine
till now.
Thanks,
Sayali
On Dec 18, 2013 9:14 PM, iKhan ik.ibadk...@gmail.com wrote:
If you are behind corporate proxy,
On Wed, Dec 18, 2013 at 8:35 AM, Duncan Thomas duncan.tho...@gmail.com wrote:
04:00 or 05:00 UTC would basically preclude European participation for
most people... that's 4 am for Dosaboy and myself for example.
Alternating meetings on different weeks would probably work, though we
would need
Also forgot to mention I can access the dashboard but I am unable to
retrieve any information about the volumes.
On Dec 18, 2013 8:56 PM, Sayali Lunkad sayali.92...@gmail.com wrote:
Hello,
I get the following error when I run stack.sh on Devstack
Traceback (most recent call last):
File
On 12/18/2013 10:37 AM, Steven Dake wrote:
On 12/18/2013 03:40 AM, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a number of different developers involved
before they apply for
Thanks Liz for setting up the poll.
I'm not sure we're locked to Tuesday as the meeting day either.
On Tuesdays, 20:00 UTC (TC meeting) and 21:00 UTC (Project) are meetings I
don't want to schedule over.
Those times are more attractive on other days.
-David
-Original Message-
On 12/18/2013 10:23 AM, Jarret Raim wrote:
-Original Message-
From: Steven Dake [mailto:sd...@redhat.com]
In this particular case, I believe Barbican is not ready for incubation
because
of their dependence on celery, but ultimately I don't make the decision :)
We've landed the PR
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 the idea of a unified agent,
On 12/18/2013 03:29 PM, Russell Bryant wrote:
Greetings,
The weekly Nova meeting [1] has been held on Thursdays at 2100 UTC.
I've been getting some requests to offer an alternative meeting time.
I'd like to try out alternating the meeting time between two different
times to allow more
On 18/12/13 11:40 +0100, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that projects have a number of different developers involved
before they apply for incubation, mostly to raise the bus factor.
On 12/18/2013 9:42 AM, Matt Riedemann wrote:
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the 'instance_type' key with 'flavor' per the associated blueprint.
[1]
Hi Adam,
I would like to request you to revisit the below link and provide your opinion,
so that we can move forward and try to find a common ground where everyone.
https://review.openstack.org/#/c/61897
Below is my justification for service_id in role model:
In a public cloud deployment
I've seen this come up a few times in reviews and was thinking we should
put something in the general review checklist wiki for it [1].
Basically I have three things I'd like to have in the list for DB
migrations:
1. Unique constraints should be named. Different DB engines and
SQLAlchemy
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 cl...@fewbar.com
Excerpts from Dmitry Mescheryakov's
On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague s...@dague.net wrote:
On 12/18/2013 10:37 AM, Steven Dake wrote:
On 12/18/2013 03:40 AM, Thierry Carrez wrote:
Hi everyone,
The TC meeting yesterday uncovered an interesting question which, so
far, divided TC members.
We require that
On Wed, Dec 18, 2013 at 10:20 AM, Jarret Raim jarret.r...@rackspace.comwrote:
It is a difficult thing to measure, and I don't think the intent is to
set
a hard %
for contributions. I think the numbers for Barbican were just
illustrating
the
fact that the concrete contributions are very
Excerpts from Tim Simpson's message of 2013-12-18 07:34:14 -0800:
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 the idea
Excerpts from Steven Dake's message of 2013-12-18 08:05:09 -0800:
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
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 after it is implemented on
oslo.messaging
I presume the later, but could you clarify?
On 12/18/2013 06:17 PM, Matt Riedemann wrote:
On 12/18/2013 9:42 AM, Matt Riedemann wrote:
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the 'instance_type' key with 'flavor' per the
On 18/12/13 12:35 -0500, Doug Hellmann wrote:
On Wed, Dec 18, 2013 at 10:58 AM, Sean Dague s...@dague.net wrote:
On 12/18/2013 10:37 AM, Steven Dake wrote:
But I can tell you one thing for certain, an actual incubation
commitment from the OpenStack Technical Committee has a huge
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.
*
For me, 4/5 is currently 6/7AM. An hour later when daylight savings
messes things up. Exactly wake up/get ready/kid to school/me to work
time.
I'd rather leave it as is (6/7PM depending on daylight savings).
If you alternate, I may have to miss some.
Thanks,
Avishay
From: John Griffith
2013/12/18 Steven Dake sd...@redhat.com
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
Excerpts from =?ks_c_5601-1987?B?wMzB2L/4?='s message of 2013-12-18 01:26:22
-0800:
Hi, stackers,
I know only little about Heat, and I can't wholly follow recent
discussions around multi-region support in this mailing list.
Please help me understand the roadmap or plan about hybrid cloud
Hi Gao
What is the reason why you see it would be important to have these two
additional metrics power and temperature for Nova to base scheduling on?
Alan
From: Gao, Fengqian [mailto:fengqian@intel.com]
Sent: December-18-13 1:00 AM
To: openstack-dev@lists.openstack.org
Subject:
Someone's gotta make/maintain the trove/savanna images though. They usually are
built from packages. If there is a unified agent, then it only has to be
packaged once. If there is one per special type of agent, its one package per
special type of agent. I don't think there is a free lunch here,
On 12/18/2013 07:01 AM, Dolph Mathews wrote:
Options 2 and 3 sound identical to me, when realistically applied.
Option 3 just makes the common sense aspect mandatory.
Indeed, Option 3 gets my vote. One aspect I'd like to mention regarding
diversity of contributors in any open source project is
Thanks all for the information.
I have now v3 policies in place, the issue is that as a domain admin I
could not create a project in the domain. I get 403 unauthorized status.
I see that when as a 'domain admin' request a token, the response did not
have any roles. In the token request, I
On 12/18/2013 12:44 PM, Nikola Đipanov wrote:
On 12/18/2013 06:17 PM, Matt Riedemann wrote:
On 12/18/2013 9:42 AM, Matt Riedemann wrote:
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace the
On Tue, Dec 17, 2013 at 10:00 PM, Gao, Fengqian fengqian@intel.comwrote:
Hi, all,
I am planning to extend bp
https://blueprints.launchpad.net/nova/+spec/utilization-aware-schedulingwith
power and temperature. In other words, power and temperature can be
collected and used for
On 18/12/13 04:26, 이준원 wrote:
Hi, stackers,
I know only little about Heat, and I can't wholly follow recent
discussions around multi-region support in this mailing list.
Please help me understand the roadmap or plan about hybrid cloud
and bursting in particular.
I'd like to ask the following
On 12/18/2013 01:44 PM, Nikola Đipanov wrote:
On 12/18/2013 06:17 PM, Matt Riedemann wrote:
On 12/18/2013 9:42 AM, Matt Riedemann wrote:
The question came up in this patch [1], how do we deprecate and remove
keys in the notification payload? In this case I need to deprecate and
replace
On 12/18/2013 03:00 PM, Russell Bryant wrote:
We really need proper versioning for notifications. We've had a
blueprint open for about a year, but AFAICT, nobody is actively working
on it.
https://blueprints.launchpad.net/nova/+spec/versioned-notifications
IBM is behind this effort
Matt -
Could a test be added that goes through the models and checks these things?
Other projects could use this too.
Here's an example of a test that checks if the tables are all InnoDB:
Please provide proof of that assumption or at least a general hypothesis
that we can test.
I can't prove that the new agent will be larger as it doesn't exist yet.
Since nothing was agreed upon anyway, I don't know how you came to that
conclusion. I would suggest that any agent framework
On Dec 18, 2013 6:38 AM, Russell Bryant rbry...@redhat.com wrote:
Greetings,
The weekly Nova meeting [1] has been held on Thursdays at 2100 UTC.
I've been getting some requests to offer an alternative meeting time.
I'd like to try out alternating the meeting time between two different
times
Thanks for the summary Dmitry. I'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
Services already own their own policy enforcement, and therefore own their
own definitions of roles. A service deployment can already require roles
that are prefixed by a specific string (compute-*), and can already map
actual capabilities onto those roles ({compute-create:
role:compute-manager}).
I am fine with this, but I will never be attending the 1400 UTC
meetings, as I live in utc-8
I too will miss the 1400UTC meetings during the majority of the year.
During PDT I will be able to make them, but will be uncaffeinated.
--Dan
___
On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru ravi...@gmail.com wrote:
Thanks all for the information.
I have now v3 policies in place, the issue is that as a domain admin I
could not create a project in the domain. I get 403 unauthorized status.
I see that when as a 'domain admin'
I don't have a problem with any of these requirements, but I'd like to
explore automating the checks. Would it be possible to write a unit
test that verified this for all migrations? Then we don't need to add
it to the checklist...
Michael
On Thu, Dec 19, 2013 at 4:27 AM, Matt Riedemann
Tim, we definitely don't want to force projects to migrate to the unified
agent. I've started making the PoC with the idea that Savanna needs the
agent anyway, and we want it to be ready for Icehouse. On the other side, I
believe, it will be much easier to drive the discussion further with the
PoC
Hi Dolph,
I dont have project yet to use in the scope. The intention is to get a
token using domain admin credentials and create project using it.
Thanks,
-Ravi.
On Wed, Dec 18, 2013 at 11:39 AM, Dolph Mathews dolph.math...@gmail.comwrote:
On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru
Thanks Dolph,
It worked now. I specified domain id in the scope.
-Ravi.
On Wed, Dec 18, 2013 at 12:05 PM, Ravi Chunduru ravi...@gmail.com wrote:
Hi Dolph,
I dont have project yet to use in the scope. The intention is to get a
token using domain admin credentials and create project using
1 - 100 of 147 matches
Mail list logo
