Awesome guys,
Thanks for picking this up. I'm looking forward to the reviews :)
Walt
On 19.11.2013 10:38, Kekane, Abhishek wrote:
Hi All,
Greetings!!!
Hi there!
And thanks for your interest in cinder and taskflow!
We are in process of implementing the TaskFlow 0.1 in Cinder for "copy
v
On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short wrote:
> Hi
>
>
> On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner wrote:
>>
>> A substantive reason for switching from mox to mock is the derelict
>> state of mox releases. There hasn't been a release of mox in three
>> years: the latest, mox-0.5.3, wa
Sweet!
Feel free to ask lots of questions and jump on both irc channels
(#openstack-state-management and #openstack-cinder) if u need any help that can
be better solved in real time chat.
Thanks for helping getting this ball rolling :-)
Sent from my really tiny device...
> On Nov 19, 2013, at
Thanks Jarda for the intro;
Hi Stackers,
The project Search is a service providing fast full-text search for
resources across OpenStack services.
The idea was introduced and discussed at the Summit. We confirmed the
need for Search service: 1) from core Horizon team and UX 2) from
integrators bu
Isaku,
Do you have in mind any implementation, any BP?
We could actually work on this together, all plugins will get the benefits
of a better implementation.
Thanks,
Edgar
On 11/19/13 3:57 AM, "Isaku Yamahata" wrote:
>On Mon, Nov 18, 2013 at 03:55:49PM -0500,
>Robert Kukura wrote:
>
>> On 11
On 11/19/2013 08:21 AM, Dolph Mathews wrote:
Related BP:
Create a unified request identifier
https://blueprints.launchpad.net/nova/+spec/cross-service-request-id
And we have discussed workplans as well, which would be data to be
carried along with the request id
https://blueprints.launch
On Mon, Nov 18, 2013 at 8:58 PM, Lu, Lianhao wrote:
>
> Doug Hellmann wrote on 2013-11-19:
> >
> > On Mon, Nov 18, 2013 at 12:25 PM, Devananda van der Veen <
> devananda@gmail.com> wrote:
> >
> >
> > Hi Lianhao Lu,
> >
> > I briefly summarized my recollection of that session in th
Hi Kanthi,
The issue is that the nova-api says that by default every instance needs to
be in a default security group that blocks all ingress traffic from outside
and allows all ingress from instances that belong to the same security
group. If an instance does not have an ip address we are unable
On 11/19/2013 11:33 AM, Paula Ta-Shma wrote:
Hi Paula,
Where can we see the source code for the prototype and any API specs
that you may have?
Best,
-jay
Hi Jay,
Thanks for your interest. Our prototype intercepts Swift REST requests
using proxy server middleware and uses Solr as the indexi
On Tue, 2013-11-19 at 12:52 +, Daniel P. Berrange wrote:
> On Wed, Nov 13, 2013 at 02:46:06PM +0200, Tuomas Paappanen wrote:
> > Hi all,
> >
> > I would like to hear your thoughts about core pinning in Openstack.
> > Currently nova(with qemu-kvm) supports usage of cpu set of PCPUs
> > what can
On 11/18/2013 06:47 PM, Joshua Harlow wrote:
An idea related to this, what would need to be done to make the DB have
the exact state that a compute node is going through (and therefore the
scheduler would not make unreliable/racey decisions, even when there are
multiple schedulers). It's not like
Yes, my work has been on ML2 with neutron-openvswitch-agent. I’m interested to
see what Jun Park has. I might have something ready before he is available
again, but would like to collaborate regardless.
Amir
On Nov 19, 2013, at 3:31 AM, Kanthi P
mailto:pavuluri.kan...@gmail.com>> wrote:
Hi
On 11/18/2013 11:35 AM, Mike Spreitzer wrote:
There were some concerns expressed at the summit about scheduler
scalability in Nova, and a little recollection of Boris' proposal to
keep the needed state in memory. I also heard one guy say that he
thinks Nova does not really need a general SQL dat
Thanks Avishay.
I think the status description error was introduced with this aim.
Whether vendor-specific error descriptions can make sense to a tenant,
that's a good question.
Personally, I feel like as a tenant that information would not be a lot
useful to me, as I would not be able to do any d
On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> Hey all
>
> Not having been at the summit (maybe the next one), could somebody
> give a really short explanation as to why it needs to be a separate
> service?
> It sounds like it should fit within the Nova area. It is, after all,
> just anoth
Excerpts from Zane Bitter's message of 2013-11-15 12:41:53 -0800:
> Good news, everyone! I have created the missing whiteboard diagram that
> we all needed at the design summit:
>
> https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_Missing_Diagram
>
> I've documen
> My apologies, I'm apparently coming into this quite late :) Would you
> mind sharing a link to the HP proposal? I wasn't at the summit
> unfortunately and am playing a bit of catch up.
Hi Jay,
Take a look at https://wiki.openstack.org/wiki/MetadataSearch
There are links there to the REST API p
Matt,
As an option you may estimate the load using Stackalytics data on number of
commits -
http://stackalytics.com/?release=icehouse&metric=commits&project_type=all&module=sqlalchemy-migrateNumber
of commits is certainly less than number of patches, but for project
sqlalchemy-migrate the multipli
On Mon, Nov 18, 2013 at 5:57 AM, Zane Bitter wrote:
> On 16/11/13 11:15, Angus Salkeld wrote:
>
>> On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
>>
>>> On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter wrote:
>>>
>>> On 15/11/13 02:48, Christopher Armstrong wrote:
On Thu, Nov 14,
On 11/19/2013 01:08 PM, Paula Ta-Shma wrote:
My apologies, I'm apparently coming into this quite late :) Would you
mind sharing a link to the HP proposal? I wasn't at the summit
unfortunately and am playing a bit of catch up.
Hi Jay,
Take a look at https://wiki.openstack.org/wiki/MetadataSea
Personally I would prefer #3 from the below. #2 I think will still have to
deal with consistency issues, just switching away from a DB doesn't make
magical ponies and unicorns appear (in-fact it can potentially make the
problem worse if its done incorrectly - and its pretty easy to get it
wrong IMH
On Tue, Nov 19, 2013 at 6:45 AM, Chuck Short wrote:
> Hi
>
> I am excited to see containers getting such traction in the openstack
> project.
>
>
> On Mon, Nov 18, 2013 at 7:30 PM, Russell Bryant wrote:
>>
>> On 11/18/2013 06:30 PM, Dan Smith wrote:
>> >> Not having been at the summit (maybe the
If you start adding these states you might really want to consider the
following work that is going on in other projects.
It surely appears that everyone is starting to hit the same problem (and
joining efforts would produce a more beneficial result).
Relevant icehouse etherpads:
- https://etherp
Excerpts from Chris Friesen's message of 2013-11-19 09:29:00 -0800:
> On 11/18/2013 06:47 PM, Joshua Harlow wrote:
> > An idea related to this, what would need to be done to make the DB have
> > the exact state that a compute node is going through (and therefore the
> > scheduler would not make unr
And also of course, nearly forgot a similar situation/review in heat.
https://review.openstack.org/#/c/49440/
Except theres was/is dealing with stack locking (a heat concept).
On 11/19/13 10:33 AM, "Joshua Harlow" wrote:
>If you start adding these states you might really want to consider the
>
On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley
wrote:
> On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
>> Hey all
>>
>> Not having been at the summit (maybe the next one), could somebody
>> give a really short explanation as to why it needs to be a separate
>> service?
>> It sounds like it
Sorry that was I prefer #3 (not #2) at the end there. Keyboard failure ;)
On 11/19/13 10:27 AM, "Joshua Harlow" wrote:
>Personally I would prefer #3 from the below. #2 I think will still have to
>deal with consistency issues, just switching away from a DB doesn't make
>magical ponies and unicorn
On Wed, Nov 13, 2013 at 10:11 PM, Alex Glikson wrote:
> Thanks, I understand the Nova scheduler part. One of the gaps there is
> related to the blueprint we have are working on [1]. I was wondering
> regarding the role of Ironic, and the exact interaction between the user,
> Nova and Ironic.
>
T
Currently the Nova libvirt driver is declaring that it wants a minimum
of libvirt 0.9.6.
For cases where we use features newer than this, we have to do conditional
logic to ensure we operate correctly on old libvirt. We don't want to keep
adding conditionals forever since they complicate the code
On Tue, 2013-11-19 at 13:46 -0500, Eric Windisch wrote:
> On Tue, Nov 19, 2013 at 1:02 PM, James Bottomley
> wrote:
> > On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> >> Hey all
> >>
> >> Not having been at the summit (maybe the next one), could somebody
> >> give a really short explanatio
On Tue, Nov 19, 2013 at 10:02:45AM -0800, James Bottomley wrote:
> On Mon, 2013-11-18 at 14:28 -0800, Stuart Fox wrote:
> > Hey all
> >
> > Not having been at the summit (maybe the next one), could somebody
> > give a really short explanation as to why it needs to be a separate
> > service?
> > It
On 11/17/2013 01:57 PM, Steve Baker wrote:
On 11/15/2013 05:19 AM, Christopher Armstrong wrote:
http://docs.heatautoscale.apiary.io/
I've thrown together a rough sketch of the proposed API for
autoscaling. It's written in API-Blueprint format (which is a simple
subset of Markdown) and provides
On 11/19/2013 12:35 PM, Clint Byrum wrote:
Each scheduler process can own a different set of resources. If they
each grab instance requests in a round-robin fashion, then they will
fill their resources up in a relatively well balanced way until one
scheduler's resources are exhausted. At that ti
Hi,
I noticed that the Accept HTTP Header checked in the Version
Negotiation Middleware by Heat is the same MIME type used by Glance
("application/vnd.openstack.images-")
Is this OK, or should it be something like
"application/vnd.openstack.orchestration-"?
If this is the ca
On 11/19/2013 12:27 PM, Joshua Harlow wrote:
Personally I would prefer #3 from the below. #2 I think will still have to
deal with consistency issues, just switching away from a DB doesn't make
magical ponies and unicorns appear (in-fact it can potentially make the
problem worse if its done incorr
Excerpts from Chris Friesen's message of 2013-11-19 11:37:02 -0800:
> On 11/19/2013 12:35 PM, Clint Byrum wrote:
>
> > Each scheduler process can own a different set of resources. If they
> > each grab instance requests in a round-robin fashion, then they will
> > fill their resources up in a rela
On 11/19/2013 10:02 AM, James Bottomley wrote:
It is possible to extend the Nova APIs to control containers more fully,
but there was resistance do doing this on the grounds that it's
expanding the scope of Nova, hence the new project.
How well received would another CLI/API to learn be among t
On 11/19/2013 01:51 PM, Clint Byrum wrote:
Excerpts from Chris Friesen's message of 2013-11-19 11:37:02 -0800:
On 11/19/2013 12:35 PM, Clint Byrum wrote:
Each scheduler process can own a different set of resources. If they
each grab instance requests in a round-robin fashion, then they will
fi
Hi Vijay,
Thanks for working on this. As was discussed at the summit, immediate
solution seems to be passing certificates via transient fields in Vip
object, which will avoid the need for certificate management (incl. storing
them).
If certificate management is concerned then I agree that it needs
On 11/19/2013 03:08 PM, Rick Jones wrote:
> On 11/19/2013 10:02 AM, James Bottomley wrote:
>> It is possible to extend the Nova APIs to control containers more fully,
>> but there was resistance do doing this on the grounds that it's
>> expanding the scope of Nova, hence the new project.
>
> How w
On 11/19/2013 08:37 PM, Thomas Spatzier wrote:
> Steve Baker wrote on 18.11.2013 21:52:04:
>> From: Steve Baker
>> To: openstack-dev@lists.openstack.org,
>> Date: 18.11.2013 21:54
>> Subject: Re: [openstack-dev] [Heat] HOT software configuration
>> refined after design summit discussions
>>
>> On
On Mon, Nov 18, 2013 at 10:35 AM, Ladislav Smola wrote:
> Hello. I have a couple of additional questions.
>
> 1. What about IPMI data that we want to get by polling. E.g. temperatures,
> etc. Will the Ironic be polling these kind of
> data and send them directly to collector(or agent)? Not s
Excerpts from Steve Baker's message of 2013-11-18 12:52:04 -0800:
>
> Regarding apply_config/remove_config, if a SoftwareApplier resource is
> deleted it should trigger any remove_config and wait for the server to
> acknowledge when that is complete. This allows for any
> evacuation/deregistering
On 11/20/2013 09:50 AM, Clint Byrum wrote:
> Excerpts from Steve Baker's message of 2013-11-18 12:52:04 -0800:
>> Regarding apply_config/remove_config, if a SoftwareApplier resource is
>> deleted it should trigger any remove_config and wait for the server to
>> acknowledge when that is complete. Th
Excerpts from Steve Baker's message of 2013-11-19 13:06:21 -0800:
> On 11/20/2013 09:50 AM, Clint Byrum wrote:
> > Excerpts from Steve Baker's message of 2013-11-18 12:52:04 -0800:
> >> Regarding apply_config/remove_config, if a SoftwareApplier resource is
> >> deleted it should trigger any remove_
On 19/11/13 19:03, Clint Byrum wrote:
Excerpts from Zane Bitter's message of 2013-11-15 12:41:53 -0800:
Good news, everyone! I have created the missing whiteboard diagram that
we all needed at the design summit:
https://wiki.openstack.org/wiki/Heat/Blueprints/Multi_Region_Support_for_Heat/The_M
I'd like to propose an idea around a simplified and complimentary version of
devtest that makes it easier for someone to get started and try TripleO.
The goal being to get people using TripleO as a way to experience the
deployment of OpenStack, and not necessarily a way to get an experience of a
Greetings,
We've made a lot of progress on reviewing blueprints over the last week
and have the icehouse-1 [1] list in reasonable shape. Note that
icehouse-1 development must be completed two weeks from today, and that
time frame includes a major holiday in the US. Please adjust plans and
expect
Thierry Carrez wrote:
> Thierry Carrez wrote:
>> The two candidates who nominated themselves in time for this election are:
>>
>> * David Lyle
>> * Matthias Runge
>>
>> The election will be set up tomorrow, and will stay open for voting for
>> a week.
The poll is now closed, and the winner is Davi
On 11/19/2013 11:02 PM, Thierry Carrez wrote:
>
> The poll is now closed, and the winner is David Lyle !
>
David, well done and honestly deserved!
Matthias
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c
For what is worth we have considered this aspect from the perspective of
the Neutron plugin my team maintains (NVP) during the past release cycle.
The synchronous model that most plugins with a controller on the backend
currently implement is simple and convenient, but has some flaws:
- reliabili
On 19/11/13 19:40 +, Fuente, Pablo A wrote:
Hi,
I noticed that the Accept HTTP Header checked in the Version
Negotiation Middleware by Heat is the same MIME type used by Glance
("application/vnd.openstack.images-")
Is this OK, or should it be something like
"application/vnd.op
On 19/11/13 19:14, Christopher Armstrong wrote:
On Mon, Nov 18, 2013 at 5:57 AM, Zane Bitter mailto:zbit...@redhat.com>> wrote:
On 16/11/13 11:15, Angus Salkeld wrote:
On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter
Can u explain a little how using celery achieves workflow reliability and
avoids races (or mitigates spaghetti code)?
To me celery acts as a way to distribute tasks, but does not deal with actually
forming a easily understandable way of knowing that a piece of code that u
design is actually goi
On Nov 15, 2013, at 8:28 AM, Russell Bryant wrote:
> Greetings,
>
> We've talked a lot about requirements for new compute drivers [1]. I
> think the same sort of standards shold be applied for a new third-party
> API, such as the GCE API [2].
>
> Before we can consider taking on a new API, it
Thanks for your reply Joshua,
some more comments inline; however I think I'm probably going off topic
here given the initial subject of this thread.
Talking about Taskflow, and moving aside for the plugins, which have not a
lot of community-wide interest, do you reckon Taskflow might be something
On 16 November 2013 08:31, Joe Gordon wrote:
>> and building on unstable Nova APIs. Anything which we accept is a part
>> of OpenStack should not get randomly made unusable by one contributor
>> while other contributors constantly have to scramble to catch up. Either
>> stuff winds up being broke
On 20 November 2013 10:40, James Slagle wrote:
> I'd like to propose an idea around a simplified and complimentary version of
> devtest that makes it easier for someone to get started and try TripleO.
I think its a grand idea (in fact it's been floated many times). For a
while we ran our own jenk
On 11/19/2013 03:46 PM, Robert Collins wrote:
On 16 November 2013 08:31, Joe Gordon wrote:
and building on unstable Nova APIs. Anything which we accept is a part
of OpenStack should not get randomly made unusable by one contributor
while other contributors constantly have to scramble to catch
On Wed, Nov 20, 2013 at 11:00 AM, Sean Dague wrote:
> On 11/19/2013 03:46 PM, Robert Collins wrote:
>> As long as the metadataservice doesn't move out :) - that one I think
>> is pretty core and we have no native replacement [configdrive is not a
>> replacement :P].
>
> Slightly off tangent threa
Excerpts from Chris Friesen's message of 2013-11-19 12:18:16 -0800:
> On 11/19/2013 01:51 PM, Clint Byrum wrote:
> > Excerpts from Chris Friesen's message of 2013-11-19 11:37:02 -0800:
> >> On 11/19/2013 12:35 PM, Clint Byrum wrote:
> >>
> >>> Each scheduler process can own a different set of resou
On 20 November 2013 13:00, Sean Dague wrote:
>> As long as the metadataservice doesn't move out :) - that one I think
>> is pretty core and we have no native replacement [configdrive is not a
>> replacement :P].
>
>
> Slightly off tangent thread.
>
> So we recently moved devstack gate to do con fi
On 11/19/2013 08:19 AM, Julie Pichon wrote:
> I've been thinking about the AskBot UX website [0] and its lack of
> visibility, particularly for new community members.
Indeed, it's one of the drawbacks of splitting groups: information tends
not to flow very well.
> I think it would be valuable to
Hello Stackers!
I'm Thiago and I'm here on dev list mostly to watch you guys...
Nevertheless, I want to say that I would love to test in deep, the IPv6
support in OpenStack IceHouse.
At at glance, what I'm looking for is more or less specified here, as
follows:
---
I have 1 native IPv6 /48 bloc
One more thing...
I'm thinking about the "use case" for "Floating IPs" in a NAT-less IPv6
OpenStack environment.
I can think in two "use cases" in a IPv6-Only Tenant Subnet:
1- the Floating IP might be used to allocate more IPv6 address for an
Instance (since there is no plans for NAT66, I beli
Re-send again because been rejected by system.
Best Regards,
-fengqian
From: Gao, Fengqian
Sent: Tuesday, November 19, 2013 2:06 PM
To: openstack-dev@lists.openstack.org
Cc: 'Devananda van der Veen'; 'jbjoh...@us.ibm.com'; Lu, Lianhao; Wang, Shane
Subject: [Ironic] A question about getting IPMI
At yahoo at least 50+ simultaneous will be the common case (maybe we are
special).
Think of what happens on www.yahoo.com say on the olympics, news.yahoo.com
could need 50+ very very quickly (especially if say a gold medal is won by
some famous person). So I wouldn't discount those being the commo
On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin wrote:
> On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote:
>> Random OSLO updates with no list of what changed, what got fixed etc
>> are unlikely to get review attention - doing such a review is
>> extremely difficult. I was -2ing them and as
Carl, Yingjun,
I'm still getting the 2006 error even by configuring idle_interval to 1.
I applied the patch to the RDO havana dist on centos 6.4.
Are there any other options I should be considering such as min/max pool
size or use_tpool?
Thanks.
On Sat, Sep 7, 2013 at 3:33 AM, Baldwin, Carl
On 11/17/2013 09:55 PM, Eugene Nikanorov wrote:
Hi folks,
I'm working on major change to Neutron LBaaS API, obviously it will
break existing tempest API tests for LBaaS.
What would be the right process to deal with this? I guess I can't just
push fixed tests to tempest because they will not pass
Hi Edgar,
We had a similar issue and worked around by something like the following
(which I believe similar to what Aaron said):
@@ -45,6 +45,8 @@ SNAT_RULE_PROPERTY = {OS_TENANT_ROUTER_RULE_KEY: SNAT_RULE}
class MidonetResourceNotFound(q_exc.NotFound):
message = _('MidoNet %(resource_type)
Excerpts from Robert Collins's message of 2013-11-19 16:22:41 -0800:
> On 20 November 2013 13:00, Sean Dague wrote:
> >> As long as the metadataservice doesn't move out :) - that one I think
> >> is pretty core and we have no native replacement [configdrive is not a
> >> replacement :P].
> >
> >
>
On Nov 19, 2013, at 7:23 PM, Martinx - ジェームズ wrote:
>
> One more thing...
>
> I'm thinking about the "use case" for "Floating IPs" in a NAT-less IPv6
> OpenStack environment.
>
>
> I can think in two "use cases" in a IPv6-Only Tenant Subnet:
>
> 1- the Floating IP might be used to allocate m
On 11/20/2013 03:54 PM, Clint Byrum wrote:
> Excerpts from Robert Collins's message of 2013-11-19 16:22:41 -0800:
>> On 20 November 2013 13:00, Sean Dague wrote:
As long as the metadataservice doesn't move out :) - that one I think
is pretty core and we have no native replacement [config
Hi Daniel,
Thanks for your help in advance.
I have read your wiki page and it explains this issue very clearly.
But I have a question about the 'technical design', you give us a prototype
method as below:
def get_guest_cpu_topology(self, inst_type, image, preferred_topology,
mandatory_topology):
Hi Salvatore, et al,
On Mon, Nov 18, 2013 at 9:19 PM, Salvatore Orlando wrote:
> Hi Yair,
>
> I had in mind of doing something similar. I also registered a tempest
> blueprint for it.
> Basically I think we can assume test machines have access to the Internet,
> but the devstack deployment might
On 20 November 2013 08:02, Daniel P. Berrange wrote:
> Currently the Nova libvirt driver is declaring that it wants a minimum
> of libvirt 0.9.6.
...
> If there are other distros I've missed which expect to support deployment
> of Icehouse please add them to this list. Hopefully there won't be any
Hello Neutron team,
>From the "Testing Requirements" section, Tempest is mentioned as a
requirement.
Does that mean all the thirdparty vendors' system should run all the tests
in Tempest?
It might not make perfect sense to test image API for changes in the
neutron code.
So can we define some subs
On 20/11/13 14:33, Robert Collins wrote:
On 20 November 2013 08:02, Daniel P. Berrange wrote:
Currently the Nova libvirt driver is declaring that it wants a minimum
of libvirt 0.9.6.
...
If there are other distros I've missed which expect to support deployment
of Icehouse please add them to t
I've been thinking about this use case for a DHT-like design, I think I
want to do what other people have alluded to here and try and intercept
problematic requests like this one in some sort of "pre sending to
ring-segment" stage. In this case the "pre-stage" could decide to send this
off to a sch
On 20/11/13 15:43, Santosh Kumar wrote:
I am following Havana guide for creating three node set up.
Everything has been installed and configured.
However not able to create network for VMs , That's why when creating VM ..
they come out be without host-id ( VM gets lauch ).
#Nova network-creat
On 20 November 2013 17:55, Tom Fifield wrote:
> Hi Santosh,
>
> Thank you for supporting OpenStack.
...://ask.openstack.org
Thanks for doing this Tom. Can I suggest however, that when replying
one not change the topic? In gmail (which a /huge/ proportion of folk
use nowadays) that breaks the thre
Hi stackers,
Currently what I see is growing amount of interesting projects, that at
least I would like to track. But reading all mailing lists, and reviewing
all patches in all interesting projects to get high level understanding of
what is happing in project now, is quite hard or even impossibl
+1
On 20 November 2013 06:33, Boris Pavlovic wrote:
> Hi stackers,
>
>
> Currently what I see is growing amount of interesting projects, that at
> least I would like to track. But reading all mailing lists, and reviewing
> all patches in all interesting projects to get high level understanding
Another possible approach could be that only part of the 50 succeeds
(reported back to the user), and then a retry mechanism at a higher level
would potentially approach the other partition/scheduler - similar to
today's retries.
Regards,
Alex
From: Mike Wilson
To: "OpenStack Develop
Hi Eugene,
The proposal is simple, create a separate resource called
certificate (which will also be handled by Neutron+LBaaS plugin) rather than
having them in the VIP. It will maintain the original thought of security, the
certificate confidential parameters will be transient
Hi All,
As many of you have noticed the gate has been in very bad shape over the
past few days. Here is a list of some of the top open bugs (without
pending patches, and many recent hits) that we are hitting. Gate won't be
stable, and it will be hard to get your code merged, until we fix these
b
I think the idea in general is very good (I would be a heavy consumer of
such a thing myself). I am not sure how sustainable is to do it manually
though, especially for larger projects.
Maybe there is a reasonable way to automate this.. For example, if we
could generate a 'dashboard' for each p
Love the idea Boris - a nice read :)
Regards,
Tom
On 20/11/13 16:45, Michael Bright wrote:
+1
On 20 November 2013 06:33, Boris Pavlovic mailto:bpavlo...@mirantis.com>> wrote:
Hi stackers,
Currently what I see is growing amount of interesting projects, that
at least I would lik
Hi, all
There will be OpenStack I18n team meeting at UTC on Thursday (Nov 21th)
in IRC channel #openstack-meeting.
The time, we use Asia/America friendly time. Welcome to join the meeting.
This is the first I18n meeting after Icehouse design summit.
Summarize of the design summit in I18n ar
Hello Stackers,
I faced some social problems in community.
We started working on purge engine for DB (before HK summit)
This is very important, because at this moment we don't have any working
way to purge DB... so admins should make it by hand.
And we made this BP (in october)
https://bluepri
Excerpts from Steve Baker's message on 19.11.2013 21:40:54:
> From: Steve Baker
> To: openstack-dev@lists.openstack.org,
> Date: 19.11.2013 21:43
> Subject: Re: [openstack-dev] [Heat] HOT software configuration
> refined after design summit discussions
>
> I think there needs to a CM tool specifi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/11/13 16:33, Clint Byrum wrote:
> Excerpts from Vijay Venkatachalam's message of 2013-11-19 05:48:43
> -0800:
>> Hi Sam, Eugene, & Avishay, etal,
>>
>> Today I spent some time to create a write-up for SSL Termination
>> not exactly design doc. P
Tracy,
I've created etherpad with the summary:
https://etherpad.openstack.org/p/w5BwMtCG6z
--
Best regards,
Oleg Gelbukh
On Mon, Nov 18, 2013 at 11:17 PM, Tracy Jones wrote:
> Oleg - this is great! I tried to find you on IRC to recommend we put this
> on a etherpad so several of us can colla
Hi folks,
Let's meet on #openstack-meeting on Thrsday, 21, at 14-00 UTC
We'll discuss current progress and design of some of proposed features.
Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/c
On 18/11/13 16:46 +, Mark McLoughlin wrote:
On Mon, 2013-11-18 at 17:37 +0100, Julien Danjou wrote:
On Mon, Nov 18 2013, Mark McLoughlin wrote:
> I'm struggling to care about this until I have some insight into why
> it's important. And it's a bit frustrating to have to guess the
> ration
On Mon, Nov 18, 2013 at 07:10:53PM -0500, Krishna Raman wrote:
> We should probably meet on IRC or conf. call and discuss the suggested
> architecture, open questions and REST API.
>
> I have set up a doodle poll at http://doodle.com/w7y5qcdvq9i36757 to gather a
> times when we can meet.
> Pleas
Hi All,
Thanks for the response!
Amir,Mike: Is your implementation being done according to ML2 plugin
Regards,
Kanthi
On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson wrote:
> Hi Kanthi,
>
> Just to reiterate what Kyle said, we do have an internal implementation
> using flows that looks very simi
Russell Bryant wrote:
> My view of the outcome of the session was not "it *will* be a new
> service". Instead, it was, "we *think* it should be a new service, but
> let's do some more investigation to decide for sure".
>
> The action item from the session was to go off and come up with a
> propos
On Tue, Nov 19, 2013 at 10:57:51AM +0100, Thierry Carrez wrote:
> Russell Bryant wrote:
> > My view of the outcome of the session was not "it *will* be a new
> > service". Instead, it was, "we *think* it should be a new service, but
> > let's do some more investigation to decide for sure".
> >
>
1 - 100 of 136 matches
Mail list logo