On 07/17/2018 06:57 AM, Udi Kalifon wrote:
> We should also add support for the openstack client to launch the other
> validators that are used in the GUI. There are validators for the
> overcloud as well, and new validators are added all the time.
>
> These validators are installed under
>
Hi,
I am trying to get Guru Meditation Report from NEUTRON child process. I have
tried below scenarios. GMR was generated only for the parent process in all the
cases.
1. Kill -SIGUSR2
2. Kill -SIGUSR2
How can I get GMR for a child process. I assumed option 1 would give GMR for
Hi
Dear Stackers,
In order to let operators properly validate their undercloud node, I
propose to create a new subcommand in the "openstack undercloud" "tree":
`openstack undercloud validate'
This should only run the different validations we have in the
undercloud_preflight.py
That way, an
We should also add support for the openstack client to launch the other
validators that are used in the GUI. There are validators for the overcloud
as well, and new validators are added all the time.
These validators are installed under
/usr/share/openstack-tripleo-validations/validations/ and
But I want to create a volume backed server for data processing scenarios,maybe
the BlockDeviceDriver is more suitable.
-- Original --
From: "Sean McGinnis";
Date: 2018年7月16日(星期一) 晚上9:32
To: "OpenStack Developmen";
Subject: Re: [openstack-dev] [cinder] about
Thanks everyone for the feedback, I've made a quick PoC:
https://review.openstack.org/#/q/topic:bp/undercloud-pacemaker-default
And I'm currently doing local testing. I'll publish results when progress
is made, but I've made it so we have the choice to enable pacemaker
(disabled by default),
Hi,
There were total of 6 new bugs reported. I guess everyone was busy following
soccer finals, so not a huge amount of bugs I see were
Reported. The only Bug which I marked High priority was a documentation, which
lacked the information about allowed dscp marking
Values.
High Priority
1.
Hello Vamsikrishna.
Carbon snapshot hasn't been build any more and not available from opendaylight
nexus server.
But the carbon job tried to get carbon snapshot and filed.
So the fix is to use latest(and final?) carbon release(carbon SR4) instead of
carbon snapshot.
Maybe you'd like to twist
On 18-07-16 13:12:32, Kendall Nelson wrote:
> Hey Tony :)
>
> So I think the best way to deal with it would to disable bug reporting for
> requirements in LP (so nothing new can get filed there and the index won't
> be discoverable but you can still edit the old bugs) and then to do
> periodic
Hey Tony :)
So I think the best way to deal with it would to disable bug reporting for
requirements in LP (so nothing new can get filed there and the index won't
be discoverable but you can still edit the old bugs) and then to do
periodic runs of the migration script to pick up any changes that
On Mon, Jul 16, 2018 at 11:48:51AM -0400, Emilien Macchi wrote:
> On Mon, Jul 16, 2018 at 11:42 AM Dan Prince wrote:
> [...]
>
> > The biggest downside IMO is the fact that our Pacemaker integration is
> > not containerized. Nor are there any plans to finish the
> > containerization of it.
On Mon, Jul 16, 2018 at 11:42 AM Dan Prince wrote:
[...]
> The biggest downside IMO is the fact that our Pacemaker integration is
> not containerized. Nor are there any plans to finish the
> containerization of it. Pacemaker has to currently run on baremetal
> and this makes the installation of
Jimmy McArthur wrote:
Akihiro Motoki wrote:
Jimmy,
Does it mean translation **publishing** is ready now?
In the first translation of the edge computing whitepaper,
translation publishing was completely a manual process and it takes
too long.
The initial version was a volunteer effort,
Akihiro Motoki wrote:
Jimmy,
Does it mean translation **publishing** is ready now?
In the first translation of the edge computing whitepaper, translation
publishing was completely a manual process and it takes too long.
The initial version was a volunteer effort, but the Foundation wasn't
On Fri, Jul 13, 2018 at 2:34 PM Emilien Macchi wrote:
>
> Greetings,
>
> We have been supporting both Keepalived and Pacemaker to handle VIP
> management.
> Keepalived is actually the tool used by the undercloud when SSL is enabled
> (for SSL termination).
> While Pacemaker is used on the
Jimmy,
Does it mean translation **publishing** is ready now?
In the first translation of the edge computing whitepaper, translation
publishing was completely a manual process and it takes too long.
If translation publishing support is not ready, it is a bit discouraging
from translator
On Mon, Jul 16, 2018 at 11:27 AM Cédric Jeanneret wrote:
>
> Dear Stackers,
>
> In order to let operators properly validate their undercloud node, I
> propose to create a new subcommand in the "openstack undercloud" "tree":
> `openstack undercloud validate'
>
> This should only run the different
Dear Stackers,
In order to let operators properly validate their undercloud node, I
propose to create a new subcommand in the "openstack undercloud" "tree":
`openstack undercloud validate'
This should only run the different validations we have in the
undercloud_preflight.py¹
That way, an
Sorry, I should have also added... we additionally need permissions so
that we can add the a new version of the pot file to this project:
https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835
Thanks!
Jimmy
Jimmy McArthur wrote:
Hi all -
We have both of the
Hi all -
We have both of the current whitepapers up and available for
translation. Can we promote these on the Zanata homepage?
https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684
Hello Charmers,
A etherpad for planning of the upcoming PTG in Denver has been created [0].
Please make a note signalling your attendance and any topics you want
covered.
0: https://etherpad.openstack.org/p/charms-stein-ptg
--
Frode Nordahl
+Isaku
Hi Isaku,
I found the reason for the build failure. below path it should be
distribution-artifacts instead of distribution-karaf
https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/org/opendaylight/integration/distribution-karaf/-SNAPSHOT/maven-metadata.xml
Line
On 07/16/2018 10:15 AM, arkady.kanev...@dell.com wrote:
Is this for ephemeral storage handling?
For both ephemeral as well as root disk.
In other words, just act like Cinder isn't there and attach a big local
root disk to the instance.
Best,
-jay
-Original Message-
From: Jay
Is this for ephemeral storage handling?
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, July 16, 2018 8:44 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [cinder] about block device driver
On 07/16/2018 09:32 AM, Sean McGinnis wrote:
>
Hi all,
Here's a testing and documentation bug that would be great for newcomers
to the placement project:
https://bugs.launchpad.net/nova/+bug/1781439
Come find us on #openstack-placement on Freenode IRC to chat about it if
you're interested!
Best,
-jay
On 07/16/2018 09:32 AM, Sean McGinnis wrote:
The other option would be to not use Cinder volumes so you just use local
storage on your compute nodes.
^^ yes, this.
-jay
__
OpenStack Development Mailing List (not for
On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote:
> On 16/07, Rambo wrote:
> > Well,in my opinion,the BlockDeviceDriver is more suitable than any other
> > solution for data processing scenarios.Does the community will agree to
> > merge the BlockDeviceDriver to the Cinder
Hi Emilien,
On Fri, Jul 13, 2018 at 02:33:02PM -0400, Emilien Macchi wrote:
> We have been supporting both Keepalived and Pacemaker to handle VIP
> management. Keepalived is actually the tool used by the undercloud
> when SSL is enabled (for SSL termination). While Pacemaker is used on
> the
This is placement update 18-28, a weekly update of ongoing development
related to the [OpenStack](https://www.openstack.org/) [placement
service](https://developer.openstack.org/api-ref/placement/).
This week I'm trying to fill Chris' esteemable shoes while he's away.
# Most Important
##
I'm all for it!
Another benefit is better coverage for the standalone CI job(s), when it
will (hopefully) become a mandatory dependency for overcloud multinode
jobs.
On 7/16/18 12:49 PM, Sergii Golovatiuk wrote:
Hi,
On Fri, Jul 13, 2018 at 9:11 PM, Juan Antonio Osorio
wrote:
Sounds good
Hi All,
Builds are failing in Stable/pike in networking-odl on below review:
https://review.openstack.org/#/c/582745/
looks that issue is here:
http://logs.openstack.org/45/582745/5/check/networking-odl-rally-dsvm-carbon-snapshot/be4abe3/logs/devstacklog.txt.gz#_2018-07-15_18_23_41_854
There is
ok,thank you
--原始邮件--
发件人："Gorka Eguileor ";
发送时间：2018年7月16日(星期一) 晚上7:32
收件人："OpenStack Developmen" ;
主题：Re: [openstack-dev] [cinder] about block device driver
---
On 16/07, Rambo wrote:
> Well,in my opinion,the BlockDeviceDriver is more
On Fri, 2018-07-13 at 15:23 -0500, Matt Riedemann wrote:
> There are currently no open changes for the nova-network API removal
> tracked here [1] but there are at least two low-hanging fruit APIs to
> remove:
>
> * os-floating-ips-bulk
> * os-floating-ips-dns
The two of these are done now.
On Sun, Jul 15, 2018 at 7:50 PM, Samuel Monderer
wrote:
>
> Hi Remo,
>
> Attached are templates I used for the deployment. They are based on a
> deployment we did with OSP11.
> I made the changes for it to work with OSP13.
>
> I do think it's the roles_data.yaml file that is causing the error
On 16/07, Rambo wrote:
> Well,in my opinion,the BlockDeviceDriver is more suitable than any other
> solution for data processing scenarios.Does the community will agree to merge
> the BlockDeviceDriver to the Cinder repository again if our company hold the
> maintainer and CI?
>
Hi,
I'm sure
Hi Sergey,
We are using Kolla Ansible with monasca log API, and have added support for
customising the fluentd configuration [1][2]. Doug Szumski (dougsz) made
some changes in Queens to try to standardise the log message format. I
think Kolla Ansible would benefit from some better documentation
On 07/16/2018 12:18 PM, Sergii Golovatiuk wrote:
> Hi,
>
> On Thu, Jul 12, 2018 at 4:45 PM, Cédric Jeanneret wrote:
>> Dear Stackers,
>>
>> I'm currently looking for some inputs in order to get a new validation,
>> ran as a "preflight check" on the undercloud.
>>
>> The aim is to ensure we
Hi,
On Thu, Jul 12, 2018 at 4:45 PM, Cédric Jeanneret wrote:
> Dear Stackers,
>
> I'm currently looking for some inputs in order to get a new validation,
> ran as a "preflight check" on the undercloud.
>
> The aim is to ensure we actually have enough disk space for all the
> files and, most
Well,in my opinion,the BlockDeviceDriver is more suitable than any other
solution for data processing scenarios.Does the community will agree to merge
the BlockDeviceDriver to the Cinder repository again if our company hold the
maintainer and CI?
-- Original
Hi,
On Fri, Jul 13, 2018 at 9:11 PM, Juan Antonio Osorio
wrote:
> Sounds good to me. Even if pacemaker is heavier, less options and
> consistency is better.
>
> Greetings from Mexico :D
Greetings from Poznań :D
>
> On Fri, 13 Jul 2018, 13:33 Emilien Macchi, wrote:
>>
>> Greetings,
>>
>> We
On 06/07, Amy Marrich wrote:
> Hey,
>
> Forwarding to the Dev list as you may get a better response from there.
>
> Thanks,
>
> Amy (spotz)
>
Hi,
I included a good number of improvements regarding bottlenecks on the
backup service in recent releases, some of them are automatic, and
others need
On 16/07, Rambo wrote:
> Hi,all
>
>
> In the Cinder repository, I noticed that the BlockDeviceDriver driver is
> being deprecated, and was eventually be removed with the Queens release.
>
>
> https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/block_device.py
>
>
> In
Hi,all
In the Cinder repository, I noticed that the BlockDeviceDriver driver is
being deprecated, and was eventually be removed with the Queens release.
https://github.com/openstack/cinder/blob/stable/ocata/cinder/volume/drivers/block_device.py
In my use case, the instances using
On Fri, Jul 13, 2018, at 9:19 PM, Lance Bragstad wrote:
> Hey all,
>
> As noted in the weekly report [0], today is feature freeze for
> keystone-related specifications. I wanted to elaborate on each
> specification so that our plan is clear moving forward.
>
> *Unified Limits**
> **
> *I propose
44 matches
Mail list logo
