From what I can see, the ring gets created and rebalanced in
puppet-swift/manifest/ringbuilder.pp i.e calling:
class { '::swift::ringbuilder':
# the part power should be determined by assuming 100 partitions
per drive
part_power => '18',
replicas => '3',
min_part_ho
Hongbin,
Good use case. I suggest that we add a parameter to magnum bay-create that will
allow the user to override the baymodel.apiserver_port attribute with a new
value that will end up in the bay.api_address attribute as part of the URL.
This approach assumes implementation of the magnum-api
Hello,
guys, I found the default configuration of redis is not changed as the
flavor changed. Why this? I think it should be like mysql default configuraion
that
will changed as the instrance's flavor changed.
--
Best
Li Tianqing__
On 06/12/2015 04:53 PM, Rich Megginson wrote:
I've done a first pass of setting up a puppet module to configure
Keystone to use ipsilon for federation, using
https://github.com/richm/puppet-apache-auth-mods, and a version of
ipsilon-client-install with patches
https://fedorahosted.org/ipsilon/
A use case could be the cloud is behind a proxy and the API port is filtered.
In this case, users have to start the service in an alternative port.
Best regards,
Hongbin
From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: June-12-15 2:22 PM
To: OpenStack Development Mailing List (not for
Our maintenance has concluded successfully without incident and the
accompanying Gerrit outage was roughly an hour.
We moved 57 repositories to new Git namespaces:
stackforge/cookbook-openstack-bare-metal
-> openstack/cookbook-openstack-bare-metal
stackforge/cookbook-openstack-blo
I second Henry! Great addition to the team!
Edgar
On 6/12/15, 2:39 PM, "Henry Gessau" wrote:
>Although I am not on your list I would like to add my +1! Yamamoto shows great
>attention to detail in code reviews and frequently finds real issues that were
>not spotted by others.
>
>On Thu, Jun
It turns out we already have one: https://launchpad.net/magnum-ui
The Driver is already set to "Magnum Drivers”.
On Jun 12, 2015, at 12:26 PM, Adrian Otto
mailto:adrian.o...@rackspace.com>> wrote:
Okay, I will think on that a bit.
Adrian
Original message
From: "Steven Dake
Team,
While triaging this bug, I got to thinking about unique names:
https://bugs.launchpad.net/solum/+bug/1434293
Should our app names be unique? Why? Should I open a blueprint for a new
feature to make name uniqueness optional, and default it to “on”. If not, why?
Thanks,
Adrian
___
Team,
We currently delete logs for an app when we delete the app[1].
https://bugs.launchpad.net/solum/+bug/1463986
Perhaps there should be an optional setting at the tenant level that determines
whether your logs are deleted or not by default (set to off initially), and an
optional parameter t
Excerpts from Alec Hothan (ahothan)'s message of 2015-06-12 13:41:17 -0700:
>
> On 6/1/15, 5:03 PM, "Davanum Srinivas" wrote:
>
> >fyi, the spec for zeromq driver in oslo.messaging is here:
> >https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage
> >.rst,unified
> >
> >-- di
+1!
On Fri, Jun 12, 2015 at 1:44 PM, Kevin Benton wrote:
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would like Rossella
> Sblendido to be a member of the control plane core reviewer team.
>
> Her review stats are in line with other cores[2] and her feedback on patches
> re
Hi, Alec
Thanks for email threads investigation.
I've decided to spend more time to dig into old zmq-related threads too.
Some notes inline.
6/12/15 23:41, Alec Hothan (ahothan) пишет:
On 6/1/15, 5:03 PM, "Davanum Srinivas" wrote:
fyi, the spec for zeromq driver in oslo.messaging is here:
h
> -Original Message-
> From: KARR, DAVID
> Sent: Thursday, June 11, 2015 8:00 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] Looking for help getting git-review to
> work over https
>
> *** Security Advisory: This Message Originated Outside
A big +1 from me. Rossella is also a great community influence with her "Land
your first patch" for Neutron talk at the Paris summit.
On Fri, Jun 12, 2015, Kevin Benton wrote:
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would like Rossella
> Sblendido to be a member of the
Although I am not on your list I would like to add my +1! Yamamoto shows great
attention to detail in code reviews and frequently finds real issues that were
not spotted by others.
On Thu, Jun 11, 2015, Kevin Benton wrote:
> Hello all!
>
> As the Lieutenant of the built-in control plane[1], I wo
+1
On 12 June 2015 at 13:49, Edgar Magana wrote:
> Excellent news! +1
>
> Cheers,
>
> Edgar
>
>
> On Jun 12, 2015, at 12:50 PM, Kevin Benton wrote:
>
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would
> like Rossella Sblendido to be a member of the control plane core
I think Shraddha was talking about the gateway IP the DHCP server will respond
with. Different VMs will get different gateways.
- Original Message -
> That logic is contained in the virtual machine. We have no control over that.
>
> On Thu, Jun 11, 2015 at 3:34 PM, Shraddha Pandhe <
> spa
+1
- Original Message -
> Excellent news! +1
>
> Cheers,
>
> Edgar
>
>
> On Jun 12, 2015, at 12:50 PM, Kevin Benton < blak...@gmail.com > wrote:
>
>
>
>
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would like Rossella
> Sblendido to be a member of the control
That logic is contained in the virtual machine. We have no control over
that.
On Thu, Jun 11, 2015 at 3:34 PM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:
> The idea is to round-robin between gateways by using some sort of mod
> operation
>
> So logically it can look something like:
>
>
This thread kind of deteriorated a bit (though it looks like it's
hopefully recovering), so I'd just like to add some observations.
What we have here is a classic case of a long-running fork, with all
that that entails. In this case the fork is a public one, but that
actually makes very little
Just to follow up, I've posted a revised specification which only include
group *IDs* in tokens (so, effectively promoting OS-FEDERATION's behavior
to core without modification) and mention of an X-Group-Ids header in
keystonemiddleware.auth_token:
https://review.openstack.org/#/c/188564/
On We
I've done a first pass of setting up a puppet module to configure
Keystone to use ipsilon for federation, using
https://github.com/richm/puppet-apache-auth-mods, and a version of
ipsilon-client-install with patches
https://fedorahosted.org/ipsilon/ticket/141 and
https://fedorahosted.org/ipsilo
Hi everyone,
Any thoughts on supporting multiple gateway IPs for subnets?
On Thu, Jun 11, 2015 at 3:34 PM, Shraddha Pandhe <
spandhe.openst...@gmail.com> wrote:
> The idea is to round-robin between gateways by using some sort of mod
> operation
>
> So logically it can look something like:
>
I am pleased to announce git-review 1.25.0 is officially released
today (Friday, June 12, 2015). This version brings together 43 new
changes from 23 different collaborators including fixes for 9 bugs
and a variety of other improvements:
https://git.openstack.org/cgit/openstack-infra/git-review/log
Excellent news! +1
Cheers,
Edgar
On Jun 12, 2015, at 12:50 PM, Kevin Benton
mailto:blak...@gmail.com>> wrote:
Hello!
As the Lieutenant of the built-in control plane[1], I would like Rossella
Sblendido to be a member of the control plane core reviewer team.
Her review stats are in line with
On 6/1/15, 5:03 PM, "Davanum Srinivas" wrote:
>fyi, the spec for zeromq driver in oslo.messaging is here:
>https://review.openstack.org/#/c/187338/1/specs/liberty/zmq-patterns-usage
>.rst,unified
>
>-- dims
I was about to provide some email comments on the above review off gerrit,
but figured
On 6/12/2015 11:11 AM, Chen CH Ji wrote:
Hi
We have [1] in the db layer and it's directly used by API
layer , the filters is directly from client's input
In this case, when doing [2] or similar changes, do we
need to consider microversion usage when we change options
On Fri, Jun 12, 2015 at 01:23:28PM -0700, James Bottomley wrote:
> However, the commit history is vital to obtaining the provenance of the
> code. If there's ever a question about who authored what part of the
> code (or worse, who copied it wrongly from a different project, as in
> the SCO suit a
On Fri, Jun 12, 2015 at 12:14:52PM -0400, Emilien Macchi wrote:
> On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote:
> > IMO, it's a communication issue and related more to Puppet OpenStack
> > community that to Fuel Library folks. In Fuel Library when patch from
> > external contributor has some pr
On Fri, 2015-06-12 at 13:05 -0700, Dmitry Borodaenko wrote:
> On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> > On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > > What about code history and re
On 06/12/2015 03:33 PM, Dmitry Borodaenko wrote:
> On Fri, Jun 12, 2015 at 02:25:31PM +0200, Flavio Percoco wrote:
>>> I have already explained in the thread how we address the problem of
>>> tracking down and managing the Fuel specific changes in forked modules.
>>> With that problem addressed,
On 6/12/15, 14:46, "KARR, DAVID" wrote:
>> -Original Message-
>> From: Kevin L. Mitchell [mailto:kevin.mitch...@rackspace.com]
>> Sent: Friday, June 12, 2015 12:05 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] Looking for help getting git-review to
>> work
On Fri, Jun 12, 2015 at 08:33:56AM -0700, James Bottomley wrote:
> On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> > On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > > What about code history and respect of commit ownership?
> > > I'm personally wondering if it's fa
> -Original Message-
> From: Ian Cordasco [mailto:ian.corda...@rackspace.com]
> Sent: Friday, June 12, 2015 12:05 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Looking for help getting git-review to
> work over https
>
> It looks like
Hi Everyone,
Thanks for joining the service chaining meeting on 6/11/2015. Here are the
links to the meeting logs:
http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.html
http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.txt
h
On Fri, Jun 12, 2015 at 2:44 PM, Kevin Benton wrote:
> Hello!
>
> As the Lieutenant of the built-in control plane[1], I would like Rossella
> Sblendido to be a member of the control plane core reviewer team.
>
> Her review stats are in line with other cores[2] and her feedback on
> patches relate
> -Original Message-
> From: Kevin L. Mitchell [mailto:kevin.mitch...@rackspace.com]
> Sent: Friday, June 12, 2015 12:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] Looking for help getting git-review to
> work over https
>
> On Fri, 2015-06-12 at 17:08 +,
Hello!
As the Lieutenant of the built-in control plane[1], I would like Rossella
Sblendido to be a member of the control plane core reviewer team.
Her review stats are in line with other cores[2] and her feedback on
patches related to the agents has been great. Additionally, she has been
working
On Fri, Jun 12, 2015 at 02:25:31PM +0200, Flavio Percoco wrote:
> >I have already explained in the thread how we address the problem of
> >tracking down and managing the Fuel specific changes in forked modules.
> >With that problem addressed, I don't see any other objective reason for
> >frustratio
Okay, I will think on that a bit.
Adrian
Original message
From: "Steven Dake (stdake)"
Date: 06/12/2015 8:04 AM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum -
need
It looks like it can't run the setup.py because it can't find pbr.
Could you provide the following:
- Version of pip you're using (pip --version)
- How you installed pip (e.g., apt-get install -y python-pip)
- Contents of your global pip configuration (if one exists, it will be in
~/.pip/)
- What
On Fri, 2015-06-12 at 17:08 +, KARR, DAVID wrote:
> Thanks. I already tried that. It's not even clear this is failing to
> connect. I don't know what this is telling me.
> --
> # pip install --proxy http://one.proxy.att.com:8080 .
> Processing /home/dk068x/work/git-review
>
Dear Mike
It has come to my attention that during the work done to submit code into
OpenStack one of our Engineers had accidently deleted the original copyright
notice thereby failing to give credit to the original authors of the code
namely “Objectif Libre”. It was inadvertent and there was no
Hello OpenStack TC and stackers!
We’ve submitted a patch to add Cue to the OpenStack project list.
https://review.openstack.org/#/c/191173/
For those not familiar, Cue is a Message Broker Provisioning and Lifecycle
Management service for OpenStack. We’ve focused initially on RabbitMQ, and
are s
Egor makes a good point. If we have the API port number on the Baymodel, and
Magnum sets the api_address value to a URL that contains the correct protocol,
address, and port for the native API service. Here is the blueprint for that:
https://blueprints.launchpad.net/magnum/+spec/magnum-api-addre
Team,
Starting next week, I will be asking our blueprint assignees (or a chosen
delegate) to provide a brief team update on each of our Essential and High
priority blueprints. We currently have 11 of them so, let’s plan to keep the
updates concise in the < 3 min range.
Remember that if you are
Team,
OpenStack Networking support for Magnum Bays was an important topic for us in
Vancouver at the design summit. Here is one blueprint that requires discussion
that’s beyond the scope of what we can easily fit in the BP whiteboard:
https://blueprints.launchpad.net/magnum/+spec/native-docker-
Thanks for raising this for discussion. Although I do think that the API port
humber should be expressed in a URL that the local client can immediately use
for connecting a native client to the API, I am not convinced that this needs
to be a separate attribute on the Bay resource.
In general, I
Sean,
Thanks for quick fix/revert https://review.openstack.org/#/c/191010/
This unblocked Rally gates...
Best regards,
Boris Pavlovic
On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum wrote:
> Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700:
> >
> > On 6/12/15 11:37 AM, Mike Bayer w
Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700:
>
> On 6/12/15 11:37 AM, Mike Bayer wrote:
> >
> >
> > On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
> >> Hi neutrons,
> >>
> >> I'd like to draw your attention to an issue discovered by rally gate job:
> >> http://logs.openstack.org/9
Dirk Müller wrote:
Hi Russel,
I'm just kind of curious ... as both the RDO and SUSE folks look closer
at this, how big are the differences?
From the overall big picture, we're doing pretty much the same thing.
We have both a tool chain to continuously track changes as they happen
in upstream
On 06/12/2015 01:31 PM, Dirk Müller wrote:
>> If instead it seems
>> the differences are minor enough that combining efforts is a win for
>> everyone, then that's even better, but I don't see it as the required
>> outcome here personally.
>
> Right. We've started with an open discussion and not st
Hello All,
I wanted to share some of our next working items and hopefully get more
people on board with the project.
I personally would mentor any new comer that wants to get familiar with the
project and help
with any of these items.
You can also feel free to approach Russell Bryant (rbry...@redh
Hi Russel,
> I'm just kind of curious ... as both the RDO and SUSE folks look closer
> at this, how big are the differences?
>From the overall big picture, we're doing pretty much the same thing.
We have both a tool chain to continuously track changes as they happen
in upstream git, packaging tha
> -Original Message-
> From: Ian Cordasco [mailto:ian.corda...@rackspace.com]
> Sent: Friday, June 12, 2015 9:57 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Looking for help getting git-review to
> work over https
>
> Python has gene
On 06/12/2015 12:47 PM, Dirk Müller wrote:
> Hi,
>
> A couple of packagers from RDO and SUSE met today on IRC to kick off
> brain storming on unified upstream rpm packaging for OpenStack.
>
> Please note: there are currently two movements going on: RDO would
> like to move their Liberty packaging
Python has generally awful support for doing HTTPS over an HTTPS proxy.
Can you try doing:
# pip install --proxy http://one.proxy.att.com:
Cheers,
Ian
On 6/12/15, 10:26, "KARR, DAVID" wrote:
>As I apparently have to sudo this, it would likely be more effective, if
>at all, to specify the proxy
The "serial console" feature was introduced during the Juno cycle and
is an alternative to remote access via VNC, RDP, SPICE for platforms
which don't support these. The review 180912 adds a new row for this
feature in the hypervisor support matrix [1]. Please have a look if you
can make a support
On Thu, Jun 11, 2015 at 9:54 AM, James E. Blair wrote:
> 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 abou
Hi,
A couple of packagers from RDO and SUSE met today on IRC to kick off
brain storming on unified upstream rpm packaging for OpenStack.
Please note: there are currently two movements going on: RDO would
like to move their Liberty packaging from github.com and gerrithub to
openstack gerrit, and R
Good idea, but that also made no difference. In any case, I don’t think this
is attempting a direct ssh connection, so I don’t see how setting up a ssh
proxy would make any difference. I tried this as “myself” and also with “sudo
–E bash” with the same result:
$ pip install .
Processing /home/
On 6/12/15 11:37 AM, Mike Bayer wrote:
On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
Hi neutrons,
I'd like to draw your attention to an issue discovered by rally gate job:
http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
I
David,
FYI, I used corkscrew with pypi as well with another .ssh/config line of:
Host pypi.python.org
ProxyCommand corkscrew 80 %h %p
On Fri, Jun 12, 2015 at 11:29 AM KARR, DAVID wrote:
> As I apparently have to sudo this, it would likely be more effective,
> if at all, to specify the
On 2015-06-12 09:04:09 + (+), liuxinguo wrote:
> Recently our CI can not connect to port 29418 of
> review.openstack.org. Following are the failuer
> message, is there anyone know the reasion why our CI can not
> cennect to 29418 of review.openstack.org?
See the several other threads on th
This is exactly what I did in [1].
Cheers,
Armando
[1]
https://review.openstack.org/#/q/status:open+branch:master+topic:neutron-unstable,n,z
On 12 June 2015 at 09:00, Clint Byrum wrote:
> Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700:
> > On Fri, 12 Jun 2015, Joe Gordon wrote
On 06/12/2015 11:41 AM, Sergii Golovatiuk wrote:
> Hi,
>
> I have read all this thread trying to understand what's going on. It has
> many emotions but very few logical proposals. Let me try to sum up and
> make some proposals.
>
> * A bug is reported in both Fuel Library and the Puppet mod
Hi
We have [1] in the db layer and it's directly used by API
layer , the filters is directly from client's input
In this case, when doing [2] or similar changes, do we need to
consider microversion usage when we change options?
Thanks
[1]
https://github.com/
Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700:
> On Fri, 12 Jun 2015, Joe Gordon wrote:
>
> > Glad to see us catch these issues early.
>
> Yes! CI is doing exactly the job it is supposed to be doing here. It
> is finding bugs in code. When that happens we should fix the bugs,
>
Dulko, Michal wrote:
Hi,
In Cinder we had merged a complicated piece of code[1] to be able to
return something from flow that was reverted. Basically outside we
needed an information if volume was rescheduled or not. Right now this
is done by injecting information needed into exception thrown fr
Hi,
I have read all this thread trying to understand what's going on. It has
many emotions but very few logical proposals. Let me try to sum up and make
some proposals.
* A bug is reported in both Fuel Library and the Puppet module having
> trouble. A patch is provided in Fuel Library (your fork
Hi, everyone,
as we are heading to Fuel 6.1 release, we went through 6.1 Hard Code
Freeze milestone and created stable/6.1 branch in stackforge/fuel-*
repositories [1]
>From now on our master branch (which is a future 7.0) is open for new
features and we've enabled nightly builds for it.
You can
On 6/12/15 6:42 AM, Sean Dague wrote:
On 06/12/2015 06:31 AM, Joe Gordon wrote:
On Fri, Jun 12, 2015 at 7:13 PM, Sean Dague mailto:s...@dague.net>> wrote:
On 06/12/2015 01:17 AM, Salvatore Orlando wrote:
> It is however interesting that both "lock wait timeouts" and "missing
>
On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
Hi neutrons,
I'd like to draw your attention to an issue discovered by rally gate job:
http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
I don't have bandwidth to take a deep look
On Thu, May 28, 2015 at 12:55:50PM -0700, Jim Rollenhagen wrote:
> [snip]
>
> I also put an informational spec about this change up in the
> ironic-specs repo: https://review.openstack.org/#/c/185171/. My goal was
> to discuss this in the spec, but the mailing list is fine too. There are
> some un
Hello TC members and fellow stackers,
The `os-ansible-deployment`[0] project has submitted a review to to change the
Governance of the project[1]. Our community of developers and deployers have
discussed the move at length, in IRC/meetings and on etherpad[2], and believe
that
we're ready to be
On Fri, 2015-06-12 at 02:43 -0700, Dmitry Borodaenko wrote:
> On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
> > What about code history and respect of commit ownership?
> > I'm personally wondering if it's fair to copy/paste several thousands of
> > lines of code from another Open
As I apparently have to sudo this, it would likely be more effective, if at
all, to specify the proxy on the command line. Unfortunately, it didn’t make
any difference:
# pip install --proxy "https://one.proxy.att.com:8080"; .
Processing /home/dk068x/work/git-review
Complete output from comm
On Thu, Jun 11, 2015, Salvatore Orlando wrote:
> Finally, I received queries from several community members that would be keen
> on helping supporting this microversioning effort. I wonder if the PTL and the
> API lieutenants would ok with agreeing to have a team of developers meeting
> regularly,
Adiran,
Disagree.
The python-magnumclient and heat-coe-templates have separate launchpad
trackers. I suspect we will want a separate tracker for python-k8sclient when
we are ready for that.
IMO each repo should have a separate launchpad tracker to make the lives of the
folks maintaining the
Hi,
In Cinder we had merged a complicated piece of code[1] to be able to return
something from flow that was reverted. Basically outside we needed an
information if volume was rescheduled or not. Right now this is done by
injecting information needed into exception thrown from the flow. Another
-1. You are correct in that it is allowed in free source, and done in practice.
There has to be a very good reason for it for it though. It feels like you are
using the nuclear option when there are other ways to solve the problem that
are more friendly to the attribution of the authors. One of
Steve,
There is no need for a second LP project at all.
Adrian
Original message
From: "Steven Dake (stdake)"
Date: 06/12/2015 7:41 AM (GMT-08:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [magnum][horizon] Making a dashb
Brad,
Each repo should have a separate launchpad tracker. I reconfigured the
magnum-ui launchpad tracker with the liberty series and the liberty milestones.
This is common best practice in OpenStack governance. I recommend a common
drivers team however, which should be magnum-drivers.
Regar
Adrian,
Great thanks for that. I would recommend one change and that is for one
magnum-drivers team across launchpad trackers. The magnum-drivers team as you
know (this is for the benefit of others) is responsible for maintaining the
states of the launchpad trackers.
Regards,
-steve
From: A
The kolla-drivers team in launchpad is a restricted team because people can
damage the issue tracker and cause a bunch of work on my end to fix. That
said, I’m going to open up the kolla-drivers launchpad team to a wider group of
any individual involved in Kolla. This is different from the cor
On 06/12/2015 07:58 AM, Bogdan Dobrelya wrote:
>> Hi,
>>
>> Before you read me, please remember I know almost nothing about puppet. :)
>>
>> On 06/11/2015 11:03 PM, Matt Fischer wrote:
>>
>> Matt,
>>
>> I appreciate a lot who you are, and all the help you've given me so far,
>> but what you are a
On 06/12/2015 08:29 AM, Flavio Percoco wrote:
> On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote:
>> On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote:
>>> On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
>>> >Secondly, I'd like to point out that Fuel is not so different from
>>> >wh
On 06/12/2015 05:43 AM, Dmitry Borodaenko wrote:
> On Thu, Jun 11, 2015 at 11:43:09PM -0400, Emilien Macchi wrote:
>> What about code history and respect of commit ownership?
>> I'm personally wondering if it's fair to copy/paste several thousands of
>> lines of code from another Open-Source proj
Folks
As Dmitry already said, we are open towards merging with upstream and would
like to make our code divergence no more than several percents of lines,
but there are historical reasons for this divergence with which we are not
happy either. So let's just point out that both sides look into the
Hi,
Since we reopened the review for this blueprint we've got a large number of
comments. It can be clearly seen that the original proposal has to be changed,
although it still requires some discussion to define a reasonable design that
provides the desired feature and is aligned with the archi
Even though 7am is not ideal for the west coast, I¹d be willing to go back
that far. That would put the meeting at the morning school rush for the
west coast folks though (although we are in summer break in the US and we
could renegotiate a time in 3 months when school starts up again if its a
pro
Le 12/06/2015 15:27, Matt Van Winkle a écrit :
On 6/12/15 7:46 AM, "Andrew Laski" wrote:
On 06/11/15 at 06:54pm, Ian Wells wrote:
On 11 June 2015 at 12:37, Richard Raseley wrote:
Andrew Laski wrote:
There are many reasons a deployer may want to live-migrate instances
around: capacity
Daniel P. Berrange wrote:
> On Tue, Jun 09, 2015 at 07:52:39PM +0300, Roman Bogorodskiy wrote:
> > Hi,
> >
> > Few months ago I've started a discussion on FreeBSD host support for
> > OpenStack. [1] At a result of discussion it was figured out that there
> > are a number of limitations, mainly
On 6/12/15 7:46 AM, "Andrew Laski" wrote:
>On 06/11/15 at 06:54pm, Ian Wells wrote:
>>On 11 June 2015 at 12:37, Richard Raseley wrote:
>>
>>> Andrew Laski wrote:
>>>
There are many reasons a deployer may want to live-migrate instances
around: capacity planning, security patching, noi
On 06/11/15 at 06:54pm, Ian Wells wrote:
On 11 June 2015 at 12:37, Richard Raseley wrote:
Andrew Laski wrote:
There are many reasons a deployer may want to live-migrate instances
around: capacity planning, security patching, noisy neighbors, host
maintenance, etc... and I just don't think th
> But I still need to
> figure out more details about device renaming and what other side
> effects might come with it.
Device renaming might not be a good idea in the macvtap context, as the
interface used could also be used with by other applications that might
insist on a fixed device name. It
Hi David,
Ok, sudo python setup.py install without pbr install is not working behind
an http proxy.
Because you should use sudo -E python setup.py install to pass
http(s)_proxy ernv variables.
But even if you do so python setup.py install will try to install pbr
WITHOUT taking into account proxy
On 12/06/15 03:04 -0700, Dmitry Borodaenko wrote:
On Fri, Jun 12, 2015 at 09:31:45AM +0200, Flavio Percoco wrote:
On 11/06/15 17:36 +0300, Matthew Mosesohn wrote:
>Secondly, I'd like to point out that Fuel is not so different from
>what other teams are doing. At the Summit, I heard from others w
On 12/06/15 03:28 -0700, Dmitry Borodaenko wrote:
On Fri, Jun 12, 2015 at 09:24:33AM +0200, Flavio Percoco wrote:
I'm sure you both, and the Fuel team, are acting on good faith but I
believe, in this case, there's no problem that makes copy/pasting
code, and therefore loosing commits attribution
1 - 100 of 136 matches
Mail list logo
