Just chiming in with a side-note.
I always liked the idea of Postern for things like this though the crypto
geek in me always worries about making key retrieval too easy for
developers, bad things happen down that road.
The OSSG can help with overall secure design and would be happy to consult
if
Hi All,
The reason I ask this question in openstack-dev is there is a lot of
confusion going around other projects moving to keystone v3. Would it be a
problem if I use keystone v3 api for authenticating and point other
services to use keystone v2 with keystone v3 token? The main issue here is
key
On 28/05/14 17:01 +, Kurt Griffiths wrote:
Crew, as discussed in the last team meeting, I have updated the API v1.1 spec
to remove the ability to get one or more messages by ID. This was done to
remove unnecessary complexity from the API, and to make it easier to support
different types of me
Could we replace the refresh from the period task with a timestamp in the
network cache of when it was last updated so that we refresh it only when it’s
accessed if older that X ?
From: Aaron Rosen [mailto:aaronoro...@gmail.com]
Sent: 29 May 2014 01:47
To: Assaf Muller
Cc: OpenStack Development
On 05/27/14 16:44, Bartosz Kupidura wrote:
> Hello,
> Responses inline.
>
>
> Wiadomość napisana przez Vladimir Kuklin w dniu 27 maj
> 2014, o godz. 15:12:
>
>> Hi, Bartosz
>>
>> First of all, we are using openstack-dev for such discussions.
>>
>> Second, there is also Percona's RA for Percona
Hi, stackers
if i define provider when creating network, but no segmentation_id,
net-create fail. why not allocate segmentation_id automatically?
~$ neutron net-create test --provider:network_type=vlan --provider:physical_
network=default
Invalid input for operation: segmentation_id required for VL
Hey Mainn,
mostly it is driven by following requirements:
https://etherpad.openstack.org/p/ironic-ui
plus what you already know from Tuskar point of view - which is simply
monitoring, monitoring, monitoring :)
Hope it helps
-- Jarda
On 2014/29/05 05:51, Tzu-Mainn Chen wrote:
Hi Jarda,
Thes
Hi everyone,
Recently, wrapt was added as a dependency. The Python module suffers
from obvious design issues, like for example:
- Lack of Python 3.4 support
- Broken with Python 3.2
- Upstream sources in "src" instead of "wrapt" so then running py.test
doesn't work unless you do "ln -s src wrapt",
Sean Dague wrote:
> I honestly just think we might want to also use it as a time to rethink
> our program concept. Because all our programs that include projects that
> are part of the integrated release are 1 big source tree, and maybe a
> couple of little trees that orbit it (client and now specs
Hi James,
that's a good point. I just restructured the etherpad so that there are
3 sections: one is for July 28 - Aug 1, second is for July 21-25 and
third one is for those who want to attend but can't make it within
suggested dates. So I would like to encourage everybody who is willing
to a
On Thu, May 29, 2014 at 04:29:34AM +, Tracy Jones wrote:
> Hi Folks - I spoke with Michael at the summit about bug management for
> Juno. Other than tagging the untagged bugs each week,
I'm try to do that (and some triage/root-cause analysis for
libvirt/QEMU/KVM-based bugs and would like to
Hi, Folks,
When we configure VXLAN range [1,16M], neutron-server service costs long
time and cpu rate is very high(100%) when initiation. One test base on
postgresql has been verified: more than 1h when VXLAN range is [1, 1M].
So, any good solution about this performance issue?
Thanks,
Xurong Ya
On 05/29/2014 05:26 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> I honestly just think we might want to also use it as a time to rethink
>> our program concept. Because all our programs that include projects that
>> are part of the integrated release are 1 big source tree, and maybe a
>> couple
On 05/28/2014 10:03 PM, Gabriel Hurley wrote:
> It's sort of a silly point, but as someone who would likely consume the
> split-off package outside of the OpenStack context, please give it a
proper
> name instead of "django_horizon". The module only works in Django, the
name
> adds both clutter and
may be the problem is that you are using liftetime crm attributes instead
of 'reboot' ones. shadow/commit is used by us because we need transactional
behaviour in some cases. if you turn crm_shadow off, then you will
experience problems with multi-state resources and
location/colocation/order const
Hi,
vxlan network are inserted/verified in DB one by one, which could explain
the time required
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/type_vxlan.py#L138-L172
Cédric
On Thu, May 29, 2014 at 12:01 PM, Xurong Yang wrote:
> Hi, Folks,
>
> When we configur
Hi,
Just a reminder that the weekly Nova API meeting is being held tomorrow
Friday UTC .
We encourage cloud operators and those who use the REST API such as
SDK developers and others who and are interested in the future of the
API to participate.
In other timezones the meeting is at:
EST
On Wed, May 28, 2014 at 10:18 PM, Jaromir Coufal wrote:
> Hi All,
>
> There is a lot of tags in the subject of this e-mail but believe me that all
> listed projects (and even more) are relevant for the designs which I am
> sending out.
>
> Nodes management section in Horizon is being expected for
Hello,
Wiadomość napisana przez Vladimir Kuklin w dniu 29 maj
2014, o godz. 12:09:
> may be the problem is that you are using liftetime crm attributes instead of
> 'reboot' ones. shadow/commit is used by us because we need transactional
> behaviour in some cases. if you turn crm_shadow off,
Comment inline at bottom of message...
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: 06 May 2014 18:44
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Question about addit log in nova-compute.log
On 05/06/2014 01:37 PM, Jiang, Yunhong wrot
On 5/29/2014 4:41 AM, Xurong Yang wrote:
> Hi, stackers
> if i define provider when creating network, but no segmentation_id,
> net-create fail. why not allocate segmentation_id automatically?
> ~$ neutron net-create test --provider:network_type=vlan
> --provider:physical_network=default
> Invali
On 28 May 2014, at 20:02, Sergey Lukjanov wrote:
> Hey folks,
>
> it's a small wrap-up for the topic "Sahara subprojects releasing and
> versioning" that was discussed partially on summit and requires some
> more discussions. You can find details in [0].
>
>> common
>
> We'll include only one
On 05/28/2014 12:37 PM, Dat Tran wrote:
Hi everyone,
I have a idea for new project: Mahout-as-a-service.
Main idea of this project:
- Install OpenStack
- Deploying OpenStack Sahara source
- Deploying Mahout on Sahara OpenStack system.
- Construction of the API.
Through web or mobile interface,
On 05/29/2014 07:23 AM, Alexander Ignatov wrote:
On 28 May 2014, at 20:02, Sergey Lukjanov wrote:
sahara-image-elements
We're agreed that some common parts should be merged into the
diskimage-builder repo (like java support, ssh, etc.). The main issue
of keeping -image-elements separated is
On 28 May 2014, at 17:14, Sergey Lukjanov wrote:
> 1. How should we handle addition of new functionality to the API,
> should we bump minor version and just add new endpoints?
Agree with most of folks. No new versions on adding new endpoints.
Semantic changes require new major version of rest a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 28/05/14 23:03, Nachi Ueno wrote:
> Hi folks
>
> OK, so it looks like this is consensus in the community,
>
> Link bug or bp for most of commit Exception for not linking bug:
> (1) Infra sync (2) minor fix. (typo, small code refactor, fix doc
On 29/05/14 00:48, Eugene Nikanorov wrote:
> Hi,
>
> I have two questions that previously were briefly discussed. Both of them
> still cause discussions within advanced services community, so I'd like to
> make final clarification in this email thread.
>
> 1. Usage of "Service Type Framework"
> I
+1 to Carlos.
In addition, there should be possible for LBaaS (It might only be just the
LBaaS drivers) to get the information including the private key back so that
the backend can use it.
This means that a "trusted" communication channel between the driver and
Barbican needs to be established
From: Kieran Spear [mailto:kisp...@gmail.com]
Sent: 28 May 2014 06:05
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] nova default quotas
Hi Joe,
On 28/05/2014, at 11:21 AM, Joe Gordon
mailto:joe.gord...@gmail.com>> wrote:
On Tue, May 27
On Thu, 2014-05-29 at 11:26 +0200, Thierry Carrez wrote:
> Back to the topic, the tension here is because DNS is seen as a
> "network" thing and therefore it sounds like it makes sense under
> "Networking". But "programs" are not categories or themes. They are
> teams aligned on a mission statement
On Thu, 2014-05-29 at 08:00 +0930, Michael Davies wrote:
> On Thu, May 29, 2014 at 4:22 AM, Sean Dague wrote:
> > I would agree this doesn't make sense in Neutron.
> >
> > I do wonder if it makes sense in the Network program. I'm getting
> > suspicious of the programs for projects model if every n
Catching up...
On Thu, 2014-05-29 at 15:59 +0400, Alexander Ignatov wrote:
> On 28 May 2014, at 17:14, Sergey Lukjanov wrote:
> > 1. How should we handle addition of new functionality to the API,
> > should we bump minor version and just add new endpoints?
>
> Agree with most of folks. No new ve
Bunch of responses/thoughts:
> API
I'm ok that semantics additions could be done in one API version w/o
increasing minor version. I like the idea to keep only major API
versions starting from the next API version.
RE backward compat period, for now 1-2 cycles is ok.
> Images
Agreed that we shou
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable diskimage-builder version
The dib is now published to pypi, so, we could make
sahara-image-elemen
On 05/29/2014 09:59 AM, Trevor McKay wrote:
below, sahara-extra
sahara-extra
Keep it as is, no need to stop releasing, because we're not publishing
anything to pypi. No real need for tags.
Even if we keep the repo for now, I think we could simplify a little
bit. The edp-examples could be
Hi,
The blueprint let admins provide some provider attributes and let neutron
the remaining attributes.
The blueprint specification and associated implementation are under
reviews[1].
[1]
https://review.openstack.org/#/q/topic:bp/provider-network-partial-specs,n,z
On Thu, May 29, 2014 at 1:23 P
> client
We have separated launchpad project for client and we're publishing
client releases to it.
> extra
I'm neutral about moving job examples and API samples between sahara and extra
> ui tests
if we'll be able to remove sahara-dashboard before good integration
tests for our pages will be
below, sahara-extra
On Wed, 2014-05-28 at 20:02 +0400, Sergey Lukjanov wrote:
> Hey folks,
>
> it's a small wrap-up for the topic "Sahara subprojects releasing and
> versioning" that was discussed partially on summit and requires some
> more discussions. You can find details in [0].
>
> > common
- Original Message -
> > > sahara-extra
> >
> > Keep it as is, no need to stop releasing, because we're not publishing
> > anything to pypi. No real need for tags.
>
> Even if we keep the repo for now, I think we could simplify a little
> bit. The edp-examples could be moved to the Sah
- Original Message -
> Re sahara-image-elements we found a bunch of issues that we should
> solve and that's why I think that keeping current releasing is still
> the best option.
>
> - we should test it better and depend on stable diskimage-builder version
> The dib is now published to
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of them and
ability to publish them on OS infra.
O
what were the bunch of issues you ran into? will you capture them in a
blueprint or bug so they can be resolved?
best,
matt
On 05/29/2014 10:03 AM, Sergey Lukjanov wrote:
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current rele
On 05/29/2014 10:15 AM, Michael McCune wrote:
- Original Message -
Re sahara-image-elements we found a bunch of issues that we should
solve and that's why I think that keeping current releasing is still
the best option.
- we should test it better and depend on stable diskimage-builder
- Original Message -
> the image-elements is too unstable to be used by anyone but an expert at
> this point. imho we should make sure the experts produce working images
> first, it's what our users will need in the first place, then make the
> image generation more stable.
+1
mike
___
On 05/29/2014 10:22 AM, Sergey Lukjanov wrote:
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of
Hello Neutron core team,
We have three specs[1][2][3] submitted last week, for which have gotten +1s
from non core contributors.
It would be great if core devs could review them and give us some feedback.
(I noticed that I didn't include links to gerrit reviews in launchpad BPs
and just fixed them
On 29 May 2014, at 18:43, Matthew Farrellee wrote:
> i do not think we should release any images that have a root password set
> (essentially a backdoor).
>
> for K we should deprecate the hadoop1 versions and thus significantly cut the
> size of the new image artifact.
>
Agree don’t publis
Hi, Marios,
STF stands for 'service type framework'. It's the current way to dispatch
calls to different drivers based on 'provider' attribute of the LBaaS
service instance. Firewall and VPN implementations were not upstreamed as
we want to move to Flavor Framework.
I think the flavor framework d
I agree with this. No real sense in leaving image generation up to novice
users at this point.
+1
- Original Message -
From: "Michael McCune"
To: "OpenStack Development Mailing List (not for usage questions)"
Sent: Thursday, May 29, 2014 10:39:50 AM
Subject: Re: [openstack-dev] [sahar
Well, for my specific error, it was an intermittent ssl handshake error
before the request was ever sent to the
neutron-server. In our case, we saw that 4 out of 5 resize operations
worked, the fifth failed with this ssl
handshake error in neutronclient.
I certainly think a GET is safe to retry,
On Tue, May 27, 2014 at 6:07 PM, James E. Blair wrote:
> I wonder if it would
> be possible to detect them based on the presence of a "Verified" vote?
>
Not all CIs always add a vote. Only 3 or so of over 9000 Neutron's CIs put
their +/-1s on the change.
--
Kind regards, Yuriy.
___
Hello,
During the last Summit the use of AngularJS in Horizon was discussed and there
is the intention to do a better use of it in the dashboards.
I think this blueprint could help
https://blueprints.launchpad.net/horizon/+spec/django-angular-integration,
since it proposes the integration of D
On Wed, May 28, 2014 at 3:54 AM, Joe Gordon wrote:
> On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno wrote:
>
>> (2) Avoid duplication of works
>> I have several experience of this. Anyway, we should encourage people
>> to check listed bug before
>> writing patches.
>>
>
> That's a very good point,
I think this falls inline with other items we are working toward in
Horizon, namely more pluggable components on panels.
I think creating a directory in openstack_dashboard for these reusable
components makes a lot of sense. And usage should eventually moved to
there.
I would suggest something as
We are in the process of removing the redundancy between Project and Admin
by using RBAC to allow sharing of one code base for multiple roles. This
is a WIP.
David
On 5/28/14, 1:53 PM, "Tzu-Mainn Chen" wrote:
>Hi Doug,
>
>Thanks for the response! I agree with you in the cases where we are
>ext
Currently hitting https://bugs.launchpad.net/devstack/+bug/1323430 with
devstack HEAD. Anyone else?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Ryan Brady writes:
>> Would you want to merge the patches that simply remove the unneeded
>> lines and then let me followup with patches that remove © along with
>> the then unnecessary coding lines?
>
> If I was in your position, I'd update the patches that remove lines to
> include all of the a
Hi Everyone,
So we'd like to announce to everyone that we're going to be doing a combined
Infra and QA program mid-cycle meet-up. It will be the week of July 14th in
Darmstadt, Germany at Deutsche Telekom who has graciously offered to sponsor the
event. The plan is to use the week as both a time
I like the idea
2014-05-29 8:33 GMT-07:00 Yuriy Taraday :
> On Wed, May 28, 2014 at 3:54 AM, Joe Gordon wrote:
>>
>> On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno wrote:
>>>
>>> (2) Avoid duplication of works
>>> I have several experience of this. Anyway, we should encourage people
>>> to check l
I will take them!
Edgar
From: Tomoe Sugihara mailto:to...@midokura.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 29, 2014 at 7:57 AM
To: "OpenStack Development Mailing List (not for usage questions)"
As I was reviewing this patch today:
https://review.openstack.org/#/c/96160/
It occurred to me that the tuskar project is part of the tripleo
program:
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n247
I wondered if business, including bots posting to irc for #tu
Hi folks!
During the Atlanta Summit there was quite a lot of talks about the
Application Lifecycle management and Murano's role in this process. There
were several cross-project sessions between Murano, Heat and Solum teams
([1]) at which it was decided that Murano has its own place in the
applica
On Thu 29 May 2014 10:25:02 AM MDT, Anita Kuno wrote:
> As I was reviewing this patch today:
> https://review.openstack.org/#/c/96160/
>
> It occurred to me that the tuskar project is part of the tripleo
> program:
> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n2
as per discussions on l3 subteem meeting today, i started
a bgp speakers comparison wiki page for this bp.
https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison
Artem, can you add other requirements as columns?
as one of ryu developers, i'm naturally biased to ryu bgp.
i appreciate if so
Hi Paul,
Just out of curiosity, I am assuming you are using the client that
still relies on httplib2. Patch [1] replaced httplib2 with requests,
but I believe that a new client that incorporates this change has not
yet been published. I wonder if the failures you are referring to
manifest themselv
On 29/05/14 05:26, Thierry Carrez wrote:
Sean Dague wrote:
I honestly just think we might want to also use it as a time to rethink
our program concept. Because all our programs that include projects that
are part of the integrated release are 1 big source tree, and maybe a
couple of little trees
jebl...@openstack.org (James E. Blair) writes:
> Nikita Konovalov has been reviewing changes to both storyboard and
> storyboard-webclient for some time. He is the second most active
> storyboard reviewer and is very familiar with the codebase (having
> written a significant amount of the server
I agree that there is room for improvement on the Federation design within
Keystone. I would like to re-iterate what Adam said that we are already seeing
efforts to fully integrate further protocol support (OpenID Connect, etc)
within the current system. Lets be sure that whatever redesign work
jebl...@openstack.org (James E. Blair) writes:
> The Infrastructure program has a unique three-tier team structure:
> contributors (that's all of us!), core members (people with +2 ability
> on infra projects in Gerrit) and root members (people with
> administrative access). Read all about it her
jebl...@openstack.org (James E. Blair) writes:
> The Infrastructure program has a unique three-tier team structure:
> contributors (that's all of us!), core members (people with +2 ability
> on infra projects in Gerrit) and root members (people with
> administrative access). Read all about it her
Yes, we're still on a code level that uses httplib2. I noticed that as
well, but wasn't sure if that would really
help here as it seems like an ssl thing itself. But... who knows?? I'm
not sure how consistently we can
recreate this, but if we can, I'll try using that patch to use requests and
se
On Wed, May 28, 2014 at 11:42 PM, Robert Collins
wrote:
> Is there any wiggle room on those dates? As James Polley says, PyCon
> AU (and the Openstack miniconf, which I'm organising with JHesketh)
> overlap significantly - and I can't be in two places at once.
>
> However July 21-25th would be tot
Hi Jaromir,
I agree that the midcycle meetup with TripleO and Ironic was very
beneficial last cycle, but this cycle, Ironic is co-locating its sprint
with Nova. Our focus needs to be working with them to merge the
nova.virt.ironic driver. Details will be forthcoming as we work out the
exact detail
Devananda van der Veen wrote on 05/29/2014
01:26:12 PM:
> Hi Jaromir,
>
> I agree that the midcycle meetup with TripleO and Ironic was very
> beneficial last cycle, but this cycle, Ironic is co-locating its
> sprint with Nova. Our focus needs to be working with them to merge
> the nova.virt.
+1! Excellent summary and analysis Morgan!
--Brad
Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet: bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680
From: Morgan Fainberg
To: "OpenStack Development Mailing List (not for usage questions)"
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh <
joshua.hesk...@rackspace.com> wrote:
> On 5/29/14 8:52 AM, James E. Blair wrote:
>
>> Devananda van der Veen writes:
>>
>> Hi all!
>>>
>>> This is a follow-up to several summit discussions on
>>> how-do-we-deprecate-baremetal, a summary of the p
Hi thomas,
Since I'm the one that added wrapt to the requirements list I thought it
would be appropriate for me to respond :)
So looking over the pull request it seems like there was agreement that
the issues will be fixed and the adjustments will occur (that seems to be
the case last time I chec
On 5/27/2014 4:44 PM, Vishvananda Ishaya wrote:
I’m not sure that this is the right approach. We really have to add the old
extension back for compatibility, so it might be best to simply keep that
extension instead of adding a new way to do it.
Vish
On May 27, 2014, at 1:31 PM, Cazzolato,
On Wed, May 28, 2014 at 8:14 PM, Jander lu wrote:
> Hi, guys, I have two confused part in Ironic.
>
>
>
> (1) if I use nova boot api to launch an physical instance, how does nova
> boot command differentiate whether VM or physical node provision? From
> this article, nova bare metal use "Placemen
On Thu, May 29, 2014 at 12:59 PM, Morgan Fainberg wrote:
>
>
> David and Kristy, the slides and summit session are a great starting place
> for this work. Now we need to get the proposal drafted up in the new
> Keystone-Specs repository (
> https://git.openstack.org/cgit/openstack/keystone-specs )
And /me is no longer the "new guy" :)
On Thu, May 29, 2014 at 9:05 PM, James E. Blair wrote:
> jebl...@openstack.org (James E. Blair) writes:
>
>> The Infrastructure program has a unique three-tier team structure:
>> contributors (that's all of us!), core members (people with +2 ability
>> on inf
A further vote to maintain compatibility . One of the key parts to a good
federation design is to be using it in the field and encountering real life
problems.
Production sites expect stability of interfaces and functions. If this cannot
be reasonably ensured, the federation function deploymen
mishandling of SSL was the very reason why I brought that change
forward; so I wouldn't rule it out completely ;)
A.
On 29 May 2014 19:15, Paul Ward wrote:
> Yes, we're still on a code level that uses httplib2. I noticed that as
> well, but wasn't sure if that would really
> help here as it see
On Thu, May 29, 2014 at 12:59 PM, Tim Bell wrote:
>
>
> A further vote to maintain compatibility . One of the key parts to a good
> federation design is to be using it in the field and encountering real life
> problems.
>
>
>
> Production sites expect stability of interfaces and functions. If thi
On 20 May 2014 20:53, Julien Danjou wrote:
> On Mon, May 19 2014, Jay Pipes wrote:
>
>> I think at that point I mentioned that there were a number of places that
>> were using the SELECT ... FOR UPDATE construct in Nova (in SQLAlchemy, it's
>> the with_lockmode('update') modification of the query
> I didn't realize it would violate Django community's conventions, can you
> point to where they are documented?
There's no single document that says "you must name this way", but if you look
at all the most popular django packages, they all follow a similar trend.
The Django tutorial does actu
Hi there!
Recently we've changed the way application packages are paginated in
murano-dashboard (AppCatalog and Package Definitions panels) -
adopting the Glance approach with generators and 'next_marker'
property. This change concerns all 3 murano components - murano-api
[1], python-muranoclient
So as another of the panelists on this panel that Jay organized some
comments on Julien's reply below.
| On Mon, May 19 2014, Jay Pipes wrote:
|
| > I think at that point I mentioned that there were a number of places
| > that were using the SELECT ... FOR UPDATE construct in Nova (in
| > SQLAlch
On 29/05/14 13:33, Mike Spreitzer wrote:
Devananda van der Veen wrote on 05/29/2014
01:26:12 PM:
> Hi Jaromir,
>
> I agree that the midcycle meetup with TripleO and Ironic was very
> beneficial last cycle, but this cycle, Ironic is co-locating its
> sprint with Nova. Our focus needs to be
I just bent Jay's ear on IRC about this for a bit...
On 21 May 2014 05:07, Jay Pipes wrote:
>> We are one of those operators that use Galera for replicating our mysql
>> databases. We used to see issues with deadlocks when having multiple
>> mysql writers in our mysql cluster. As a workaround w
On 05/28/2014 08:54 AM, Radomir Dopieralski wrote:
> Hello,
>
> we plan to finally do the split in this cycle, and I started some
> preparations for that. I also started to prepare a detailed plan for the
> whole operation, as it seems to be a rather big endeavor.
>
> You can view and amend the p
Before solving everything, I would like first to itemize the things we should
solve/consider.
So pleas focus first on what is it that we need to pay attention for and less
on how to solve such issues.
Follows the list of items:
· Provisioning status/state
o Should it only be on the l
Forgive me if I'm misunderstanding, but those all look like repositories that
are strictly tracking upstreams. They're not maintained by the
Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
- Gabriel
> -Original Message-
> From: Anita Kuno [mailto:ante...@ante
On 05/29/2014 03:45 PM, Gabriel Hurley wrote:
> Forgive me if I'm misunderstanding, but those all look like repositories that
> are strictly tracking upstreams. They're not maintained by the
> Horizon/OpenStack developers whatsoever. Is this intentional/necessary?
>
> - Gabriel
The permissio
Hello Barbican devs. I was wondering if we could get some of you to weigh in on
a couple of reviews for adding Barbican support in Heat. We seem to be churning
a bit around current and future features supported by the resources and could
use some expert opinions.
Blueprint: https://blueprints.l
Hello Randall,
We'll take a look at these CRs for sure, thanks.
Thanks,
John
From: Randall Burt [randall.b...@rackspace.com]
Sent: Thursday, May 29, 2014 3:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Ba
Httplib2 does very little directly with ssl other than a wrap_socket call.
Unless requests has special ssl error handling and retry logic, it will be
exposed to the same set of underlying errors from the ssl library so a
retry that at least catches socket and ssl errors is a good idea.
On May 29, 2
The idea here is to decouple 3rd party static files from being embedded in
the Horizon repo. There are several reasons for this move. With embedded
3rd party static files upgrading the static files is cumbersome, versions
can be difficult to track and updates can be difficult to synchronize.
This c
On 05/29/2014 04:55 PM, Lyle, David wrote:
> The idea here is to decouple 3rd party static files from being embedded in
> the Horizon repo. There are several reasons for this move. With embedded
> 3rd party static files upgrading the static files is cumbersome, versions
> can be difficult to track
Keshava,
How much of a problem is routing prefix fragmentation for you?
Fragmentation causes routing table bloat and may reduce the performance of
the routing table. It also increases the amount of information traded by
the routing protocol. Which aspect(s) is (are) affecting you? Can you
quan
1 - 100 of 125 matches
Mail list logo
