I agree with the below from a XenServer perspective. As with vmware, XenServer
supports live snapshotting and creating multiple clones from that live snapshot.
I understand that there is a XenAPI equivalent in the works and therefore would
argue the API changes need to be accepted as a minimum.
Hi all,
I configure keystone with ldap backend followed LDAP section of
http://docs.openstack.org/developer/keystone/configuration.html,
and when I create tenant in ldap, I got the error about "enable" and
"desc" attribute type undefined in keystone.log.
Here is keystone.conf:
On 08/19/13 20:34, Joshua Harlow wrote:
> Just a related question,
>
> Oslo 'incubator' db code I think depends on eventlet. This means any code
> that uses the oslo.db code could/would(?) be dependent on eventlet.
>
> Will there be some refactoring there to not require it (useful for pro
Greetings stackers!
August 22nd is fast approaching. Here's the reviews in flight. We have 5 ready
for a core reviewer to take a look. One needing some attention from someone who
knows VMware's APIs and 8 that are in need of work/discussion. I noticed that
there was some issues with Jenkins ea
On 2013年08月17日 00:14, Vishvananda Ishaya wrote:
On Aug 15, 2013, at 5:58 PM, Melanie Witt wrote:
On Aug 15, 2013, at 1:13 PM, Joe Gordon wrote:
+1 from me as long as this wouldn't change anything for the EC2 API's security
groups support, which I assume it won't.
Correct, it's unrelated to
On Tue, Aug 20, 2013 at 5:14 AM, Jay Buffington wrote:
>
> This is really interesting. I wish they would have explicitly defined
> "lines of code." Is that "git show |wc -l"? Just the new lines which
> were added? The sum of the lines changed, removed and added? You can
> get vastly different
Just a related question,
Oslo 'incubator' db code I think depends on eventlet. This means any code that
uses the oslo.db code could/would(?) be dependent on eventlet.
Will there be some refactoring there to not require it (useful for projects
that are trying to move away from eventlet).
https:
Well, no one has stepped up to run the meeting tomorrow so let's just cancel
for this week. We'll be back at our regularly scheduled time next Tues., 8/27.
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786
-Original Message-
From: Dugger, Donald D [mailt
this is off list. Just FYI.
Thanks for putting this up. I was looking forward to going to Hong Kong, but, I
have a personal (family life event) reason I can't attend. I'll do my best to
participate otherwise. I've asked Tracy Jones (a vmware team member and ATC) to
go to Hong Kong in my place.
Hi folks,
I'd like to continue the discussion about this.
I think we have the following questions to answer:
1) What should be the workflow of provider removal for the admin?
2) Do we allow 'update' operation on provider attribute?
3) Do we allow removing provider for users?
My take on these:
1)
So, in what can only be described as "extremely embarrassing" and "wow, I
thought I knew how to use a computer": netifaces appears to work ok under
PyPy! I could have sworn I'd tested it, but apparently not. So, this is no
longer a high priority item for me to get swift on pypy (in fact, +/-
event
Hi Salvatore
Thank you for your comment.
I'm adding OpenSwan support as additional driver, so it is safe for strongswan.
Best
Nachi
2013/8/19 Salvatore Orlando :
> As I said during the meeting, I am happy to support both as long as the code
> churn is reasonably contained and the chances of stro
As I said during the meeting, I am happy to support both as long as the
code churn is reasonably contained and the chances of strongswan support
introducing bugs into openswan driver are negligible.
Openswan should be the default solution, in muy opinion.
Salvatore
On 20 August 2013 00:15, Nach
Hi folks
I would like to discuss whether supporting OpenSwan or StrongSwan or Both for
ipsec driver?
We choose StrongSwan because of the community is active and plenty of docs.
However It looks like RHEL is only supporting OpenSwan.
so we should choose
(A) Support StrongSwan
(B) Support OpenSwa
Greetings,
Some OpenStack programs have started a nice trend of getting together in
the middle of the development cycle. These meetups can serve a number
of useful purposes: community building, ramping up new contributors,
tackling hard problems by getting together in the same room, and more.
I
Mark,
But for a variety of reasons, I do not consider the general thrust of "use
oslo db code" to be approved. Instead, lets continue to consider features
from olso db on a case by case basis, and see what the right resolution is
in each case.
Absolutely agree with this point (e.g. we removed sha
The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting tomorrow, Tuesday August 20th, at 19:00 UTC in
#openstack-meeting
Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)
Everyone interested in infr
Hi Matt,
it is not an accident that savanna-extra has no tarballs at tarballs.o.o,
because this repo is used for storing some date that is only needed for some
stuff like building images for vanilla plugin, storing Swift support patch for
Hadoop and etc. So, it looks like that we should not pac
> All I'm saying is that we should be careful not to swap one set of
> problems for another.
My 2 cents: I am in agreement with Jay. I am leery of NoSQL being a
direct sub in and I fear that this effort can be adding a large workload
for little benefit.
A somewhat related post:
http://www.joelo
Will someone setup a tarballs.os.o release of savanna-extra's master
(https://github.com/stackforge/savanna-extra), and make sure it gets an
official release for 0.3?
Best,
matt
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http:
For what it's worth... this doesn't seem too bad to me...
I was planning on using this part of the vSphere API:
*
https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/vim.vm.CloneSpec.html
...to accomplish the clone part of the BP. The API contains a "spec" section
where
On Wed, Aug 14, 2013 at 7:12 PM, Robert Collins
wrote:
> Note specifically the citation of 200-400 lines as the knee of the review
> effectiveness curve: that's lower than I thought - I thought 200 was
> clearly fine - but no.
>
This is really interesting. I wish they would have explicitly defin
On 08/16/2013 04:58 PM, Doug Hellmann wrote:
> The notification messages don't translate 1:1 to database records. Even
> if the notification payload includes multiple resources, we will store
> those as multiple individual records so we can query against them. So it
> seems like sending individua
Robert Collins wrote:
> [...]
> But to answer your points:
> - an unreleased feature is an unreleased feature irrespective of what
> branch it is in. It's not something you'd pull bug fixes into a frozen
> branch for.
> - If the codebase knows it's a release branch (can we tell
> programmatically
On Mon, Aug 19, 2013 at 09:15:24AM -0500, Dolph Mathews wrote:
> On Mon, Aug 19, 2013 at 6:06 AM, Steven Hardy wrote:
>
> > On Sun, Aug 18, 2013 at 07:02:04PM +0200, Matthieu Huin wrote:
> > > Hi Steve,
> > >
> > > It might be a bit late for this, but here's a script I wrote when
> > experimentin
I think Zane's response pretty much covers it, but here's some comments
since you requested my response:
On Thu, Aug 15, 2013 at 05:50:19PM -0500, Christopher Armstrong wrote:
> *Introduction and Requirements*
>
> So there's kind of a perfect storm happening around autoscaling in Heat
> right now
Daniel P. Berrange wrote:
> In this thread about code review:
>
> http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html
>
> I mentioned that I thought there were too many blueprints created without
> sufficient supporting design information and were being used for "tickbox"
Thanks for refocusing the discussion on your original questions!
Also thanks for this additional summary. I consider the patches you have up
for review in glance to have a general direction-level green light at this
point (though I've got a question on the specifics in the ultimate review).
But f
+1 for trying things differently :)
On 8/19/13 12:14 AM, "Jay Pipes" wrote:
>On 08/18/2013 10:33 PM, Joe Gordon wrote:
>> An alternative I think would be better would be to scrap the
>>use of
>> the SQLAlchemy ORM; keep using the DB engine abstraction
>>support.
>>
>> +1, I am ho
On Fri, Aug 16, 2013 at 1:35 PM, Clint Byrum wrote:
> Excerpts from Zane Bitter's message of 2013-08-16 09:36:23 -0700:
> > On 16/08/13 00:50, Christopher Armstrong wrote:
> > > *Introduction and Requirements*
> > >
> > > So there's kind of a perfect storm happening around autoscaling in Heat
> >
Hi Salvatore,
Thanks for reviewing. You are right - there are changes planned in Neutron as
well for the Amazon VPC API support. Here is the link referring to the Neutron
blueprint.
https://blueprints.launchpad.net/neutron/+spec/juniper-plugin-with-extensions
All calls except related to Instanc
Thank you for the answer and link.
Mark
From: Shake Chen [mailto:shake.c...@gmail.com]
Sent: Friday, August 16, 2013 6:01 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] General Question about CentOS
Now in Centos 6.x ,the Python is 2.6.6, the Openstack can run it. you can
Hello,
Below, you can see the meeting minutes from today's Murano meeting.
Minutes:
http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-08-19-15.04.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-08-19-15.04.txt
Log:
http://eavesdrop.openstack.org/
In this thread about code review:
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013701.html
I mentioned that I thought there were too many blueprints created without
sufficient supporting design information and were being used for "tickbox"
process compliance only. I based this
On Fri, Aug 16, 2013 at 2:51 PM, Miller, Mark M (EB SW Cloud - R&D -
Corvallis) wrote:
> Is OpenStack supported on CentOS running Python 2.6?
>
Oh, I forgot to mention, keystone's py2.6 support seems to currently be
broken because of this bug:
https://bugs.launchpad.net/keystone/+bug/1213284/
We're doing continuous deployment on Oracle Linux 6.3, using a RHEL kernel
making it almost identical to CentOS 6.3. We're using keystone, glance,
neutron and nova. The neutron metadata service doesn't work, nor do
overlapping ips: both need network namespace support in the kernel which
wasn't in
On Mon, Aug 19, 2013 at 6:06 AM, Steven Hardy wrote:
> On Sun, Aug 18, 2013 at 07:02:04PM +0200, Matthieu Huin wrote:
> > Hi Steve,
> >
> > It might be a bit late for this, but here's a script I wrote when
> experimenting with trusts:
> https://github.com/mhuin/keystone_trust/blob/master/tests/sw
On Sun, Aug 18, 2013 at 11:17 PM, Robert Collins
wrote:
> On 19 August 2013 16:15, John Griffith
> wrote:
>
> > This was pretty well discussed back in April and May IMO.
>
> It petered out with no firm consensus AFAICT. Those of us with CD
> experience are trying to debug the concerns those of us
On 08/18/2013 04:04 PM, Jay Pipes wrote:
> On 08/17/2013 03:10 AM, Julien Danjou wrote:
>> On Fri, Aug 16 2013, Jay Pipes wrote:
>>
>>> Actually, that's the opposite of what I'm suggesting :) I'm suggesting
>>> getting rid of the resource_metadata column in the meter table and
>>> using the
>>> r
On 08/19/2013 09:40 AM, Julien Danjou wrote:
> On Mon, Aug 19 2013, Sandy Walsh wrote:
>
>> On 08/19/2013 05:08 AM, Julien Danjou wrote:
>>> On Sun, Aug 18 2013, Jay Pipes wrote:
>>>
I'm proposing that in these cases, a *new* resource would be added to the
resource table (and its ID in
On 19/08/13 16:45 +0400, Boris Pavlovic wrote:
Flavio,
So could you review please patches in Glance? =)
Yes, I'll sync with Mark and other folks to make sure all doubts are
cleared.
--
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
Open
Flavio,
So could you review please patches in Glance? =)
Best regards,
Boris Pavlovic
--
Mirantis Inc.
On Mon, Aug 19, 2013 at 4:33 PM, Flavio Percoco wrote:
> On 19/08/13 04:33 -0700, Gary Kotton wrote:
>
>> So are you agree with next points?
>> 1) In Havana focus on migrating in all proje
On Mon, Aug 19 2013, Sandy Walsh wrote:
> On 08/19/2013 05:08 AM, Julien Danjou wrote:
>> On Sun, Aug 18 2013, Jay Pipes wrote:
>>
>>> I'm proposing that in these cases, a *new* resource would be added to the
>>> resource table (and its ID inserted in meter) table with the new
>>> flavor/instance
https://review.openstack.org/#/c/41702/
Thanks!
PCM (Paul Michali)
MAIL p...@cisco.com
IRC pcm_ (irc.freenode.net)
TW @pmichali
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@li
On 19/08/13 04:33 -0700, Gary Kotton wrote:
So are you agree with next points?
1) In Havana focus on migrating in all projects to oslo.db code
[Gary Kotton] It is worth going for.
+1
2) in IceHouse create and move to oslo.db lib
[Gary Kotton] I am in favor of this pending the stability
On 08/19/2013 05:08 AM, Julien Danjou wrote:
> On Sun, Aug 18 2013, Jay Pipes wrote:
>
>> I'm proposing that in these cases, a *new* resource would be added to the
>> resource table (and its ID inserted in meter) table with the new
>> flavor/instance's metadata.
>
> Ah I see. Considering we're
Hi,
I've been trying to spend some time adding a few (hopefully) useful test
scenarios for neutron.
I have never commited anything into tempest, so I would appreciate any
feedback on the approach I am taking.
I have the following goals:
1) enable test_006_check_tenant_network_connectivity for neu
On submitted a Patch for neutron test case
https://review.openstack.org/#/c/42598/
unrelated tests from tempest seem to be failing.
http://logs.openstack.org/98/42598/2/check/gate-tempest-devstack-vm-neutron-full/4388bc6/console.html
One of the test failure is listed below.
Any idea why this i
From: Boris Pavlovic [mailto:bo...@pavlovic.me]
Sent: Monday, August 19, 2013 2:20 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Proposal oslo.db lib
Flavio,
I'm sorry if I'm being paranoid, I just think we should first focus on
migrating all projects - those that will
Flavio,
I'm sorry if I'm being paranoid, I just think we should first focus on
migrating all projects - those that will / should migrate -
successfully and then pulling oslo.db out.
Absolutely agree
Pulling it out during Icehouse won't slow Oslo's db development down.
So the only problem is th
On Sun, Aug 18, 2013 at 07:02:04PM +0200, Matthieu Huin wrote:
> Hi Steve,
>
> It might be a bit late for this, but here's a script I wrote when
> experimenting with trusts:
> https://github.com/mhuin/keystone_trust/blob/master/tests/swift_example.sh
>
> I hope it'll help you.
Thanks for this!
Mark,
Main part of oslo is:
1) common migration testing
2) common sqla.models
3) common hacks around sqla and sqla-migrate
4) common work around engines and sessions
All these points are implemented in Glance almost in the same way as in
Oslo.
Also we are able to use only part of this code in Gl
On 19/08/13 14:17 +0400, Boris Pavlovic wrote:
Flavio,
Agreed. I'd also like to see other project migrated before pulling
oslo.db out from oslo-incubator
as I wrote before oslo.db code is used by: Nova, Neutron, Cinder, Ironic,
Ceilometer use oslo.db. And we have already patches to switch in
Hi,
1) Can I Expose
the host-aggregate as availability zone?
2) Is there anyway to make the Host Aggregate dynamically growing (with each VM
creation- add the host to host aggregate if its not already there)?
Thanks,
Sudheesh___
OpenStack-dev mail
Hi,
1) Can I Expose
the host-aggregate as availability zone?
2) Is there anyway to make the Host Aggregate dynamically growing (with each VM
creation- add the host to host aggregate if its not already there)?
Thanks,
Sudheesh___
OpenStack-dev mailing
Flavio,
Agreed. I'd also like to see other project migrated before pulling
oslo.db out from oslo-incubator
as I wrote before oslo.db code is used by: Nova, Neutron, Cinder, Ironic,
Ceilometer use oslo.db. And we have already patches to switch in Glance to
id. And we are woking in Keystone and H
On 19/08/13 00:34 -0700, Gary Kotton wrote:
Hi,
I have a number of things to say here:
1. Great work in getting the DB into the common and ironing out the
issues
+1
2. As far as I know only Neutron and Nova are making use of the common DB
code. Neutron has been using this since
On Mon, Aug 19, 2013 at 01:28:25AM -0700, Tim Smith wrote:
> On Sun, Aug 18, 2013 at 1:28 PM, Robert Collins
> wrote:
>
> > On 17 August 2013 07:01, Russell Bryant wrote:
> >
> > >> Maybe we've grown up to the point where we have to be more careful and
> > >> not introduce
> > >> these kind of fe
On Mon, Aug 19, 2013 at 08:28:58AM +1200, Robert Collins wrote:
> On 17 August 2013 07:01, Russell Bryant wrote:
>
> >> Maybe we've grown up to the point where we have to be more careful and
> >> not introduce
> >> these kind of features and the maintenance cost of introducing
> >> experimental f
On 19/08/13 02:51 -0400, Jay Pipes wrote:
On 08/19/2013 12:56 AM, Joshua Harlow wrote:
Another good article from an ex-coworker that keeps on making more and
more sense the more projects I get into...
http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern
Your mileage/opinion though may vary
On 18/08/13 18:47 -0400, Jay Pipes wrote:
On 08/18/2013 06:28 PM, Joe Gordon wrote:
On Aug 18, 2013 3:58 PM, "Jay Pipes" mailto:jaypi...@gmail.com>> wrote:
>
> On 08/18/2013 03:53 AM, Joshua Harlow wrote:
>>
>> I always just liked SQL as the database abstraction layer ;)
>>
>> On a more serious
On Sun, Aug 18, 2013 at 1:28 PM, Robert Collins
wrote:
> On 17 August 2013 07:01, Russell Bryant wrote:
>
> >> Maybe we've grown up to the point where we have to be more careful and
> >> not introduce
> >> these kind of features and the maintenance cost of introducing
> >> experimental features i
On Mon, Aug 19 2013, Jay Pipes wrote:
> Thoughts?
+1
--
Julien Danjou
;; Free Software hacker ; freelance consultant
;; http://julien.danjou.info
signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.o
On Mon, Aug 19 2013, Jay Pipes wrote:
> 2) I highly caution folks who think a No-SQL store is a good storage
> solution for any of the data currently used by Nova, Glance (registry),
> Cinder (registry), Ceilometer, and Quantum. All of the data stored and
> manipulated in those projects is HIGHLY
On Sun, Aug 18 2013, Jay Pipes wrote:
> I'm proposing that in these cases, a *new* resource would be added to the
> resource table (and its ID inserted in meter) table with the new
> flavor/instance's metadata.
Ah I see. Considering we're storing metadata as a serialized string
(whereas it's a di
Hi Jay,
When I started working around unique keys, I tried to use deleted_at
column. so answer about why we don't use deleted_at column you could read
in Devananda's comment on my patch https://review.openstack.org/#/c/16162/ .
Also I should mention that this is really huge change and it will ta
'deleted' is used so that we can have proper unique constraints by setting it
to `id` on deletion. This was not the case until Grizzly, and before Grizzly I
would have agreed completely.
- Chris
On Aug 19, 2013, at 12:39 AM, Jay Pipes wrote:
> I'm throwing this up here to get some feedback o
OK, cool. I'm in agreement with your explained storage/logic separation
below.
Cheers,
-jay
On 08/19/2013 03:12 AM, Robert Collins wrote:
On 19 August 2013 18:35, Jay Pipes wrote:
http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html
The
I'm throwing this up here to get some feedback on something that's
always bugged me about the model base used in many of the projects.
There's a mixin class that looks like so:
class SoftDeleteMixin(object):
deleted_at = Column(DateTime)
deleted = Column(Integer, default=0)
def sof
Hi,
I have a number of things to say here:
1. Great work in getting the DB into the common and ironing out the issues
2. As far as I know only Neutron and Nova are making use of the common DB
code. Neutron has been using this since the beginning of H2 (this did not
resolve all of th
On 08/18/2013 10:33 PM, Joe Gordon wrote:
An alternative I think would be better would be to scrap the use of
the SQLAlchemy ORM; keep using the DB engine abstraction support.
+1, I am hoping this will provide noticeable performance benefits while
being agnostic of what DB back-e
On 19 August 2013 18:35, Jay Pipes wrote:
>> http://www.codinghorror.com/blog/2006/06/object-relational-mapping-is-the-vietnam-of-computer-science.html
>>
>> There is no proper use of an ORM.
>
>
> I'm not a super-fan of ORMs, Robert. I'm not sure why you're insisting on
> taking me down this roa
72 matches
Mail list logo
