date:20170925

Adhi,

I'm happy to know that you've resolved the Rrd_interface.Internal_error.

 By checking the logs you posted, the errors are all relative to measurements 
which are not implemented yet for XenServer. See the supporting matrix: 
https://docs.openstack.org/ceilometer/latest/admin/telemetry-measurements.html
 We're evaluating adding support for these measurements and put that in the 
development plan.
 In recent releases, upstream has been changed to log it as error for the 
unimplemented measurements. That doesn’t make sense indeed.

Regards,
Jianghua
--
Date: Mon, 25 Sep 2017 14:51:46 +0700
From: Adhi Priharmanto 
To: Jianghua Wang 
Cc: "openstack@lists.openstack.org" 
Subject: Re: [Openstack] FW: [xenserver-ocata] ceilometer compute
error   Rrd_interface.Internal_error

Hi Jianghua,

Thanks for your response and attention. For the error of  "
Rrd_interface.Internal_error" , I was installed this update on my xenserver
(https://support.citrix.com/article/CTX225676) , and RRD error now was gone 
from ceilometer logs.

I'm still at ocata release , here is my openstack package list on my compute 
node

> [root@cmp1-oc-srg ceilometer]# rpm -qa |grep openstack 
> centos-release-openstack-ocata-1-1.el7.noarch
> openstack-selinux-0.7.13-2.el7.noarch
> openstack-nova-compute-15.0.0-1.el7.noarch
> openstack-neutron-common-10.0.1-1.el7.noarch
> openstack-ceilometer-polling-8.1.0-1.el7.noarch
> openstack-ceilometer-compute-8.1.0-1.el7.noarch
> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
> openstack-neutron-ml2-10.0.1-1.el7.noarch
> openstack-ceilometer-common-8.1.0-1.el7.noarch
> openstack-nova-common-15.0.0-1.el7.noarch
> openstack-neutron-10.0.1-1.el7.noarch


And here's is my logs as your request
https://paste.fedoraproject.org/paste/Yv8DoGbLziE0~luY6qwbhQ

I still find error at ceilometer-compute logs like this one

2017-09-25 14:31:07.041 9048 INFO ceilometer.agent.manager [-] Polling
> pollster disk.device.iops in the context of all_pollsters
> 2017-09-25 14:31:07.042 9048 ERROR ceilometer.agent.manager [-] 
> Prevent pollster disk.device.iops from polling [,  mon-srg>, ] on source all_pollsters anymore!
> 2017-09-25 14:31:07.043 9048 INFO ceilometer.agent.manager [-] Polling 
> pollster disk.device.latency in the context of all_pollsters
> 2017-09-25 14:31:07.044 9048 ERROR ceilometer.agent.manager [-] 
> Prevent pollster disk.device.latency from polling [, 
>  mon-srg>, ] on source all_pollsters anymore!


I think this error maybe make some of measurement won't works at gnocchi, and 
also some of gnocchi metric won't show the unit

[root@localhost ~]# gnocchi metric list |grep disk.device.iops
>
> +---+-+-+---++
> | id| archive_policy/name | name
>  | unit  | resource_id|
>
> +---+-+-+---++
>
>> | 0062d222-2874-4a19-be34-a5bee3051d21 | low |
>> disk.device.iops| None  |
>> 7b089e8e-5be7-599a-b279-15a8129f7bdd |
>
> | 3dc249e4-006d-47a3-935c-58e571ba086c | low |
>> disk.device.iops| None  |
>> 0efeccca-8313-5aec-a1e2-955e091419f9 |
>
> | c2c19329-1709-4165-bdea-3bcf81c5d9d4 | low |
>> disk.device.iops| None  |
>> 78aa9c1e-b199-551c-b295-fecb237639fc |
>
> | cfa1c4bf-591e-4229-bb76-7607fcba640e | low |
>> disk.device.iops| None  |
>> bdf98233-442b-5fe4-aa02-ba567e487dcc |
>
>

Any suggest about the last error of ceilometer-compute  ?

On Mon, Sep 25, 2017 at 1:02 PM, Jianghua Wang 
wrote:

> Adhi,
>
>   Do you still have this problem?
>
>   The following errors may be caused due to this xvda disk doesn’t exist.
> Did you see any issue from the nova?
>
> Rrd.Invalid_data_source(\\"vbd_xvda_read\\")")
>
>
>
> If you are still suffering from this issue, can you send me the 
> following log files:
>
> 1.   Log files for the nova-compute and ceilometer services located
> in nova compute node.
>
> 2.   The /var/log/xensource.log from dom0 where the compute node is
> running on.
>
>
>
> And can you confirm the release version? From the title – 
> [xenserver-ocata], it may be ocata. But by checking the code line from 
> the log, it’s probably already in pike.
>
>
>
> Regards,
>
> Jianghua

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Recall: [xenserver-ocata] ceilometer compute

Jianghua Wang would like to recall the message, "[Openstack] [xenserver-ocata] 
ceilometer compute".
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [xenserver-ocata] ceilometer compute error Rrd_interface.Internal_error

Adhi,

I'm happy to know that you've resolved the Rrd_interface.Internal_error.

 By checking the logs you posted, the errors are all relative to measurements 
which are not implemented yet for XenServer. See the supporting matrix: 
https://docs.openstack.org/ceilometer/latest/admin/telemetry-measurements.html
 We're evaluating adding support for these measurements and put that in the 
development plan.
 In recent releases, upstream has been changed to log it as error for the 
unimplemented measurements. That doesn’t make sense indeed.

Regards,
Jianghua
--
Date: Mon, 25 Sep 2017 14:51:46 +0700
From: Adhi Priharmanto 
To: Jianghua Wang 
Cc: "openstack@lists.openstack.org" 
Subject: Re: [Openstack] FW: [xenserver-ocata] ceilometer compute
error   Rrd_interface.Internal_error

Hi Jianghua,

Thanks for your response and attention. For the error of  "
Rrd_interface.Internal_error" , I was installed this update on my xenserver
(https://support.citrix.com/article/CTX225676) , and RRD error now was gone 
from ceilometer logs.

I'm still at ocata release , here is my openstack package list on my compute 
node

> [root@cmp1-oc-srg ceilometer]# rpm -qa |grep openstack 
> centos-release-openstack-ocata-1-1.el7.noarch
> openstack-selinux-0.7.13-2.el7.noarch
> openstack-nova-compute-15.0.0-1.el7.noarch
> openstack-neutron-common-10.0.1-1.el7.noarch
> openstack-ceilometer-polling-8.1.0-1.el7.noarch
> openstack-ceilometer-compute-8.1.0-1.el7.noarch
> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
> openstack-neutron-ml2-10.0.1-1.el7.noarch
> openstack-ceilometer-common-8.1.0-1.el7.noarch
> openstack-nova-common-15.0.0-1.el7.noarch
> openstack-neutron-10.0.1-1.el7.noarch


And here's is my logs as your request
https://paste.fedoraproject.org/paste/Yv8DoGbLziE0~luY6qwbhQ

I still find error at ceilometer-compute logs like this one

2017-09-25 14:31:07.041 9048 INFO ceilometer.agent.manager [-] Polling
> pollster disk.device.iops in the context of all_pollsters
> 2017-09-25 14:31:07.042 9048 ERROR ceilometer.agent.manager [-] 
> Prevent pollster disk.device.iops from polling [,  mon-srg>, ] on source all_pollsters anymore!
> 2017-09-25 14:31:07.043 9048 INFO ceilometer.agent.manager [-] Polling 
> pollster disk.device.latency in the context of all_pollsters
> 2017-09-25 14:31:07.044 9048 ERROR ceilometer.agent.manager [-] 
> Prevent pollster disk.device.latency from polling [, 
>  mon-srg>, ] on source all_pollsters anymore!


I think this error maybe make some of measurement won't works at gnocchi, and 
also some of gnocchi metric won't show the unit

[root@localhost ~]# gnocchi metric list |grep disk.device.iops
>
> +---+-+-+---++
> | id| archive_policy/name | name
>  | unit  | resource_id|
>
> +---+-+-+---++
>
>> | 0062d222-2874-4a19-be34-a5bee3051d21 | low |
>> disk.device.iops| None  |
>> 7b089e8e-5be7-599a-b279-15a8129f7bdd |
>
> | 3dc249e4-006d-47a3-935c-58e571ba086c | low |
>> disk.device.iops| None  |
>> 0efeccca-8313-5aec-a1e2-955e091419f9 |
>
> | c2c19329-1709-4165-bdea-3bcf81c5d9d4 | low |
>> disk.device.iops| None  |
>> 78aa9c1e-b199-551c-b295-fecb237639fc |
>
> | cfa1c4bf-591e-4229-bb76-7607fcba640e | low |
>> disk.device.iops| None  |
>> bdf98233-442b-5fe4-aa02-ba567e487dcc |
>
>

Any suggest about the last error of ceilometer-compute  ?

On Mon, Sep 25, 2017 at 1:02 PM, Jianghua Wang 
wrote:

> Adhi,
>
>   Do you still have this problem?
>
>   The following errors may be caused due to this xvda disk doesn’t exist.
> Did you see any issue from the nova?
>
> Rrd.Invalid_data_source(\\"vbd_xvda_read\\")")
>
>
>
> If you are still suffering from this issue, can you send me the 
> following log files:
>
> 1.   Log files for the nova-compute and ceilometer services located
> in nova compute node.
>
> 2.   The /var/log/xensource.log from dom0 where the compute node is
> running on.
>
>
>
> And can you confirm the release version? From the title – 
> [xenserver-ocata], it may be ocata. But by checking the code line from 
> the log, it’s probably already in pike.
>
>
>
> Regards,
>
> Jianghua

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session

2017-09-25 Thread Dan Prince

On Thu, Sep 21, 2017 at 8:53 AM, Jiří Stránský  wrote:

> On 21.9.2017 12:31, Giulio Fidente wrote:
>
>> On 09/20/2017 07:36 PM, James Slagle wrote:
>>
>>> On Tue, Sep 19, 2017 at 8:37 AM, Giulio Fidente 
>>> wrote:
>>>
 On 09/18/2017 05:37 PM, James Slagle wrote:

> - The entire sequence and flow is driven via Mistral on the Undercloud
> by default. This preserves the API layer and provides a clean reusable
> interface for the CLI and GUI.
>

 I think it's worth saying that we want to move the deployment steps out
 of heat and in ansible, not in mistral so that mistral will run the
 workflow only once and let ansible go through the steps

 I think having the steps in mistral would be a nice option to be able to
 rerun easily a particular deployment step from the GUI, versus having
 them in ansible which is instead a better option for CLI users ... but
 it looks like having them in ansible is the only option which permits us
 to reuse the same code to deploy an undercloud because having the steps
 in mistral would require the undercloud installation itself to depend on
 mistral which we don't want to

 James, Dan, please comment on the above if I am wrong

>>>
>>> That's correct. We don't want to require Mistral to install the
>>> Undercloud. However, I don't think that necessarily means it has to be
>>> a single call to ansible-playbook. We could have multiple invocations
>>> of ansible-playbook. Both Mistral and CLI code for installing the
>>> undercloud could handle that easily.
>>>
>>> You wouldn't be able to interleave an external playbook among the
>>> deploy steps however. That would have to be done under a single call
>>> to ansible-playbook (at least how that is written now). We could
>>> however have hooks that could serve as integration points to call
>>> external playbooks after each step.
>>>
>>
>> the benefits of driving the steps from mistral are that then we could
>> also interleave the deployment steps and we won't need the
>> ansible-playbook hook for the "external" services:
>>
>> 1) collect the ansible tasks *and* the workflow_tasks (per step) from heat
>>
>> 2) launch the stepN deployment workflow (ansible-playbook)
>>
>> 3) execute any workflow_task defined for stepN (like ceph-ansible
>> playbook)
>>
>> 4) repeat 2 and 3 for stepN+1
>>
>> I think this would also provide a nice interface for the UI ... but then
>> we'd need mistral to be able to deploy the undercloud
>>
>>
> Alternatively we could do the main step loop in Ansible directly, and have
> the tasks do whatever they need to get the particular service deployed,
> from  to launching a nested ansible-playbook run if that's what it takes.
>
> That way we could run the whole thing end-to-end via ansible-playbook, or
> if needed one could execute smaller bits by themselves (steps or nested
> playbook runs) -- that capability is not baked in by default, but i think
> we could make it so.
>

This was the idea that had the most traction at the PTG when we discussed
it. Things can still be interleaved across the installers (stepwise) but we
effectively eliminate the complexity of having multiple tools involved
within the main deploy step loop as you described it.

I think we should consider making it so that the main Ansible loop can call
any external installer in a stepwise fashion though. It doesn't have to be
just Ansible it calls. In this manner we would be supporting calling into
multiple phases of an external installer.

During the undercloud deployment we get all the benefits of Ansible driving
our primary deployment loop and can still call into external installers
like Kubernetes if we want to. On the overcloud we'd still be leveraging
the high level Mistral workflow to kick off the initial Ansible
playbooks... but once that happens it would be Ansible driving any external
installers directly.

Dan


>
> Also the interface for services would be clean and simple -- it's always
> the ansible tasks.
>
> And Mistral-less use cases become easier to handle too (= undercloud
> installation when Mistral isn't present yet, or development envs when you
> want to tune the playbook directly without being forced to go through
> Mistral).
>
> Logging becomes a bit more unwieldy in this scenario though, as for the
> nested ansible-playbook execution, all output would go into a task in the
> outer playbook, which would be harder to follow and the log of the outer
> playbook could be huge.
>
> So this solution is no silver bullet, but from my current point of view it
> seems a bit less conceptually foreign than using Mistral to provide step
> loop functionality to Ansible, which should be able to handle that on its
> own.
>
>
> - It would still be possible to run ansible-playbook directly for
> various use cases (dev/test/POC/demos). This preserves the quick
> iteration via Ansible that is often desired.
>

Re: [openstack-dev] [ptg] Simplification in OpenStack

2017-09-25 Thread Samuel Cassiba


> On Sep 25, 2017, at 16:52, Clint Byrum  wrote:
> 
> Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
>> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
>> 
>> :Lastly, I do think GUI's make deployments easier and because of that, I
>> :feel they're critical. There is more than one vendor whose built and
>> :distributes a free GUI to ease OpenStack deployment and management. That's
>> :a good start but those are the opinions of a specific vendor - not he OS
>> :community. I have always been a big believer in a default cloud
>> :configuration to ease the shock of having so many options for everything. I
>> :have a feeling however our commercial community will struggle with
>> :accepting any method/project other than their own as being part a default
>> :config. That will be a tough one to crack.
>> 
>> Different people have differnt needs, so this is not meant to
>> contradict Adam.
>> 
>> But :)
>> 
>> Any unique deployment tool would be of no value to me as OpenStack (or
>> anyother infrastructure component) needs to fit into my environment.
>> I'm not going to adopt something new that requires a new parallel
>> management tool to what I use.
>> 
> 
> You already have that if you run OpenStack.
> 
> The majority of development testing and gate testing happens via
> Devstack. A parallel management tool to what most people use to actually
> operate OpenStack.
> 
>> I think focusing on the existing configuration management projects it
>> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
>> know set of "constellations" in an opinionated would make deployment
>> easy (for most people who are using one of those already) and ,
>> ussuming the opionions are the same :) make consumption easier as
>> well.
>> 
>> As an example when I started using OpenStack (Essex) we  had recently
>> switch to Ubuntu as our Linux platform and Pupept as our config
>> management. Ubuntu had a "one click MAAS install of OpenStack" which
>> was impossible as it made all sorts of assumptions about our
>> environment and wanted controll of most of them so it could provide a
>> full deployemnt solution.  Puppet had a good integrated example config
>> where I plugged in some local choices and and used existing deploy
>> methodologies.
>> 
>> I fought with MAAS's "simple" install for a week.  When I gave up and
>> went with Puppet I had live users on a substantial (for the time)
>> cloud in less htan 2 days.
>> 
>> I don't think this has to do with the relative value of MASS and
>> Puppet at the time, but rather what fit my existing deploy workflows.
>> 
>> Supporting multiple config tools may not be simple from an upstream
>> perspective, but we do already have these projects and it is simpler
>> to consume for brown field deployers at least.
>> 
> 
> I don't think anybody is saying we would slam the door in the face of
> people who use any one set of tools.
> 
> But rather, we'd start promoting and using a single solution for the bulk
> of community efforts. Right now we do that with devstack as a reference
> implementation that nobody should use for anything but dev/test. But
> it would seem like a good idea for us to promote a tool for going live
> as well.

Except by that very statement, you slam the door in the face of tons of existing
knowledge within organizations. This slope has a sheer face.

Promoting a single solution would do as much harm as it would good, for all it’s
worth. In such a scenario, the most advocated method would become the only
understood method, in spite of all other deployment efforts. Each project that
did not have the most mindshare would become more irrelevant than they are now
and further slip into decay. For those that did not have the fortune or
foresight to land on this hypothetical winning side, what for their efforts,
evolve or gtfo?

I'm not saying Fuel or Salt or Chef or Puppet or Ansible needs to be the
'winner', because there isn't a competition, at least in my opinion. The way I
see it, we're all working to get to the same place. Our downstream consumers
don’t really care how that happens in the grand scheme, only that it does.

> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack][Cinder][third-party][ci] Tintri Cinder CI failure

2017-09-25 Thread Apoorva Deshpande

Hello,

Tintri's Cinder CI started failing around Sept 19, 2017. There are 29 tests
failing[1] with following errors [2][3][4]. Tintri Cinder driver inherit
nfs cinder driver and it's available here[5].

Please let me know if anyone has recently seen these failures or has any
pointers on how to fix.

Thanks,
Apoorva

IRC: Apoorva

[1]
http://openstack-ci.tintri.com/tintri/refs-changes-57-505357-1/testr_results.html
[2] http://paste.openstack.org/show/621886/
[3] http://paste.openstack.org/show/621858/
[4] http://paste.openstack.org/show/621857/
[5]
https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/tintri.py
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

2017-09-25 Thread Clint Byrum

Excerpts from Jonathan D. Proulx's message of 2017-09-25 11:18:51 -0400:
> On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:
> 
> :Lastly, I do think GUI's make deployments easier and because of that, I
> :feel they're critical. There is more than one vendor whose built and
> :distributes a free GUI to ease OpenStack deployment and management. That's
> :a good start but those are the opinions of a specific vendor - not he OS
> :community. I have always been a big believer in a default cloud
> :configuration to ease the shock of having so many options for everything. I
> :have a feeling however our commercial community will struggle with
> :accepting any method/project other than their own as being part a default
> :config. That will be a tough one to crack.
> 
> Different people have differnt needs, so this is not meant to
> contradict Adam.
> 
> But :)
> 
> Any unique deployment tool would be of no value to me as OpenStack (or
> anyother infrastructure component) needs to fit into my environment.
> I'm not going to adopt something new that requires a new parallel
> management tool to what I use.
> 

You already have that if you run OpenStack.

The majority of development testing and gate testing happens via
Devstack. A parallel management tool to what most people use to actually
operate OpenStack.

> I think focusing on the existing configuration management projects it
> the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
> know set of "constellations" in an opinionated would make deployment
> easy (for most people who are using one of those already) and ,
> ussuming the opionions are the same :) make consumption easier as
> well.
> 
> As an example when I started using OpenStack (Essex) we  had recently
> switch to Ubuntu as our Linux platform and Pupept as our config
> management. Ubuntu had a "one click MAAS install of OpenStack" which
> was impossible as it made all sorts of assumptions about our
> environment and wanted controll of most of them so it could provide a
> full deployemnt solution.  Puppet had a good integrated example config
> where I plugged in some local choices and and used existing deploy
> methodologies.
> 
> I fought with MAAS's "simple" install for a week.  When I gave up and
> went with Puppet I had live users on a substantial (for the time)
> cloud in less htan 2 days.
> 
> I don't think this has to do with the relative value of MASS and
> Puppet at the time, but rather what fit my existing deploy workflows.
> 
> Supporting multiple config tools may not be simple from an upstream
> perspective, but we do already have these projects and it is simpler
> to consume for brown field deployers at least.
> 

I don't think anybody is saying we would slam the door in the face of
people who use any one set of tools.

But rather, we'd start promoting and using a single solution for the bulk
of community efforts. Right now we do that with devstack as a reference
implementation that nobody should use for anything but dev/test. But
it would seem like a good idea for us to promote a tool for going live
as well.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][infra] Zuul v3 migration update

2017-09-25 Thread James E. Blair

Hi,

We started to migrate to Zuul v3 today, but ran into some problems which
delayed us sufficiently that we're going to suspend activity until
tomorrow.

In the mean time, please consider the project-config repository frozen
to all changes except those which are necessary for the migration.  We
should be able to lift this freeze as soon as we finish the migration.

If you haven't yet, please see [1] for information about the transition.

[1] https://docs.openstack.org/infra/manual/zuulv3.html

Thanks,

Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack] etcd v3.2.0?

2017-09-25 Thread Tony Breeds

On Fri, Jun 16, 2017 at 12:06:47PM +1000, Tony Breeds wrote:
> Hi All,
>   I just push a review [1] to bump the minimum etcd version to
> 3.2.0 which works on intel and ppc64le.  I know we're pretty late in the
> cycle to be making changes like this but releasing pike with a dependacy
> on 3.1.x make it harder for users on ppc64le (not many but a few :D)
> 
> Yours Tony.
> 
> [1] https://review.openstack.org/474825

So this came up at the PTG and the current plan is:

Interim solution:
 1. Get the mirroring tool to the point it can be consumed by infra.
 2. setup a new zuulv3 job to run this and do the mirroring.

Middle term solution:
 1. Get etcd3 packages updated in debian/ubuntu create a PPA (or
similar) for infra to consume.

Both of these are intended to be done during Queens.

Long term plan:
 1. Ensue the packages above are just there for 18.04 so we can put this
behind us.

With hindsight I think we need to add something like "Current packages
can be consumed in our CI" as a requirement for anything added as a base
service.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Yours Tony.

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][release] Last release date vs End of Life date

2017-09-25 Thread Tony Breeds

On Thu, Jun 29, 2017 at 01:34:05PM +0800, ChangBo Guo wrote:
> Thanks tony  for raising up this, better document this in some place :-)

For the record this was just added to the queens schedule [1].  The
deadline is this week but in reality early nest week would probably also
be accepted.

Yours Tony.

[1] https://releases.openstack.org/queens/schedule.html#n-final-library-releases


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack] [Fuel] node name issue

2017-09-25 Thread Jim Okken

hi all,

I am using Fuel 10.

i have 2 nodes I am trying to deploy as compute nodes. at one time in the
past I was attempting to deploy them too. I assume back then their node
names were node-11 and node-20.

they were never successfully deploy and now I've worked out their hardware
issues and are attempting to deploy them again. now Fuel has given them the
names node-80 and node-81.
(i may be at 80 in my node names but I only have 17 nodes so far)

the deploy of these 2 nodes does not get past installing Ubuntu. The nodes
reboot after Ubuntu is installed and come up incorrectly as node-11 and
node-20. After that Fuel sits for a long while and then gives an error
(pasted at the end of email). I assume the nodes come up with the wrong
name/ip/ssh-key and Fuel can't contact them.

I'm a novice at using the fuel and fuel2 cli's but I've tried deleting
these nodes and removing from database. Then re-PXE boot the nodes and
start a fresh deploy just to have them named node11 and 20 again. Fuel cli
does show the correct host name for these nodes, but I've tried anyway to
(re)set the host name for these node with no affect.

If I try to delete node-11 and node-20 I get this error
404 Client Error: Not Found for url:
http://10.20.243.1:8000/api/v1/nodes/?ids=11 (NodeCollection not found)

what can I do to get past this please?



Errors from the Fuel Astute log:
2017-09-25 21:06:28 ERROR [1565] Error running provisioning:
# ,
trace: ["/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:178:in
`rescue in initialize_mclient'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:161:in
`initialize_mclient'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:51:in
`initialize'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:421:in
`new'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:421:in
`run_shell_without_check'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:449:in
`update_node_status'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:313:in
`reboot_hook'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:38:in
`block in process'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:26:in
`each'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/nailgun_hooks.rb:26:in
`process'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/image_provision.rb:117:in
`reboot'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:273:in
`soft_reboot'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:240:in
`provision_piece'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:126:in `block
(3 levels) in provision_and_watch_progress'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:309:in `call'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:309:in
`sleep_not_greater_than'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:120:in `block
(2 levels) in provision_and_watch_progress'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:119:in `loop'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:119:in `block
in provision_and_watch_progress'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:118:in
`catch'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:118:in
`provision_and_watch_progress'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/provision.rb:52:in
`provision'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/orchestrator.rb:109:in
`provision'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/dispatcher.rb:46:in
`provision'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/dispatcher.rb:37:in
`image_provision'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:172:in
`dispatch_message'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:131:in
`block in dispatch'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:64:in
`call'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:64:in
`block in each'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:56:in
`each'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/task_queue.rb:56:in
`each'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:128:in
`each_with_index'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:128:in
`dispatch'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/server/server.rb:106:in
`block in perform_main_job'"]
2017-09-25 21:06:26 ERROR [1565] Error occured while provisioning:
# >
2017-09-25 21:06:26 ERROR [1565] No more retries for MCollective client
instantiation after exception:
["/usr/share/gems/gems/mcollective-client-2.8.4/lib/mcollective/rpc/client.rb:507:in
`discover'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:167:in
`initialize_mclient'",
"/usr/share/gems/gems/astute-10.0.0/lib/astute/mclient.rb:51:in
`initialize'",

Re: [Openstack] Disable distributed loadbalancers (LBaaSv2)?

2017-09-25 Thread Turbo Fredriksson

On 21 Sep 2017, at 04:45, Kevin Benton  wrote:

> If you wanted to do it purely with an SQL hack you might be able to set 
> distributed to False in the router_extra_attributes table. Additionally you 
> would need to delete any entries from the routerports table with the type 
> 'network:router_centralized_snat' and update any with the type 
> 'network:router_interface_distributed' to 'network:router_interface’.

Thanx! That seems to have done the trick. I think:

bladeA01:~# neutron router-list
+--++--+-+---+
| id   | name   | external_gateway_info 

   
| distributed | ha|
+--++--+-+---+
| d9c39638-51b5-481a-a60d-df79b6a06f9d | infrastructure | {"network_id": 
"b74570c9-f40f-4c64-9e4c-9bf0c9978d2e", "enable_snat": true, 
"external_fixed_ips": [{"subnet_id": "7bc73f7a-f07e-4ad7-bcd8-1fd77f46c888", 
"ip_address": "10.0.5.1"}]} | False   | False |
| dac1e4f4-dd02-4f97-bc77-952906e8daa7 | tenant | {"network_id": 
"b74570c9-f40f-4c64-9e4c-9bf0c9978d2e", "enable_snat": true, 
"external_fixed_ips": [{"subnet_id": "ab4da704-0ed2-4e54-89e4-afc98b8bb631", 
"ip_address": "10.0.6.1"}]} | False   | False |
+--++--+-+———+

The “external_gateway_info” still say “enable_snat=true” on both of them…
Is that correct?

But at least both “distributed” and “ha” is “False” now, so there’s a lot
of progress! :). Million thanx.


All my compute nodes are still down, haven’t dared start them up yet.
Any way I can know for sure that this actually worked, without spinning
up everything?


signature.asc
Description: Message signed with OpenPGP
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [keystone]] Trello board update

2017-09-25 Thread Lance Bragstad

Hey all,

I went through the Trello board for all our Queens work and updated all
cards that needed "fleshing out". Each should have an accurate
description of the work, why it's needed, and a checklist if applicable.
If a card still doesn't make sense, please ping me or add the "needs
fleshing out" tag back to the card with a comment.

Thanks!

Lance




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Ocata moving to phase II

2017-09-25 Thread Ihar Hrachyshka

Hi all,

with the latest Ocata release[1], stable/ocata branches now officially
move to phase II support. The phase is defined in [2] as:

"Only critical bugfixes and security patches are acceptable."

In Neutron, it usually means that we may now allow fixes for High and
Critical bugs only. (Plus CVEs.) Of course, test fixes,
infrastructural fixes for gates, more test coverage, documentation
fixes are all valid fixes still, because they are by their own nature
don't affect production instances of Neutron.

And of course, Pike is now our main focus for all kinds of backports.

[1] https://review.openstack.org/#/c/505814/
[2] https://docs.openstack.org/project-team-guide/stable-branches.html

Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ironic] this week's priorities and subteam reports

2017-09-25 Thread Yeleswarapu, Ramamani

Hi,

We are glad to present this week's priorities and subteam report for Ironic. As 
usual, this is pulled directly from the Ironic whiteboard[0] and formatted.

This Week's Priorities (as of the weekly ironic meeting)

1. Decide on the priorities for the Queens cycle (dtantsur to post a review 
soon)
2. Refactoring of the way we access clients: 
https://review.openstack.org/#/q/topic:bug/1699547
3. Rolling upgrades missing bit: https://review.openstack.org/#/c/497666/
3.1. check object versions in dbsync tool: 
https://review.openstack.org/#/c/497703/
4. Switch to none auth for standalone mode: 
https://review.openstack.org/#/c/359061/
5. Script to extract ironic_tempest_plugin: 
https://review.openstack.org/#/c/489762/
5.1. this is needed for the plugin separation

Vendor priorities
-
cisco-ucs:
idrac:
Dell 3d party CI stability improvement for 13G and 12G servers - 
https://review.openstack.org/#/c/505398/
ilo:
irmc:
nothing to review this week.
secure boot support for virtual media boot interface is coming soon.
oneview:
Documentation for 'oneview' hardware type - 
https://review.openstack.org/#/c/502072/

Subproject priorities
-
bifrost:
ironic-inspector (or its client):
(dtantsur on behalf of milan): firewall refactoring: 
https://review.openstack.org/#/c/471831/
networking-baremetal:
  neutron baremetal agent https://review.openstack.org/#/c/456235/ (needs 
rebase and update)
sushy and the redfish driver:
(dtantsur) implement redfish sessions: 
https://review.openstack.org/#/c/471942/


Bugs (dtantsur, vdrok, TheJulia)

- Stats (diff between 18 Sep 2017 and 25 Sep 2017)
- Ironic: 269 bugs (+5) + 255 wishlist items (-3). 29 new, 200 in progress 
(+2), 0 critical, 30 high (-2) and 34 incomplete (-1)
- Inspector: 13 bugs + 29 wishlist items. 2 new (-1), 11 in progress (+1), 0 
critical, 2 high and 3 incomplete
- Nova bugs with Ironic tag: 16 (+1). 0 new, 0 critical, 2 high
- dtantsur had to update the batch sizes used in the bug dashboard. now it's 
more reliable but much slower :(

CI refactoring and missing test coverage

- not considered a priority, it's a 'do it always' thing
- Standalone CI tests (vsaienk0)
- next patch to be reviewed, needed for 3rd party CI: 
https://review.openstack.org/#/c/429770/
- Missing test coverage (all)
- portgroups and attach/detach tempest tests: 
https://review.openstack.org/382476
- local boot with partition images: TODO 
https://bugs.launchpad.net/ironic/+bug/1531149
- adoption: https://review.openstack.org/#/c/344975/
- should probably be changed to use standalone tests
- root device hints: TODO
- node take over?
- resource classes integration tests: 
https://review.openstack.org/#/c/443628/

Essential Priorities

!!! this list is work-in-progress now !!!

Reference architecture guide (dtantsur)
---
- status as of 14 Aug 2017:
- Common bits: https://review.openstack.org/487410 needs a revision
- I guess this moves to Queens

Driver composition (dtantsur)
-
- spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-composition-reform.html
- gerrit topic: https://review.openstack.org/#/q/status:open+topic:bug/1524745
- status as of 28 Aug 2017:
- documentation
- upgrade guide for the remaining drivers: TODO
- ilo: https://review.openstack.org/#/c/496480/
- idrac: (rpioso) TODO
- snmp: https://review.openstack.org/#/c/498541/ MERGED
- dev docs on writing hardware types: TODO
- what to do with VendorMixin on upgrade 
https://review.openstack.org/#/c/507019/
- new hardware types:
- apparently all merged in Pike
- API for hardware interface properties:
- proposed spec: https://review.openstack.org/#/c/471174/
- spec on the classic drivers deprecation: 
http://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/classic-drivers-future.html
 to be continued in Queens

High Priorities
===
!!! this list is work-in-progress now !!!

Rescue mode (stendulker/aparnav)

- spec: 
http://specs.openstack.org/openstack/ironic-specs/specs/approved/implement-rescue-mode.html
- code: https://review.openstack.org/#/q/topic:bug/1526449+status:open
- Status: 25 Sep 2017
- The nova patch for Rescue is abandoned and rescue tempest 
patch(https://review.openstack.org/#/c/452308/) which is dependent on the nova 
patch is in merge conflict.
- any plans to revive the nova patch soon(ish)?
- (TheJulia) None that I'm aware of, but nova is going to expect ironic 
work be completed first.

Neutron event processing (vdrok, vsaienk0)
--
- spec at

Re: [openstack-dev] [all][QA][group-based-policy][zaqar][packaging_deb][fuel][networking-*] Marking <= mitaka EOL

2017-09-25 Thread Jeremy Stanley

On 2017-09-24 12:48:41 -0400 (-0400), Paul Belanger wrote:
[...]
> I just noticed our DIB image git cache is still referencing old
> branches we have EOL'd. This is because we haven't deleted the
> cache in some time.

The fact that the cache needs manual cleaning is a bug, in my
opinion. It would be good to figure out whether it can be pruned at
every update, and whether there's maybe just a feature of DIB's
source repositories functionality we're missing turning on to make
that happen. Otherwise maybe we can prune unreachable refs and
nonexistent remote heads periodically via cron?

> I think we could update the EOL docs to have an infra-root make
> sure we do this, after all branches have been EOL'd in gerrit.
> Unless there is a better way to do this using git over manually
> deleting the cache on our nodepool-builder servers.

Yeah, while it'll do in the short term it strikes me as more of a
workaround than a proper solution.
-- 
Jeremy Stanley

signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-25 Thread Jeremy Stanley

On 2017-09-25 12:12:23 -0400 (-0400), Anita Kuno wrote:
> When I click this link I see two items. Perhaps the list can be
> named 'help wanted list' and the point about it being the top 5 or
> having a maximum of 5 items can be made in the text. Having a top
> 5 list with 2 items may confuse the audience folks are trying to
> redirect here.

The original intent was not to publicize it until we had approved
three more items, but five seems like a somewhat arbitrary number to
me and baking it into the idea has resulted in us postponing
advertisement of good existing content.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] vGPUs support for Nova

Sahid,

   Just share some background. XenServer doesn't expose vGPUs as mdev or pci 
devices. I proposed a spec about one year ago to make fake pci devices so that 
we can use the existing PCI mechanism to cover vGPUs. But that's not a good 
design and got strongly objection. After that, we switched to use the resource 
providers by following the advice from the core team.

Regards,
Jianghua

-Original Message-
From: Sahid Orentino Ferdjaoui [mailto:sferd...@redhat.com] 
Sent: Monday, September 25, 2017 11:01 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] vGPUs support for Nova

On Mon, Sep 25, 2017 at 09:29:25AM -0500, Matt Riedemann wrote:
> On 9/25/2017 5:40 AM, Jay Pipes wrote:
> > On 09/25/2017 05:39 AM, Sahid Orentino Ferdjaoui wrote:
> > > There is a desire to expose the vGPUs resources on top of Resource 
> > > Provider which is probably the path we should be going in the long 
> > > term. I was not there for the last PTG and you probably already 
> > > made a decision about moving in that direction anyway. My personal 
> > > feeling is that it is premature.
> > > 
> > > The nested Resource Provider work is not yet feature-complete and 
> > > requires more reviewer attention. If we continue in the direction 
> > > of Resource Provider, it will need at least 2 more releases to 
> > > expose the vGPUs feature and that without the support of NUMA, and 
> > > with the feeling of pushing something which is not 
> > > stable/production-ready.
> > > 
> > > It's seems safer to first have the Resource Provider work well 
> > > finalized/stabilized to be production-ready. Then on top of 
> > > something stable we could start to migrate our current virt 
> > > specific features like NUMA, CPU Pinning, Huge Pages and finally PCI 
> > > devices.
> > > 
> > > I'm talking about PCI devices in general because I think we should 
> > > implement the vGPU on top of our /pci framework which is 
> > > production ready and provides the support of NUMA.
> > > 
> > > The hardware vendors building their drivers using mdev and the 
> > > /pci framework currently understand only SRIOV but on a quick 
> > > glance it does not seem complicated to make it support mdev.
> > > 
> > > In the /pci framework we will have to:
> > > 
> > > * Update the PciDevice object fields to accept NULL value for
> > >    'address' and add new field 'uuid'
> > > * Update PciRequest to handle a new tag like 'vgpu_types'
> > > * Update PciDeviceStats to also maintain pool of vGPUs
> > > 
> > > The operators will have to create alias(-es) and configure 
> > > flavors. Basically most of the logic is already implemented and 
> > > the method 'consume_request' is going to select the right vGPUs 
> > > according the request.
> > > 
> > > In /virt we will have to:
> > > 
> > > * Update the field 'pci_passthrough_devices' to also include GPUs
> > >    devices.
> > > * Update attach/detach PCI device to handle vGPUs
> > > 
> > > We have a few people interested in working on it, so we could 
> > > certainly make this feature available for Queen.
> > > 
> > > I can take the lead updating/implementing the PCI and libvirt 
> > > driver part, I'm sure Jianghua Wang will be happy to take the lead 
> > > for the virt XenServer part.
> > > 
> > > And I trust Jay, Stephen and Sylvain to follow the developments.
> > 
> > I understand the desire to get something in to Nova to support 
> > vGPUs, and I understand that the existing /pci modules represent the 
> > fastest/cheapest way to get there.
> > 
> > I won't block you from making any of the above changes, Sahid. I'll 
> > even do my best to review them. However, I will be primarily 
> > focusing this cycle on getting the nested resource providers work 
> > feature-complete for (at least) SR-IOV PF/VF devices.
> > 
> > The decision of whether to allow an approach that adds more to the 
> > existing /pci module is ultimately Matt's.
> > 
> > Best,
> > -jay
> > 
> > 
> > __ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: 
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Nested resource providers is not merged or production ready because we 
> haven't made it a priority. We've certainly talked about it and Jay 
> has had patches proposed for several releases now though.
> 
> Building vGPU support into the existing framework, which only a couple 
> of people understand - certainly not me, might be a short-term gain 
> but is just more technical debt we have to pay off later, and delays 
> any focus on nested resource providers for the wider team.
> 
> At the Queens PTG it was abundantly clear that many features are 
> dependent on nested resource providers, including several 
> networking-related features like bandwidth-based

Re: [openstack-dev] [octavia] haproxy fails to receive datagram

2017-09-25 Thread Michael Johnson

Hi Yipei,

I just tried to reproduce this and was not successful.

I setup a tenant network, added a web server to it, created a
loadbalancer VIP on the tenant network, added the webserver as a
member on the load balancer.  I can curl from the tenant network
qdhcp- netns without issue.

Are you running a recent version of Octavia?  This bug might be
impacting you: https://review.openstack.org/501915

Can you check if this routing table is present inside your amphora netns?

root@amphora-f58cdb7c-8fde-4eea-bd40-780664cfa49f:~# ip netns exec
amphora-haproxy ip route show table 1

default via  dev eth1 onlink

It could be that since they are all on the same subnet there is a
return path issue in the kernel which this patch fixes with a policy
based route.

Michael

On Mon, Sep 25, 2017 at 1:33 AM, Yipei Niu  wrote:
> Hi, all,
>
> I encounter some problems when using Octavia. After installing octavia with
> devstack, I create a load balancer named lb1 (VIP: 10.0.1.9, IP of VRRP
> port: 10.0.1.3) for a subnet (10.0.1.0/24), then a listener, a pool, and two
> members. All the resources are created successfully. The two members (VMs)
> reside in the same subnet, whose IP are 10.0.1.6 and 10.0.1.7, respectively.
> To simulate a web server in each VM, I run "while true; do echo -e "HTTP/1.0
> 200 OK\r\n\r\nWelcome to $VM_IP" | sudo nc -l -p 80;done" to listen on port
> 80 and return the VM's IP if the request is accepted. I run "sudo ip netns
> exec qdhcp- curl -v $VM_IP" to send requests to VMs, the "web servers"
> in VMs work (already added corresponding security rules to the VMs). Then I
> tried to run "sudo ip netns exec qdhcp- curl -v $VIP" to send requests,
> the VMs do not respond, and finally returns a timeout error.
>
> The configuration details in local.conf are as follows.
>
> [[local|localrc]]
>
> DATABASE_PASSWORD=password
> RABBIT_PASSWORD=password
> SERVICE_PASSWORD=password
> SERVICE_TOKEN=password
> ADMIN_PASSWORD=password
>
> HOST_IP=192.168.56.9
>
> LOGFILE=/opt/stack/logs/stack.sh.log
> VERBOSE=True
> LOG_COLOR=True
> SCREEN_LOGDIR=/opt/stack/logs
>
> # Neutron LBaaS
> enable_plugin neutron-lbaas https://github.com/openstack/neutron-lbaas.git
> enable_plugin octavia https://github.com/openstack/octavia.git
> ENABLED_SERVICES+=,q-lbaasv2
> ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api
>
> disable_service horizon
> disable_service tempest
>
> To investigate the source of the error, I logon to the amphora. The details
> of interfaces of amphora_haproxy network namespace are as follows.
>
> 1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> 3: eth1:  mtu 1450 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether fa:16:3e:42:bf:d9 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.3/24 brd 10.0.1.255 scope global eth1
>valid_lft forever preferred_lft forever
> inet 10.0.1.9/24 brd 10.0.1.255 scope global secondary eth1:0
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe42:bfd9/64 scope link
>valid_lft forever preferred_lft forever
>
> So I run "sudo ip netns exec amphora-haproxy tcpdump -i eth1 -nn 'tcp'" to
> check whether amphora receive the request. The details are as follows.
>
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
> ^C06:11:49.048973 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
> 1717936594, win 28200, options [mss 1410,sackOK,TS val 28032309 ecr
> 0,nop,wscale 7], length 0
> 06:11:50.031976 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28032559 ecr 0,nop,wscale 7],
> length 0
> 06:11:52.026565 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28033060 ecr 0,nop,wscale 7],
> length 0
> 06:11:56.002577 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28034062 ecr 0,nop,wscale 7],
> length 0
> 06:12:03.909721 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq 1717936594,
> win 28200, options [mss 1410,sackOK,TS val 28036064 ecr 0,nop,wscale 7],
> length 0
>
> Based on the trace, we can see that amphora do receive the request, but
> haproxy does not send handshake datagram to respond. Then, to see whether
> haproxy in the amphora listens on the right IP and port, I print
> /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg in the
> console and see the following info.
>
> # Configuration for lb1
> global
> daemon
> user nobody
> log /dev/log local0
> log /dev/log local1 notice
> stats socket /var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57.sock
> mode 0666 level user
>
> defaults
> log global
> retries 3
> option redispatch
> timeout connect 5000
> timeout client 5
>

Re: [Openstack] Help needed with migrating Fuel server

2017-09-25 Thread Evgeniy L

Hi,

Try following this guide:
https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master

Thanks,

On Sun, Sep 24, 2017 at 11:57 PM, Raja T Nair  wrote:

> Hello All,
>
> Can somebody help me with info on how to migrate OR backup/restore fuel
> server to another hardware?
> Fuel version - fuel-7.0.0-6122.1
>
> We want to migrate fuel services to a new hardware.
>
> Many Thanks.
> Raja.
>
> --
> :^)
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Fuel] Fuel 11 does not boot into setup menu, does not install successfully

2017-09-25 Thread Evgeniy L

Hi,

I've never tried installing 11 version, but this looks suspicious:
fuelmenu=10.0.0

I think it should be version 11, not 10.

Thanks,

On Thu, Sep 21, 2017 at 9:30 AM, Tomas Brännström <
tomas.a.brannst...@tieto.com> wrote:

> Hi
> I'm trying to install the Fuel 11 release in a Virtualbox VM, but to no
> success. When the OS install is finished, instead of starting the fuelmenu,
> I just get to a login prompt. Scrolling up the tty reveals a stack trace
> from python:
>
> + fuelmenu --save-only --iface=eth0
> Traceback (most recent call last):
>   File "/bin/fuelmenu", line 9, in 
> load_entry_point('fuelmenu=10.0.0', 'console_scripts', 'fuelmenu')()
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 385,
> in main
> managed_iface=options.iface)
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 340,
> in setup
> FuelSetup(**kwargs)
>   File "/usr/lib/python2.7/site-packages/fuelmenu/fuelmenu.py", line 78,
> in __init__
> self.main()
>
> (sorry for any typos, I had to type it out by hand...)
>
> Once logged in I can run fuelmenu without any arguments, but even after
> doing the regular configuration there I can tell that everything hasn't
> been successfully installed: the web GUI is not running and I can't ssh
> into the VM. Also the install procedure usually takes a lot longer than
> what I'm seeing here.
>
> This is running in Virtualbox version 5.1.26r117224. The VM has two NIC's
> (one NAT:ed and one bridged with the ADMIN vlan), if that matters.
>
> We've been using Fuel 9 previously without issues.
>
> /Tomas
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-25 Thread Anita Kuno


On 2017-09-22 06:11 PM, Mike Perez wrote:

On 21:21 Sep 21, Matt Riedemann wrote:

I just wanted to highlight to people that there seems to be a series of
garbage patches in various projects [1] which are basically doing things
like fixing a single typo in a code comment, or very narrowly changing http
to https in links within docs.

Also +1ing ones own changes.

I've been trying to snuff these out in nova, but I see it's basically a
pattern widespread across several projects.

This is the boilerplate comment I give with my -1, feel free to employ it
yourself.

"Sorry but this isn't really a useful change. Fixing typos in code comments
when the context is still clear doesn't really help us, and mostly seems
like looking for padding stats on stackalytics. It's also a drain on our CI
environment.

If you fixed all of the typos in a single module, or in user-facing
documentation, or error messages, or something in the logs, or something
that actually doesn't make sense in code comments, then maybe, but this
isn't one of those things."

I'm not trying to be a jerk here, but this is annoying to the point I felt
the need to say something publicly.

[1] https://review.openstack.org/#/q/author:%255E.*inspur.*

I agree with the frustration here. It was mentioned earlier in the thread the
top 5 wanted [1] is a good step in the right direction. I think also the
efforts on the contributor portal [2] are going to be a helpful link to send
people when they make mistakes.

I'm sure some of the people who haven't had this communicated to them yet
aren't aware, so we should all be aware as demonstrated in Matt's boilerplate
comment to be nice when communicating.

[1] - http://governance.openstack.org/tc/reference/top-5-help-wanted.html


When I click this link I see two items. Perhaps the list can be named 
'help wanted list' and the point about it being the top 5 or having a 
maximum of 5 items can be made in the text. Having a top 5 list with 2 
items may confuse the audience folks are trying to redirect here.


Thanks,
Anita.


[2] - 
http://lists.openstack.org/pipermail/openstack-dev/2017-September/122534.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][infra] Release of openstack-infra/zuul-sphinx failed

2017-09-25 Thread James E. Blair

Jeremy Stanley  writes:

> On 2017-09-25 10:51:42 -0400 (-0400), Doug Hellmann wrote:
>> I assume someone has already noticed that this release failed, but I'm
>> forwarding it to the dev list just in case.
>
> Thanks for the heads up! And yes, it's currently under discussion in
> #openstack-infra but we're still trying to nail down the root cause.

We recently removed several Zuul mergers to reallocate them to Zuul v3
in preparation for the cutover.  Unfortunately, the persistent
workspaces on the release worker have git repos which may have
originally been cloned from those mergers, and so when our release jobs
update those repos, they may consult those mergers as they are the
'origin' remotes.

This is increasingly likely to affect projects created more recently, as
older projects would have been cloned when we had fewer mergers, and the
mergers we removed were the ones added last.

This is something that, ideally, we would have addressed either in
zuul-cloner or in the release jobs.  However, we're about to replace
them all, so it's probably not worth worrying about.

In the mean time, I removed all of the workspaces on the release worker,
so all projects will clone anew from the existing set of mergers.

-Jim

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Release-job-failures][infra] Release of openstack-infra/zuul-sphinx failed

2017-09-25 Thread Jeremy Stanley

On 2017-09-25 10:51:42 -0400 (-0400), Doug Hellmann wrote:
> I assume someone has already noticed that this release failed, but I'm
> forwarding it to the dev list just in case.

Thanks for the heads up! And yes, it's currently under discussion in
#openstack-infra but we're still trying to nail down the root cause.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 22/09/17 14:47 -0400, Doug Hellmann wrote:

Excerpts from Davanum Srinivas (dims)'s message of 2017-09-22 13:47:06 -0400:

Doug,
Howard (cc'ed) already did a bunch of reaching out especially on
wechat. We should request his help.

Howard,
Can you please help with communications and follow up?

Thanks,
Dims


Thanks, Dims and Howard,

I think the problem has reached a point where it would be a good
idea to formalize our approach to outreach. We should track the
patches or patch series identified as problematic, so reviewers
know not to bother with them. We can also track who is contacting
whom (and how) so we don't have a bunch of people replicating work
or causing confusion for people who are trying to contribute. Having
that information will also help us figure out when we need to
escalate by finding the right managers to be talking to.

Let's put together a small team to manage this instead of letting
it continue to cause frustration for everyone.


Count me in! I'm interested in helping with this effort.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 22/09/17 14:20 +, Jeremy Stanley wrote:

On 2017-09-22 08:30:21 -0400 (-0400), Amrith Kumar wrote:
[...]

When can we take some concrete action to stop these same kinds of
things from coming up again and again?


Technical solutions to social problems rarely do more than increase
complexity for everyone involved.


Just wanted to +1 this as I just mentioned a technical solution in one of my
replies to this thread on which I also said I doubt it would ever work/help.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Running large instances with CPU pinning and OOM

2017-09-25 Thread Jakub Jursa

Hello everyone,

We're experiencing issues with running large instances (~60GB RAM) on
fairly large NUMA nodes (4 CPUs, 256GB RAM) while using cpu pinning. The
problem is that it seems that in some extreme cases qemu/KVM can have
significant memory overhead (10-15%?) which nova-compute service doesn't
take in to the account when launching VMs. Using our configuration as an
example - imagine running two VMs with 30GB RAM on one NUMA node
(because we use cpu pinning) - therefore using 60GB out of 64GB for
given NUMA domain. When both VMs would consume their entire memory
(given 10% KVM overhead) OOM killer takes an action (despite having
plenty of free RAM in other NUMA nodes). (the numbers are just
arbitrary, the point is that nova-scheduler schedules the instance to
run on the node because the memory seems 'free enough', but specific
NUMA node can be lacking the memory reserve).

Our initial solution was to use ram_allocation_ratio < 1 to ensure
having some reserved memory - this didn't work. Upon studying source of
nova, it turns out that ram_allocation_ratio is ignored when using cpu
pinning. (see
https://github.com/openstack/nova/blob/mitaka-eol/nova/virt/hardware.py#L859
and
https://github.com/openstack/nova/blob/mitaka-eol/nova/virt/hardware.py#L821
). We're running Mitaka, but this piece of code is implemented in Ocata
in a same way.
We're considering to create a patch for taking ram_allocation_ratio in
to account.

My question is - is ram_allocation_ratio ignored on purpose when using
cpu pinning? If yes, what is the reasoning behind it? And what would be
the right solution to ensure having reserved RAM on the NUMA nodes?

Thanks.

Regards,

Jakub Jursa

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes


On 23/09/17 12:25 -0400, Doug Hellmann wrote:

Excerpts from Qiming Teng's message of 2017-09-23 23:55:34 +0800:

To some extent, I think Zhipeng is right. There are times we as a
community have to do something beyond mentoring new developers. One of
the reasons behind these patches are from the management chain of those
companies. They need numbers, and they don't care what kind of
contributions were made. They don't bother read these emails.

Another fact is that some companies are doing such things not just in the
OpenStack community. Their developers are producing tons of low-quality
"patches" to play this as a game in other communities as well. If we
don't place a STOP sign, things will never get improved. By not doing
something, we are hurting everyone, including those developers who could
have done more meaningful contributions, though their number of patches
may decrease.

Just my 2 cents.

- Qiming


This may be true. Before we create harsh processes, however, we
need to collect the data to show that other attempts to provide
guidance have not worked.  We have a lot of anecdotal information
right now. We need to collect that and summarize it. If the results
show that there are clear abuses, rather than misunderstandings,
then we can use the data to design effective blocks without hurting
other contributors or creating a reputation that our community is
not welcoming.


I would also like to take this opportunity to encourage everyone to assume good
faith. There are ways to evaluate if there are reasons to believe there are
abusive behaviors from some companies and/or contributors.

It is neither encouraged nor right to publicly shame anyone. This is not the way
we operate and I would like to keep it that way. Let's build a process and/or
tool that can be used to analyze this behaviors so that we can communicate them
through the right channels.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] patches for simple typo fixes

On 25/09/17 09:28 -0400, Doug Hellmann wrote:

Excerpts from Sean Dague's message of 2017-09-25 08:24:18 -0400:

On 09/25/2017 07:56 AM, Chris Dent wrote:
> On Fri, 22 Sep 2017, Paul Belanger wrote:
>
>> This is not a good example of encouraging anybody to contribute to the
>> project.
>
> Yes. This entire thread was a bit disturbing to read. Yes, I totally
> agree that mass patches that do very little are a big cost to
> reviewer and CI time but a lot of the responses sound like: "go away
> you people who don't understand our special culture and our
> important work".
>
> That's not a good look.
>
> Matt's original comment is good in and of itself: I saw a thing,
> let's remember to curtail this stuff and do it in a nice way.
>
> But then we generate a long thread about it. It's odd to me that
> these threads sometimes draw more people out then discussions about
> actually improving the projects.
>
> It's also odd that if OpenStack were small and differently
> structured, any self-respecting maintainer would be happy to see
> a few typo fixes and generic cleanups. Anything to push the quality
> forward is nice. But because of the way we do review and because of
> the way we do CI these things are seen as expensive distractions[1].
> We're old and entrenched enough now that our tooling enforces our
> culture and our culture enforces our tooling.
>
> [1] Note that I'm not denying they are expensive distractions nor
> that they need to be managed as such. They are, but a lot of that
> is on us.

I was trying to ignore the thread in the hopes it would die out quick.
But torches and pitchforks all came out from the far corners, so I'm
going to push back on that a bit.

I'm not super clear why there is always so much outrage about these
patches. They are fixing real things. When I encounter them, I just
approve them to get them merged quickly and not backing up the review
queue, using more CI later if they need rebasing. They are fixing real
things. Maybe there is a CI cost, but the faster they are merged the
less likely someone else is to propose it in the future, which keeps
down the CI cost. And if we have a culture of just fixing typos later,
then we spend less CI time on patches the first time around with 2 or 3
iterations catching typos.

I think the concern is the ascribed motive for why people are putting
these up. That's fine to feel that people are stat padding (and that too
many things are driven off metrics). But, honestly, that's only
important if we make it important. Contributor stats are always going to
be pretty much junk stats. They are counting things to be the same which
are wildly variable in meaning (number of patches, number of Lines of
Code).

My personal view is just merge things that fix things that are wrong,
don't care why people are doing it. If it gets someone a discounted
ticket somewhere, so be it. It's really not any skin off our back in the
process.

If people are deeply concerned about CI resources, step one is to get
some better accounting into the existing system to see where resources
are currently spent, and how we could ensure that time is fairly spread
around to ensure maximum productivity by all developers.

-Sean

I'm less concerned with the motivation of someone submitting the
patches than I am with their effect. Just like the situation we had
with the bug squash days a year or so ago, if we had a poorly timed
set of these trivial patches coming in at our feature freeze deadline,
it would be extremely disruptive. So to me the fact that we're
seeing them in large batches means we have people who are not fully
engaged with the community and don't understand the impact they're
having. My goal is to reach out and try to improve that engagement,
and try to help them become more fully constructive contributors.

I agree with the sentinment that these patches might be coming from folks that
are not fully engaged with the community but they won't stop comming.

There's a risk behind this mass submitted patches but I agree with Sean's
comment that they are still fixing things. Once they've been submitted, I think
we're better off merging them if we're not in a release phase.

A more agressive fix would be to limit the amount of patches a single person can
propose in a given day and in a specific period of time (or forever) but this
might not be possible or not exactly what we want as I would rather work with
the community.

Flavio

--
@flaper87
Flavio Percoco

signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session


- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.


I'd say for ceph-ansible, kubernetes and in general anything else which
needs to run with a standard playbook installed on the undercloud and
not one generated via the heat templates... these "external" services
usually require the inventory file to be in different format, to
describe the hosts to use on a per-service basis, not per-role (and I
mean tripleo roles here, not ansible roles obviously)

About that, we discussed a more long term vision where the playbooks
(static data) needd to describe how to deploy/upgrade a given service is
in a separate repo (like tripleo-apb) and we "compose" from heat the
list of playbooks to be executed based on the roles/enabled services; in
this scenario we'd be much closer to what we had to do for ceph-ansible
and I feel like that might finally allow us merge back the ceph
deployment (or kubernetes deployment) process into the more general
approach driven by tripleo

James, Dan, comments?


Agreed, I think this is the longer term plan in regards to using
APB's, where everything consumed is an external playbook/role.

We definitely want to consider this plan in parallel with the POC work
that Flavio is pulling together and make sure that they are aligned so
that we're not constantly reworking the framework.

I've not yet had a chance to review the material he sent out this
morning, but perhaps we could work together to update the sequence
diagram to also have a "future" state to indicate where we are going
and what it would look like with APB's and external paybooks.


So far, I think it aligns just fine. I would like to start playing with it and
see if I can leaverage this work directly instead of modifying the existing
templates we use for paunch.

Will look into the details of how this works and get back to you,
Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptg] Simplification in OpenStack

2017-09-25 Thread Jonathan D. Proulx

On Sat, Sep 23, 2017 at 12:05:38AM -0700, Adam Lawson wrote:

:Lastly, I do think GUI's make deployments easier and because of that, I
:feel they're critical. There is more than one vendor whose built and
:distributes a free GUI to ease OpenStack deployment and management. That's
:a good start but those are the opinions of a specific vendor - not he OS
:community. I have always been a big believer in a default cloud
:configuration to ease the shock of having so many options for everything. I
:have a feeling however our commercial community will struggle with
:accepting any method/project other than their own as being part a default
:config. That will be a tough one to crack.

Different people have differnt needs, so this is not meant to
contradict Adam.

But :)

Any unique deployment tool would be of no value to me as OpenStack (or
anyother infrastructure component) needs to fit into my environment.
I'm not going to adopt something new that requires a new parallel
management tool to what I use.

I think focusing on the existing configuration management projects it
the way to go. Getting Ansible/Puppet/Chef/etc.. to support a well
know set of "constellations" in an opinionated would make deployment
easy (for most people who are using one of those already) and ,
ussuming the opionions are the same :) make consumption easier as
well.

As an example when I started using OpenStack (Essex) we  had recently
switch to Ubuntu as our Linux platform and Pupept as our config
management. Ubuntu had a "one click MAAS install of OpenStack" which
was impossible as it made all sorts of assumptions about our
environment and wanted controll of most of them so it could provide a
full deployemnt solution.  Puppet had a good integrated example config
where I plugged in some local choices and and used existing deploy
methodologies.

I fought with MAAS's "simple" install for a week.  When I gave up and
went with Puppet I had live users on a substantial (for the time)
cloud in less htan 2 days.

I don't think this has to do with the relative value of MASS and
Puppet at the time, but rather what fit my existing deploy workflows.

Supporting multiple config tools may not be simple from an upstream
perspective, but we do already have these projects and it is simpler
to consume for brown field deployers at least.

-Jon

:That's what I got tonight. hve a great weekend.
:
://adam
:
:
:*Adam Lawson*
:
:Principal Architect
:Office: +1-916-794-5706
:
:On Thu, Sep 21, 2017 at 11:23 AM, Clint Byrum  wrote:
:
:> Excerpts from Jeremy Stanley's message of 2017-09-21 16:17:00 +:
:> > On 2017-09-20 17:39:38 -0700 (-0700), Clint Byrum wrote:
:> > [...]
:> > > Something about common use cases and the exact mix of
:> > > projects + configuration to get there, and testing it? Help?
:> > [...]
:> >
:> > Maybe you're thinking of the "constellations" suggestion? It found
:> > its way into the TC vision statement, though the earliest mention I
:> > can locate is in John's post to this ML thread:
:> >
:> > http://lists.openstack.org/pipermail/openstack-dev/2017-
:> April/115319.html
:> >
:>
:> Yes, constellations. Thanks!
:>
:> __
:> OpenStack Development Mailing List (not for usage questions)
:> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
:> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
:>

:__
:OpenStack Development Mailing List (not for usage questions)
:Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
:http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] patches for simple typo fixes

2017-09-25 Thread Julien Danjou

On Mon, Sep 25 2017, Doug Hellmann wrote:

>> I was trying to ignore the thread in the hopes it would die out quick.
>> But torches and pitchforks all came out from the far corners, so I'm
>> going to push back on that a bit.
>> 
>> I'm not super clear why there is always so much outrage about these
>> patches. They are fixing real things. When I encounter them, I just
>> approve them to get them merged quickly and not backing up the review
>> queue, using more CI later if they need rebasing. They are fixing real
>> things. Maybe there is a CI cost, but the faster they are merged the
>> less likely someone else is to propose it in the future, which keeps
>> down the CI cost. And if we have a culture of just fixing typos later,
>> then we spend less CI time on patches the first time around with 2 or 3
>> iterations catching typos.
>> 
>> I think the concern is the ascribed motive for why people are putting
>> these up. That's fine to feel that people are stat padding (and that too
>> many things are driven off metrics). But, honestly, that's only
>> important if we make it important. Contributor stats are always going to
>> be pretty much junk stats. They are counting things to be the same which
>> are wildly variable in meaning (number of patches, number of Lines of
>> Code).
>> 
>> My personal view is just merge things that fix things that are wrong,
>> don't care why people are doing it. If it gets someone a discounted
>> ticket somewhere, so be it. It's really not any skin off our back in the
>> process.
>> 
>> If people are deeply concerned about CI resources, step one is to get
>> some better accounting into the existing system to see where resources
>> are currently spent, and how we could ensure that time is fairly spread
>> around to ensure maximum productivity by all developers.

Well said, agreed.

What I hate about this thread is that it's not the first one to pop up,
and it does not help to get the real problem getting acknowledge, which
IMHO is, that sometimes people spams Gerrit with small *wrong* patches.

But as you said, if they are real fixes, just blame yourself for merging
mistakes or typos in the first place.

> I'm less concerned with the motivation of someone submitting the
> patches than I am with their effect. Just like the situation we had
> with the bug squash days a year or so ago, if we had a poorly timed
> set of these trivial patches coming in at our feature freeze deadline,
> it would be extremely disruptive. So to me the fact that we're
> seeing them in large batches means we have people who are not fully
> engaged with the community and don't understand the impact they're
> having. My goal is to reach out and try to improve that engagement,
> and try to help them become more fully constructive contributors.

I think it's a good idea but I'm also pretty sure somebody already said
that (and probably did that) last time we had this discussion. While it
might or not (from my experience) improve this batch of contributors,
the next ones are already waiting to spam next cycle. ;)

-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] vGPUs support for Nova

2017-09-25 Thread Sahid Orentino Ferdjaoui

On Mon, Sep 25, 2017 at 09:29:25AM -0500, Matt Riedemann wrote:
> On 9/25/2017 5:40 AM, Jay Pipes wrote:
> > On 09/25/2017 05:39 AM, Sahid Orentino Ferdjaoui wrote:
> > > There is a desire to expose the vGPUs resources on top of Resource
> > > Provider which is probably the path we should be going in the long
> > > term. I was not there for the last PTG and you probably already made a
> > > decision about moving in that direction anyway. My personal feeling is
> > > that it is premature.
> > > 
> > > The nested Resource Provider work is not yet feature-complete and
> > > requires more reviewer attention. If we continue in the direction of
> > > Resource Provider, it will need at least 2 more releases to expose the
> > > vGPUs feature and that without the support of NUMA, and with the
> > > feeling of pushing something which is not stable/production-ready.
> > > 
> > > It's seems safer to first have the Resource Provider work well
> > > finalized/stabilized to be production-ready. Then on top of something
> > > stable we could start to migrate our current virt specific features
> > > like NUMA, CPU Pinning, Huge Pages and finally PCI devices.
> > > 
> > > I'm talking about PCI devices in general because I think we should
> > > implement the vGPU on top of our /pci framework which is production
> > > ready and provides the support of NUMA.
> > > 
> > > The hardware vendors building their drivers using mdev and the /pci
> > > framework currently understand only SRIOV but on a quick glance it
> > > does not seem complicated to make it support mdev.
> > > 
> > > In the /pci framework we will have to:
> > > 
> > > * Update the PciDevice object fields to accept NULL value for
> > >    'address' and add new field 'uuid'
> > > * Update PciRequest to handle a new tag like 'vgpu_types'
> > > * Update PciDeviceStats to also maintain pool of vGPUs
> > > 
> > > The operators will have to create alias(-es) and configure
> > > flavors. Basically most of the logic is already implemented and the
> > > method 'consume_request' is going to select the right vGPUs according
> > > the request.
> > > 
> > > In /virt we will have to:
> > > 
> > > * Update the field 'pci_passthrough_devices' to also include GPUs
> > >    devices.
> > > * Update attach/detach PCI device to handle vGPUs
> > > 
> > > We have a few people interested in working on it, so we could
> > > certainly make this feature available for Queen.
> > > 
> > > I can take the lead updating/implementing the PCI and libvirt driver
> > > part, I'm sure Jianghua Wang will be happy to take the lead for the
> > > virt XenServer part.
> > > 
> > > And I trust Jay, Stephen and Sylvain to follow the developments.
> > 
> > I understand the desire to get something in to Nova to support vGPUs,
> > and I understand that the existing /pci modules represent the
> > fastest/cheapest way to get there.
> > 
> > I won't block you from making any of the above changes, Sahid. I'll even
> > do my best to review them. However, I will be primarily focusing this
> > cycle on getting the nested resource providers work feature-complete for
> > (at least) SR-IOV PF/VF devices.
> > 
> > The decision of whether to allow an approach that adds more to the
> > existing /pci module is ultimately Matt's.
> > 
> > Best,
> > -jay
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Nested resource providers is not merged or production ready because we
> haven't made it a priority. We've certainly talked about it and Jay has had
> patches proposed for several releases now though.
> 
> Building vGPU support into the existing framework, which only a couple of
> people understand - certainly not me, might be a short-term gain but is just
> more technical debt we have to pay off later, and delays any focus on nested
> resource providers for the wider team.
> 
> At the Queens PTG it was abundantly clear that many features are dependent
> on nested resource providers, including several networking-related features
> like bandwidth-based scheduling.
> 
> The priorities for placement/scheduler in Queens are:
> 
> 1. Dan Smith's migration allocations cleanup.
> 2. Alternative hosts for reschedules with cells v2.
> 3. Nested resource providers.
> 
> All of these are in progress and need review.
> 
> I personally don't think we should abandon the plan to implement vGPU
> support with nested resource providers without first seeing any code changes
> for it as a proof of concept. It also sounds like we have a pretty simple
> staggered plan for rolling out vGPU support so it's not very detailed to
> start. The virt driver reports vGPU inventory and we decorate the details
> later with traits (which Alex Xu is working on and needs review).
> 
> Sahid, you could certainly

Re: [openstack-dev] [Release-job-failures][infra] Release of openstack-infra/zuul-sphinx failed

I assume someone has already noticed that this release failed, but I'm
forwarding it to the dev list just in case.

Excerpts from jenkins's message of 2017-09-25 14:46:58 +:
> Build failed.
> 
> - zuul-sphinx-tarball 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-tarball/312a264/
>  : SUCCESS in 1m 49s
> - zuul-sphinx-tarball-signing 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-tarball-signing/1b71335/
>  : FAILURE in 40s
> - zuul-sphinx-pypi-both-upload 
> http://logs.openstack.org/fc/fca979f1eaaed60af404e74c51c0ad67710e18cf/release/zuul-sphinx-pypi-both-upload/2826256/
>  : FAILURE in 7s
> - zuul-sphinx-announce-release zuul-sphinx-announce-release : SKIPPED
> - propose-zuul-sphinx-update-constraints 
> propose-zuul-sphinx-update-constraints : SKIPPED
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] TripleO/Ansible PTG session


On 18/09/17 09:37 -0600, James Slagle wrote:

On Wednesday at the PTG, TripleO held a session around our current use
of Ansible and how to move forward. I'll summarize the results of the
session. Feel free to add anything I forgot and provide any feedback
or questions.

We discussed the existing uses of Ansible in TripleO and how they
differ in terms of what they do and how they interact with Ansible. I
covered this in a previous email[1], so I'll skip over summarizing
those points again.

I explained a bit about the  "openstack overcloud config download"
approach implemented in Pike by the upgrades squad. This method
no-op's out the deployment steps during the actual Heat stack-update,
then uses the cli to query stack outputs to create actual Ansible
playbooks from those output values. The Undercloud is then used as the
Ansible runner to apply the playbooks to each Overcloud node.

I created a sequence diagram for this method and explained how it
would also work for initial stack deployment[2]:

https://slagle.fedorapeople.org/tripleo-ansible-arch.png

The high level proposal was to move in a direction where we'd use the
config download method for all Heat driven stack operations
(stack-create and stack-update).

We highlighted and discussed several key points about the method shown
in the diagram:

- The entire sequence and flow is driven via Mistral on the Undercloud
by default. This preserves the API layer and provides a clean reusable
interface for the CLI and GUI.

- It would still be possible to run ansible-playbook directly for
various use cases (dev/test/POC/demos). This preserves the quick
iteration via Ansible that is often desired.

- The remaining SoftwareDeployment resources in tripleo-heat-templates
need to be supported by config download so that the entire
configuration can be driven with Ansible, not just the deployment
steps. The success criteria for this point would be to illustrate
using an image that does not contain a running os-collect-config.

- The ceph-ansible implementation done in Pike could be reworked to
use this model. "config download" could generate playbooks that have
hooks for calling external playbooks, or those hooks could be
represented in the templates directly. The result would be the same
either way though in that Heat would no longer be triggering a
separate Mistral workflow just for ceph-ansible.

- We will need some centralized log storage for the ansible-playbook
results and should consider using ARA.

As it would be a lot of work to eventually make this method the
default, I don't expect or plan that we will complete all this work in
Queens. We can however start moving in this direction.

Specifically, I hope to soon add support to config download for the
rest of the SoftwareDeployment resources in tripleo-heat-templates as
that will greatly simplify the undercloud container installer. Doing
so will illustrate using the ephemeral heat-all process as simply a
means for generating ansible playbooks.

I plan to create blueprints this week for Queens and beyond. If you're
interested in this work, please let me know. I'm open to the idea of
creating an official squad for this work, but I'm not sure if it's
needed or not.

As not everyone was able to attend the PTG, please do provide feedback
about this plan as it should still be considered open for discussion.



Hey James,

sorry for getting back to this thread this late!

I like the approach and I think it makes sense for us to go down this path. As
far as my research on tripleo+kubernetes goes, I think this plan aligns quite
well with what I've been doing so far.

That said, I need to dive more into how `config download` works and start using
it for future demos and development.

Flavio

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] vGPUs support for Nova

2017-09-25 Thread Matt Riedemann


On 9/25/2017 5:40 AM, Jay Pipes wrote:

On 09/25/2017 05:39 AM, Sahid Orentino Ferdjaoui wrote:

There is a desire to expose the vGPUs resources on top of Resource
Provider which is probably the path we should be going in the long
term. I was not there for the last PTG and you probably already made a
decision about moving in that direction anyway. My personal feeling is
that it is premature.

The nested Resource Provider work is not yet feature-complete and
requires more reviewer attention. If we continue in the direction of
Resource Provider, it will need at least 2 more releases to expose the
vGPUs feature and that without the support of NUMA, and with the
feeling of pushing something which is not stable/production-ready.

It's seems safer to first have the Resource Provider work well
finalized/stabilized to be production-ready. Then on top of something
stable we could start to migrate our current virt specific features
like NUMA, CPU Pinning, Huge Pages and finally PCI devices.

I'm talking about PCI devices in general because I think we should
implement the vGPU on top of our /pci framework which is production
ready and provides the support of NUMA.

The hardware vendors building their drivers using mdev and the /pci
framework currently understand only SRIOV but on a quick glance it
does not seem complicated to make it support mdev.

In the /pci framework we will have to:

* Update the PciDevice object fields to accept NULL value for
   'address' and add new field 'uuid'
* Update PciRequest to handle a new tag like 'vgpu_types'
* Update PciDeviceStats to also maintain pool of vGPUs

The operators will have to create alias(-es) and configure
flavors. Basically most of the logic is already implemented and the
method 'consume_request' is going to select the right vGPUs according
the request.

In /virt we will have to:

* Update the field 'pci_passthrough_devices' to also include GPUs
   devices.
* Update attach/detach PCI device to handle vGPUs

We have a few people interested in working on it, so we could
certainly make this feature available for Queen.

I can take the lead updating/implementing the PCI and libvirt driver
part, I'm sure Jianghua Wang will be happy to take the lead for the
virt XenServer part.

And I trust Jay, Stephen and Sylvain to follow the developments.


I understand the desire to get something in to Nova to support vGPUs, 
and I understand that the existing /pci modules represent the 
fastest/cheapest way to get there.


I won't block you from making any of the above changes, Sahid. I'll even 
do my best to review them. However, I will be primarily focusing this 
cycle on getting the nested resource providers work feature-complete for 
(at least) SR-IOV PF/VF devices.


The decision of whether to allow an approach that adds more to the 
existing /pci module is ultimately Matt's.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Nested resource providers is not merged or production ready because we 
haven't made it a priority. We've certainly talked about it and Jay has 
had patches proposed for several releases now though.


Building vGPU support into the existing framework, which only a couple 
of people understand - certainly not me, might be a short-term gain but 
is just more technical debt we have to pay off later, and delays any 
focus on nested resource providers for the wider team.


At the Queens PTG it was abundantly clear that many features are 
dependent on nested resource providers, including several 
networking-related features like bandwidth-based scheduling.


The priorities for placement/scheduler in Queens are:

1. Dan Smith's migration allocations cleanup.
2. Alternative hosts for reschedules with cells v2.
3. Nested resource providers.

All of these are in progress and need review.

I personally don't think we should abandon the plan to implement vGPU 
support with nested resource providers without first seeing any code 
changes for it as a proof of concept. It also sounds like we have a 
pretty simple staggered plan for rolling out vGPU support so it's not 
very detailed to start. The virt driver reports vGPU inventory and we 
decorate the details later with traits (which Alex Xu is working on and 
needs review).


Sahid, you could certainly implement a separate proof of concept and 
make that available if the nested resource providers-based change hits 
major issues or goes far too long and has too much risk, then we have a 
contingency plan at least. But I don't expect that to get review 
priority and you'd have to accept that it might not get merged since we 
want to use nested resource providers.


Either way we are going to need solid functional testing and that 
functional testing should be written against the API

Re: [openstack-dev] [puppet][puppet-ceph] missing dependencies for openstacklib::openstackclient in metadata.json

2017-09-25 Thread Alex Schultz

On Mon, Sep 25, 2017 at 5:42 AM, Emil Enemærke  wrote:
> There is also missing dependency for openstack/keystone, which is also used
> in ceph::rgw::keystone::auth line 63, 68, 75, 85
>
> On Mon, Sep 25, 2017 at 1:00 PM, Emil Enemærke  wrote:
>>
>> Hi
>>
>> In class ceph::rgw::keystone::auth there is an include for
>> ::openstacklib::openstackclient (line 61), but there is no dependency for it
>> in the metadata.json file.
>>

https://review.openstack.org/507141

Thanks,
-Alex

>> Cheers
>> Emil
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] User Committee Weekly IRC meeting reminder (9/25/2017)

2017-09-25 Thread Shamail Tahir

Hi everyone,

The User Committee will be meeting later today. The agenda can be found on
our wiki page[1] and the meeting details are on eavesdrop[2]. We hope to
see you there!

[1] https://wiki.openstack.org/wiki/Governance/Foundation/UserCommittee#
Meeting_Agenda.2FPrevious_Meeting_Logs
[2] http://eavesdrop.openstack.org/#User_Committee_Meeting

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] patches for simple typo fixes

Excerpts from Sean Dague's message of 2017-09-25 09:42:08 -0400:
> On 09/25/2017 09:28 AM, Doug Hellmann wrote:
> 
> > I'm less concerned with the motivation of someone submitting the
> > patches than I am with their effect. Just like the situation we had
> > with the bug squash days a year or so ago, if we had a poorly timed
> > set of these trivial patches coming in at our feature freeze deadline,
> > it would be extremely disruptive. So to me the fact that we're
> > seeing them in large batches means we have people who are not fully
> > engaged with the community and don't understand the impact they're
> > having. My goal is to reach out and try to improve that engagement,
> > and try to help them become more fully constructive contributors.
> 
> I think that quantifying how big that impact is would be good before
> deciding it needs to be a priority to act upon. There are lots of things
> that currently swamp our system, and on my back of the envelope math and
> spot checking on resources used, these really aren't a big concern.
> 
> But it's harder to see that until we really start accounting for CI time
> by project / person, and what kinds of things really do consume the system.
> 
> -Sean
> 

Yes, that will be part of the work of the new group looking into the
problem. The idea is to roll this specific problem up with a bunch of
other things related to new contributors so we have a group actively
thinking about better onboarding and engagement from a bunch of
different angles. Watch the SIG mailing list for details.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][docs][i18n][ptls] PDFs for project-specific docs with unified doc builds

[Topic tags added to subject line]

Excerpts from Ian Y. Choi's message of 2017-09-22 07:29:23 +0900:
> Hello,
> 
> "Build PDF docs from rst-based guide documents" [1] was implemented in Ocata
> cycle, and I have heard that there were a small conversation at the 
> Denver PTG
> regarding getting PDFs for project-specific docs setup to help translations.
> 
> In my opinion, it would be a nice idea to extend [1] to project-specific
> docs with unified doc builds. It seems that unified doc builds have been
> much enhanced with [2]. Now I think having PDF build functionalities in 
> unified
> doc builds would be a way to easily have PDFs for project-specific docs.
> 
> Would someone have any idea on this or help it with some good pointers?

The job-template for the unified doc build job is in
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/openstack-publish-jobs.yaml#n22

It uses the "docs" macro, which invokes the script
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh

I think we would want to place any new logic for extending the build in
that script, although we should coordinate any changes with the Zuul v3
rollout because as part of that I have seen some suggestions to change
the expected interface for building documentation and we want to make
sure any changes we make will work with the updated interface.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] patches for simple typo fixes

2017-09-25 Thread Sean Dague

On 09/25/2017 09:28 AM, Doug Hellmann wrote:

> I'm less concerned with the motivation of someone submitting the
> patches than I am with their effect. Just like the situation we had
> with the bug squash days a year or so ago, if we had a poorly timed
> set of these trivial patches coming in at our feature freeze deadline,
> it would be extremely disruptive. So to me the fact that we're
> seeing them in large batches means we have people who are not fully
> engaged with the community and don't understand the impact they're
> having. My goal is to reach out and try to improve that engagement,
> and try to help them become more fully constructive contributors.

I think that quantifying how big that impact is would be good before
deciding it needs to be a priority to act upon. There are lots of things
that currently swamp our system, and on my back of the envelope math and
spot checking on resources used, these really aren't a big concern.

But it's harder to see that until we really start accounting for CI time
by project / person, and what kinds of things really do consume the system.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Forum Reminder! Submissions due by Sept 29th


Argh! Sorry everyone. We changed the link:

http://forumtopics.openstack.org/cfp/create

Mea culpa!!


AMIT KUMAR JAISWAL 
September 25, 2017 at 8:34 AM
Hi Jimmy.

The above link you have given is broken and is saying "Internal Server 
Error".


Please re-check the link again.

Thanks
Amit Kumar Jaiswal
ᐧ

Amit Kumar Jaiswal
Mozilla Representative  | 
LinkedIn  | Portfolio 


New Delhi, India
M : +91-8081187743 | T : @AMIT_GKP | PGP : EBE7 39F0 0427 4A2C









Jimmy McArthur 
September 25, 2017 at 8:25 AM
Hello!

This is a friendly reminder that all proposed Forum session leaders 
must submit their abstracts at:


http://odsreg.openstack.org

before 11:59PM UTC on Friday, September 29th!

Cheers,
Jimmy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Forum Reminder! Submissions due by Sept 29th

2017-09-25 Thread AMIT KUMAR JAISWAL

Hi Jimmy.

The above link you have given is broken and is saying "Internal Server
Error".

Please re-check the link again.

Thanks
Amit Kumar Jaiswal
ᐧ

Amit Kumar Jaiswal
Mozilla Representative  | LinkedIn
 | Portfolio

New Delhi, India
M : +91-8081187743 | T : @AMIT_GKP | PGP : EBE7 39F0 0427 4A2C








On Mon, Sep 25, 2017 at 6:55 PM, Jimmy McArthur  wrote:

> Hello!
>
> This is a friendly reminder that all proposed Forum session leaders must
> submit their abstracts at:
>
> http://odsreg.openstack.org
>
> before 11:59PM UTC on Friday, September 29th!
>
> Cheers,
> Jimmy
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [Openstack-operators] Forum Reminder! Submissions due by Sept 29th


Argh! Sorry everyone. We changed the link:

http://forumtopics.openstack.org/cfp/create

Mea culpa!!


AMIT KUMAR JAISWAL 
September 25, 2017 at 8:34 AM
Hi Jimmy.

The above link you have given is broken and is saying "Internal Server 
Error".


Please re-check the link again.

Thanks
Amit Kumar Jaiswal
ᐧ

Amit Kumar Jaiswal
Mozilla Representative  | 
LinkedIn  | Portfolio 


New Delhi, India
M : +91-8081187743 | T : @AMIT_GKP | PGP : EBE7 39F0 0427 4A2C









Jimmy McArthur 
September 25, 2017 at 8:25 AM
Hello!

This is a friendly reminder that all proposed Forum session leaders 
must submit their abstracts at:


http://odsreg.openstack.org

before 11:59PM UTC on Friday, September 29th!

Cheers,
Jimmy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] patches for simple typo fixes

Excerpts from Sean Dague's message of 2017-09-25 08:24:18 -0400:
> On 09/25/2017 07:56 AM, Chris Dent wrote:
> > On Fri, 22 Sep 2017, Paul Belanger wrote:
> > 
> >> This is not a good example of encouraging anybody to contribute to the
> >> project.
> > 
> > Yes. This entire thread was a bit disturbing to read. Yes, I totally
> > agree that mass patches that do very little are a big cost to
> > reviewer and CI time but a lot of the responses sound like: "go away
> > you people who don't understand our special culture and our
> > important work".
> > 
> > That's not a good look.
> > 
> > Matt's original comment is good in and of itself: I saw a thing,
> > let's remember to curtail this stuff and do it in a nice way.
> > 
> > But then we generate a long thread about it. It's odd to me that
> > these threads sometimes draw more people out then discussions about
> > actually improving the projects.
> > 
> > It's also odd that if OpenStack were small and differently
> > structured, any self-respecting maintainer would be happy to see
> > a few typo fixes and generic cleanups. Anything to push the quality
> > forward is nice. But because of the way we do review and because of
> > the way we do CI these things are seen as expensive distractions[1].
> > We're old and entrenched enough now that our tooling enforces our
> > culture and our culture enforces our tooling.
> > 
> > [1] Note that I'm not denying they are expensive distractions nor
> > that they need to be managed as such. They are, but a lot of that
> > is on us.
> 
> I was trying to ignore the thread in the hopes it would die out quick.
> But torches and pitchforks all came out from the far corners, so I'm
> going to push back on that a bit.
> 
> I'm not super clear why there is always so much outrage about these
> patches. They are fixing real things. When I encounter them, I just
> approve them to get them merged quickly and not backing up the review
> queue, using more CI later if they need rebasing. They are fixing real
> things. Maybe there is a CI cost, but the faster they are merged the
> less likely someone else is to propose it in the future, which keeps
> down the CI cost. And if we have a culture of just fixing typos later,
> then we spend less CI time on patches the first time around with 2 or 3
> iterations catching typos.
> 
> I think the concern is the ascribed motive for why people are putting
> these up. That's fine to feel that people are stat padding (and that too
> many things are driven off metrics). But, honestly, that's only
> important if we make it important. Contributor stats are always going to
> be pretty much junk stats. They are counting things to be the same which
> are wildly variable in meaning (number of patches, number of Lines of
> Code).
> 
> My personal view is just merge things that fix things that are wrong,
> don't care why people are doing it. If it gets someone a discounted
> ticket somewhere, so be it. It's really not any skin off our back in the
> process.
> 
> If people are deeply concerned about CI resources, step one is to get
> some better accounting into the existing system to see where resources
> are currently spent, and how we could ensure that time is fairly spread
> around to ensure maximum productivity by all developers.
> 
> -Sean
> 

I'm less concerned with the motivation of someone submitting the
patches than I am with their effect. Just like the situation we had
with the bug squash days a year or so ago, if we had a poorly timed
set of these trivial patches coming in at our feature freeze deadline,
it would be extremely disruptive. So to me the fact that we're
seeing them in large batches means we have people who are not fully
engaged with the community and don't understand the impact they're
having. My goal is to reach out and try to improve that engagement,
and try to help them become more fully constructive contributors.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Forum Reminder! Submissions due by Sept 29th


Hello!

This is a friendly reminder that all proposed Forum session leaders must 
submit their abstracts at:


http://odsreg.openstack.org

before 11:59PM UTC on Friday, September 29th!

Cheers,
Jimmy



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[Openstack-operators] Forum Reminder! Submissions due by Sept 29th


Hello!

This is a friendly reminder that all proposed Forum session leaders must 
submit their abstracts at:


http://odsreg.openstack.org

before 11:59PM UTC on Friday, September 29th!

Cheers,
Jimmy



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [tc][nova][ironic][mogan] Evaluate Mogan project

2017-09-25 Thread Dmitry Tantsur


Hi!

Thanks for raising this. I was interested in the project for some time, but I 
never got a chance to wrap my head around. I also have a few concerns - please 
see inline.


On 09/25/2017 01:27 PM, Zhenguo Niu wrote:

Hi folks,

First of all, thanks for the audiences for Mogan project update in the TC room 
during Denver PTG. Here we would like to get more suggestions before we apply 
for inclusion.


Speaking only for myself, I find the current direction of one API+scheduler for 
vm/baremetal/container unfortunate. After containers management moved out to be 
a separated project Zun, baremetal with Nova and Ironic continues to be a pain 
point.


#. API
Only part of the Nova APIs and parameters can apply to baremetal instances, 
meanwhile for interoperable with other virtual drivers, bare metal specific APIs 
such as deploy time RAID, advanced partitions can not  be included. It's true 
that we can support various compute drivers, but the reality is that the support 
of each of hypervisor is not equal, especially for bare metals in a 
virtualization world. But I understand the problems with that as Nova was 
designed to provide compute resources(virtual machines) instead of bare metals.


A correction: any compute resources.

Nova works okay with bare metals. It's never going to work perfectly though, 
because we always have to find a common subset of features between VM and BM. 
RAID is a good example indeed. We have a solution for the future, but it's not 
going to satisfy everyone.


Now I have a question: to which extend do you plan to maintain the "cloud" 
nature of the API? Let's take RAID as an example. Ironic can apply a very 
generic or a very specific configuration. You can request "just RAID-5" or you 
can ask for specific disks to be combined in a specific combination. I believe 
the latter is not something we want to expose to cloud users, as it's not going 
to be a cloud any more.




#. Scheduler
Bare metal doesn't fit in to the model of 1:1 nova-compute to resource, as 
nova-compute processes can't be run on the inventory nodes themselves. That is 
to say host aggregates, availability zones and such things based on compute 
service(host) can't be applied to bare metal resources. And for grouping like 
anti-affinity, the granularity is also not same with virtual machines, bare 
metal users may want their HA instances not on the same failure domain instead 
of the node itself. Short saying, we can only get a rigid resource class only 
scheduling for bare metals.


It's not rigid. Okay, it's rigid, but it's not as rigid as what we used to have.

If you're going back to VCPUs-memory-disk triad, you're making it more rigid. Of 
these three, only memory has ever made practical sense for deployers. VCPUs is a 
bit subtle, as it depends on hyper-threading enabled/disabled, and I've never 
seen people using it too often.


But our local_gb thing is an outright lie. Of 20 disks a machine can easily 
have, which one do you report for local_gb? Well, in the best case people used 
ironic root device hints with ironic-inspector to figure out. Which is great, 
but requires ironic-inspector. In the worst case people just put random number 
there to make scheduling work. This is horrible, please make sure to not get 
back to it.


What I would love to see of a bare metal scheduling project is a scheduling 
based on inventory. I was thinking of being able to express things like "give me 
a node with 2 GPU of at least 256 CUDA cores each". Do you plan on this kind of 
things? This would truly mean flexible scheduling.


Which brings me to one of my biggest reservations about Mogan: I don't think 
copying Nova's architecture is a good idea overall. Particularly, I think you 
have flavors, which do not map at all into bare metal world IMO.





And most of the cloud providers in the market offering virtual machines and bare 
metals as separated resources, but unfortunately, it's hard to achieve this with 
one compute service.


Do you have proofs for the first statement? And do you imply public clouds? Our 
customers deploy hybrid environments, to my best knowledge. Nobody I know uses 
one compute service in the whole cloud anyway.


I heard people are deploying seperated Nova for virtual 
machines and bare metals with many downstream hacks to the bare metal 
single-driver Nova but as the changes to Nova would be massive and may invasive 
to virtual machines, it seems not practical to be upstream.


I think you're overestimated the problem. In TripleO we deploy separate virtual 
nova compute nodes. If ironic is enabled, its nova computes go to controllers. 
Then you can use host aggregates to split flavors between VM and BM. With 
resources classes it's even more trivial: you get this split naturally.




So we created Mogan [1] about one year ago, which aims to offer bare metals as 
first class resources to users with a set of bare metal specific API and a 
baremetal-centric scheduler(with Placement

Re: [openstack-dev] patches for simple typo fixes

2017-09-25 Thread Sean Dague

On 09/25/2017 07:56 AM, Chris Dent wrote:
> On Fri, 22 Sep 2017, Paul Belanger wrote:
> 
>> This is not a good example of encouraging anybody to contribute to the
>> project.
> 
> Yes. This entire thread was a bit disturbing to read. Yes, I totally
> agree that mass patches that do very little are a big cost to
> reviewer and CI time but a lot of the responses sound like: "go away
> you people who don't understand our special culture and our
> important work".
> 
> That's not a good look.
> 
> Matt's original comment is good in and of itself: I saw a thing,
> let's remember to curtail this stuff and do it in a nice way.
> 
> But then we generate a long thread about it. It's odd to me that
> these threads sometimes draw more people out then discussions about
> actually improving the projects.
> 
> It's also odd that if OpenStack were small and differently
> structured, any self-respecting maintainer would be happy to see
> a few typo fixes and generic cleanups. Anything to push the quality
> forward is nice. But because of the way we do review and because of
> the way we do CI these things are seen as expensive distractions[1].
> We're old and entrenched enough now that our tooling enforces our
> culture and our culture enforces our tooling.
> 
> [1] Note that I'm not denying they are expensive distractions nor
> that they need to be managed as such. They are, but a lot of that
> is on us.

I was trying to ignore the thread in the hopes it would die out quick.
But torches and pitchforks all came out from the far corners, so I'm
going to push back on that a bit.

I'm not super clear why there is always so much outrage about these
patches. They are fixing real things. When I encounter them, I just
approve them to get them merged quickly and not backing up the review
queue, using more CI later if they need rebasing. They are fixing real
things. Maybe there is a CI cost, but the faster they are merged the
less likely someone else is to propose it in the future, which keeps
down the CI cost. And if we have a culture of just fixing typos later,
then we spend less CI time on patches the first time around with 2 or 3
iterations catching typos.

I think the concern is the ascribed motive for why people are putting
these up. That's fine to feel that people are stat padding (and that too
many things are driven off metrics). But, honestly, that's only
important if we make it important. Contributor stats are always going to
be pretty much junk stats. They are counting things to be the same which
are wildly variable in meaning (number of patches, number of Lines of
Code).

My personal view is just merge things that fix things that are wrong,
don't care why people are doing it. If it gets someone a discounted
ticket somewhere, so be it. It's really not any skin off our back in the
process.

If people are deeply concerned about CI resources, step one is to get
some better accounting into the existing system to see where resources
are currently spent, and how we could ensure that time is fairly spread
around to ensure maximum productivity by all developers.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Garbage patches for simple typo fixes

2017-09-25 Thread Chris Dent


On Fri, 22 Sep 2017, Paul Belanger wrote:


This is not a good example of encouraging anybody to contribute to the project.


Yes. This entire thread was a bit disturbing to read. Yes, I totally
agree that mass patches that do very little are a big cost to
reviewer and CI time but a lot of the responses sound like: "go away
you people who don't understand our special culture and our
important work".

That's not a good look.

Matt's original comment is good in and of itself: I saw a thing,
let's remember to curtail this stuff and do it in a nice way.

But then we generate a long thread about it. It's odd to me that
these threads sometimes draw more people out then discussions about
actually improving the projects.

It's also odd that if OpenStack were small and differently
structured, any self-respecting maintainer would be happy to see
a few typo fixes and generic cleanups. Anything to push the quality
forward is nice. But because of the way we do review and because of
the way we do CI these things are seen as expensive distractions[1].
We're old and entrenched enough now that our tooling enforces our
culture and our culture enforces our tooling.

[1] Note that I'm not denying they are expensive distractions nor
that they need to be managed as such. They are, but a lot of that
is on us.

--
Chris Dent  (⊙＿⊙') https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][puppet-ceph] missing dependencies for openstacklib::openstackclient in metadata.json

2017-09-25 Thread Emil Enemærke

There is also missing dependency for openstack/keystone, which is also used
in ceph::rgw::keystone::auth line 63, 68, 75, 85

On Mon, Sep 25, 2017 at 1:00 PM, Emil Enemærke  wrote:

> Hi
>
> In class ceph::rgw::keystone::auth there is an include for 
> ::openstacklib::openstackclient
> (line 61), but there is no dependency for it in the metadata.json file.
>
> Cheers
> Emil
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc][nova][ironic][mogan] Evaluate Mogan project

2017-09-25 Thread Zhenguo Niu

Hi folks,

First of all, thanks for the audiences for Mogan project update in the TC
room during Denver PTG. Here we would like to get more suggestions before
we apply for inclusion.

Speaking only for myself, I find the current direction of one API+scheduler
for vm/baremetal/container unfortunate. After containers management moved
out to be a separated project Zun, baremetal with Nova and Ironic continues
to be a pain point.

#. API
Only part of the Nova APIs and parameters can apply to baremetal instances,
meanwhile for interoperable with other virtual drivers, bare metal specific
APIs such as deploy time RAID, advanced partitions can not be included.
It's true that we can support various compute drivers, but the reality is
that the support of each of hypervisor is not equal, especially for bare
metals in a virtualization world. But I understand the problems with that
as Nova was designed to provide compute resources(virtual machines) instead
of bare metals.

#. Scheduler
Bare metal doesn't fit in to the model of 1:1 nova-compute to resource, as
nova-compute processes can't be run on the inventory nodes themselves. That
is to say host aggregates, availability zones and such things based on
compute service(host) can't be applied to bare metal resources. And for
grouping like anti-affinity, the granularity is also not same with virtual
machines, bare metal users may want their HA instances not on the same
failure domain instead of the node itself. Short saying, we can only get a
rigid resource class only scheduling for bare metals.

And most of the cloud providers in the market offering virtual machines and
bare metals as separated resources, but unfortunately, it's hard to achieve
this with one compute service. I heard people are deploying seperated Nova
for virtual machines and bare metals with many downstream hacks to the bare
metal single-driver Nova but as the changes to Nova would be massive and
may invasive to virtual machines, it seems not practical to be upstream.

So we created Mogan [1] about one year ago, which aims to offer bare metals
as first class resources to users with a set of bare metal specific API and
a baremetal-centric scheduler(with Placement service). It was like an
experimental project at the beginning, but the outcome makes us believe
it's the right way. Mogan will fully embrace Ironic for bare metal
provisioning and with RSD server [2] introduced to OpenStack, it will be a
new world for bare metals, as with that we can compose hardware resources
on the fly.

Also, I would like to clarify the overlaps between Mogan and Nova, I bet
there must be some users who wants to use one API for the compute resources
management as they don't care about whether it's a virtual machine or a
bare metal server. Baremetal driver with Nova is still the right choice for
such users to get raw performance compute resources. On the contrary, Mogan
is for real bare metal users and cloud providers who wants to offer bare
metals as a separated resources.

Thank you for your time!

[1] https://wiki.openstack.org/wiki/Mogan
[2]
https://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-design-overview.html

--
Best Regards,
Zhenguo Niu
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet][puppet-ceph] missing dependencies for openstacklib::openstackclient in metadata.json

2017-09-25 Thread Emil Enemærke

Hi

In class ceph::rgw::keystone::auth there is an include for
::openstacklib::openstackclient (line 61), but there is no dependency for
it in the metadata.json file.

Cheers
Emil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] vGPUs support for Nova

2017-09-25 Thread Jay Pipes


On 09/25/2017 05:39 AM, Sahid Orentino Ferdjaoui wrote:

There is a desire to expose the vGPUs resources on top of Resource
Provider which is probably the path we should be going in the long
term. I was not there for the last PTG and you probably already made a
decision about moving in that direction anyway. My personal feeling is
that it is premature.

The nested Resource Provider work is not yet feature-complete and
requires more reviewer attention. If we continue in the direction of
Resource Provider, it will need at least 2 more releases to expose the
vGPUs feature and that without the support of NUMA, and with the
feeling of pushing something which is not stable/production-ready.

It's seems safer to first have the Resource Provider work well
finalized/stabilized to be production-ready. Then on top of something
stable we could start to migrate our current virt specific features
like NUMA, CPU Pinning, Huge Pages and finally PCI devices.

I'm talking about PCI devices in general because I think we should
implement the vGPU on top of our /pci framework which is production
ready and provides the support of NUMA.

The hardware vendors building their drivers using mdev and the /pci
framework currently understand only SRIOV but on a quick glance it
does not seem complicated to make it support mdev.

In the /pci framework we will have to:

* Update the PciDevice object fields to accept NULL value for
   'address' and add new field 'uuid'
* Update PciRequest to handle a new tag like 'vgpu_types'
* Update PciDeviceStats to also maintain pool of vGPUs

The operators will have to create alias(-es) and configure
flavors. Basically most of the logic is already implemented and the
method 'consume_request' is going to select the right vGPUs according
the request.

In /virt we will have to:

* Update the field 'pci_passthrough_devices' to also include GPUs
   devices.
* Update attach/detach PCI device to handle vGPUs

We have a few people interested in working on it, so we could
certainly make this feature available for Queen.

I can take the lead updating/implementing the PCI and libvirt driver
part, I'm sure Jianghua Wang will be happy to take the lead for the
virt XenServer part.

And I trust Jay, Stephen and Sylvain to follow the developments.


I understand the desire to get something in to Nova to support vGPUs, 
and I understand that the existing /pci modules represent the 
fastest/cheapest way to get there.


I won't block you from making any of the above changes, Sahid. I'll even 
do my best to review them. However, I will be primarily focusing this 
cycle on getting the nested resource providers work feature-complete for 
(at least) SR-IOV PF/VF devices.


The decision of whether to allow an approach that adds more to the 
existing /pci module is ultimately Matt's.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

2017-09-25 Thread Volodymyr Litovka


Hi Matt,

On 9/22/17 7:10 PM, Matt Riedemann wrote:

while this approach is ok in general, some comments from my side -
1. For a new instance, if the neutron network has a dns_domain set, 
use it. I'm not totally sure how we tell from the metadata API if it's 
a new instance or not, except when we're building the config drive, 
but that could be sorted out.
In some scenarios, ports can be created for VM but be detached until 
"right" time. For example, at the moment Nova don't reflect Neutron's 
port admin state to VM (long time was going to, but thanks to this 
discussion just filled a bug 
https://bugs.launchpad.net/nova/+bug/1719261 ). So, if you need VM with 
predefined port roles (with corresponding iptables rules), but, for some 
reasons, these ports should be DOWN, you need:


- create them before VM will be created
- pass their MAC addresses to VM in order to create corresponding udev 
naming rules and subsequent configuration

- but don't attach them

In such scenario, network with "dns_domain" parameter can be unavailable 
to VM since there are no attached ports from this network at the VM 
creation time.


And a second point: what I wanted to say is that "dns_domain" is a 
property, which is available only when Designate is in use. While it can 
be immanent property of network for use with dnsmasq's "--domain" 
parameter, in order to get useful responces for DHCP "domain" queries. 
Not too critical, but full integration with DNS don't always required 
while simple DHCP functionality is enough.



2. Otherwise use the dhcp_domain config option in nova.
Crazy idea is to get customization right here - if instance's "name" is 
FQDN itself (e.g. myhost.some.domain.here) then:

- ignore "dhcp_domain" and pass "name" unchanged as hostname to VM
- but use "hostname"-part of name (e.g. myhost) to register VM in Openstack

Thank you.

--
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] vGPUs support for Nova

2017-09-25 Thread Sahid Orentino Ferdjaoui

There is a desire to expose the vGPUs resources on top of Resource
Provider which is probably the path we should be going in the long
term. I was not there for the last PTG and you probably already made a
decision about moving in that direction anyway. My personal feeling is
that it is premature.

The nested Resource Provider work is not yet feature-complete and
requires more reviewer attention. If we continue in the direction of
Resource Provider, it will need at least 2 more releases to expose the
vGPUs feature and that without the support of NUMA, and with the
feeling of pushing something which is not stable/production-ready.

It's seems safer to first have the Resource Provider work well
finalized/stabilized to be production-ready. Then on top of something
stable we could start to migrate our current virt specific features
like NUMA, CPU Pinning, Huge Pages and finally PCI devices.

I'm talking about PCI devices in general because I think we should
implement the vGPU on top of our /pci framework which is production
ready and provides the support of NUMA.

The hardware vendors building their drivers using mdev and the /pci
framework currently understand only SRIOV but on a quick glance it
does not seem complicated to make it support mdev.

In the /pci framework we will have to:

* Update the PciDevice object fields to accept NULL value for
  'address' and add new field 'uuid'
* Update PciRequest to handle a new tag like 'vgpu_types'
* Update PciDeviceStats to also maintain pool of vGPUs

The operators will have to create alias(-es) and configure
flavors. Basically most of the logic is already implemented and the
method 'consume_request' is going to select the right vGPUs according
the request.

In /virt we will have to:

* Update the field 'pci_passthrough_devices' to also include GPUs
  devices.
* Update attach/detach PCI device to handle vGPUs

We have a few people interested in working on it, so we could
certainly make this feature available for Queen.

I can take the lead updating/implementing the PCI and libvirt driver
part, I'm sure Jianghua Wang will be happy to take the lead for the
virt XenServer part.

And I trust Jay, Stephen and Sylvain to follow the developments.

s.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] notification update week 39

2017-09-25 Thread Balazs Gibizer


Hi,

Here is the status update / focus settings mail for w39.

Bugs

[Medium] https://bugs.launchpad.net/nova/+bug/1699115 api.fault
notification is never emitted
We still have to figure out what is the expected behavior here based on:
http://lists.openstack.org/pipermail/openstack-dev/2017-June/118639.html
A proposed a patch with on of the possible solution and I hope this will
help starting some discussion.
* https://review.openstack.org/#/c/505164/ Remove dead code of 
api.fault notification sending


[Medium] https://bugs.launchpad.net/nova/+bug/1718485 
instance.live.migration.force.complete is not a versioned notification 
and not whitelisted
Solution is simple and ready for review: 
https://review.openstack.org/#/c/506104/


[Undecided] https://bugs.launchpad.net/nova/+bug/1717917 
test_resize_server_error_and_reschedule_was_failed failing due to 
missing notification
Test stability issue. The fix only needs a second +2 
https://review.openstack.org/#/c/504930/


[Undecided] https://bugs.launchpad.net/nova/+bug/1718226 bdm is 
wastefully loaded for versioned instance notifications
This is a bug to follow up of the closed bp 
https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
The fix removes lot of unnecessary BDM loading from the notification 
code path: https://review.openstack.org/#/q/topic:bug/1718226


[High] https://bugs.launchpad.net/nova/+bug/1706563
TestRPC.test_cleanup_notifier_null fails with timeout
[High] https://bugs.launchpad.net/nova/+bug/1685333 Fatal Python error:
Cannot recover from stack overflow. - in py35 unit test job
The first bug is just a duplicate of the second. It seems the TetRPC
test suite has a way to end up in an infinite recusion.
I don't know about a way to reproduce it localy or to change the gate
env so that python prints out the full stack trace to see where the
problematic call is. Also adding extra log messages won't help as a
timed out test doesn't have the log messages printed to the logs. So
this bug is pretty stuck.

Versioned notification transformation
-
There are 3 transformation patches that only need a second +2:
* https://review.openstack.org/#/c/396210 Transform aggregate.add_host 
notification
* https://review.openstack.org/#/c/396211 Transform 
aggregate.remove_host notification
* https://review.openstack.org/#/c/503089 Add instance.interface_attach 
notification



Small improvements
--
* https://review.openstack.org/#/q/topic:refactor-notification-samples
Factor out duplicated notification sample data
This is a start of a longer patch series to deduplicate notification
sample data. The third patch already shows how much sample data can be
deleted from nova tree. We added a minimal hand rolled json ref
implementation to notification sample test as the existing python json
ref implementations are not well maintained.


Weekly meeting
--
Next subteam meeting will be held on 26th of September, Tuesday 17:00 
UTC on openstack-meeting-4.

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20170926T17


Cheers,
gibi




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][oslo.messaging][femdc]Topic names for every resource type RPC endpoint

2017-09-25 Thread Miguel Angel Ajo Pelayo

Yeah, you could may be segment messages by zones/cells etc.

Or group resources by buckets, for example taking the last 2-3 bytes of
each object identifier.

But you may need to do the math on how that's going to work, the more
objects an agent needs to process, the more likely that it will receive
unnecessary objects in that case.

The ideal, anyway is single object subscription (as long as the client and
rabbit would handle such scenario well)


On Sun, Sep 24, 2017 at 11:45 PM, Matthieu Simonin <
matthieu.simo...@inria.fr> wrote:

> Thanks Miguel for your feedback.
>
> I'll definetely dig more into this.
> Having a lot of messages broadcasted to all the neutron agents is not
> something you want especially in the context of femdc[1].
>
> Best,
>
> Matt
>
> [1]: https://wiki.openstack.org/wiki/Fog_Edge_Massively_Distributed_Clouds
>
> - Mail original -
> > De: "Miguel Angel Ajo Pelayo" 
> > À: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Envoyé: Mercredi 20 Septembre 2017 11:15:12
> > Objet: Re: [openstack-dev] [neutron][oslo.messaging][femdc]Topic names
> for every resource type RPC endpoint
> >
> > I wrote those lines.
> >
> > At that time, I tried a couple a publisher and a receiver at that scale.
> It
> > was the receiver side what crashed trying to subscribe, the sender was
> > completely fine.
> >
> > Sadly I don't keep the test examples, I should have stored them in github
> > or something. It shouldn't be hard to replicate though if you follow the
> > oslo_messaging docs.
> >
> >
> >
> > On Wed, Sep 20, 2017 at 9:58 AM, Matthieu Simonin <
> matthieu.simo...@inria.fr
> > > wrote:
> >
> > > Hello,
> > >
> > > In the Neutron docs about RPCs and Callbacks system, it is said[1] :
> > >
> > > "With the underlying oslo_messaging support for dynamic topics on the
> > > receiver
> > > we cannot implement a per “resource type + resource id” topic, rabbitmq
> > > seems
> > > to handle 1’s of topics without suffering, but creating 100’s of
> > > oslo_messaging receivers on different topics seems to crash."
> > >
> > > I wonder if this statements still holds for the new transports
> supported in
> > > oslo.messaging (e.g Kafka, AMQP1.0) or if it's more a design
> limitation.
> > > I'm interested in any relevant docs/links/reviews on the "topic" :).
> > >
> > > Moreover, I'm curious to get an idea on how many different resources a
> > > Neutron
> > > Agent would have to manage and thus how many oslo_messaging receivers
> > > would be
> > > required (e.g how many security groups a neutron agent has to manage
> ?) -
> > > at
> > > least the order of magnitude.
> > >
> > > Best,
> > >
> > > Matt
> > >
> > >
> > >
> > > [1]: https://docs.openstack.org/neutron/latest/contributor/
> > > internals/rpc_callbacks.html#topic-names-for-every-
> > > resource-type-rpc-endpoint
> > >
> > > 
> __
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

2017-09-25 Thread Arne Wiebalck

Ah, nice, wasn’t aware. Mateusz is one of the Horizon experts here at CERN I 
was referring to :)

On 25 Sep 2017, at 10:41, Massimo Sgaravatto 
> wrote:

Just found that there is already this one:

https://bugs.launchpad.net/horizon/+bug/1717342

2017-09-25 10:28 GMT+02:00 Saverio Proto 
>:
Yes I am interested. Are you going to push them to gerrit ?
Should we open a bug to track this change into Horizon ?

massimo do you want to open the bug on Launchpad ? So if Arne pushed
the patches on gerrit we can link them to the bug. I pointed
robcresswell to this thread, he is reading us.

thanks !

Saverio

2017-09-25 10:13 GMT+02:00 Arne Wiebalck 
>:
> Massimo, Saverio,
>
> We faced the same issue and have created patches for Horizon to display
> - the per volume quota in the volume request panel, and also
> - additional information about the volume type (like IOPS and throughput 
> limits, intended usage etc.)
>
> The patches will need some polishing before being sent upstream (I’ll need
> need to cross-check with our Horizon experts), but we use them in prod since
> quite a while and are happy to already share patch files if you’re interested.
>
> Cheers,
>  Arne
>
>
>
>> On 25 Sep 2017, at 09:58, Saverio Proto 
>> > wrote:
>>
>> I am pinging on IRC robcresswell from the Horizon project. He is still
>> PTL I think.
>> If you are on IRC please join #openstack-horizon.
>>
>> We should ask the Horizon PTL how to get this feature request into
>> implementation.
>>
>> With the command line interface, can you already see the two different
>> quotas for the two different volume types ? Can you paste an example
>> output from the CLI ?
>>
>> thank you
>>
>> Saverio
>>
>>
>> 2017-09-25 9:55 GMT+02:00 Massimo Sgaravatto 
>> >:
>>> We are currently running Mitaka (preparing to update to Ocata). I see the
>>> same behavior on an Ocata based testbed
>>>
>>> Thanks, Massimo
>>>
>>> 2017-09-25 9:50 GMT+02:00 Saverio Proto 
>>> >:

 Hello Massimo,

 what is your version of Openstack ??

 thank you

 Saverio

 2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto
 >:
> Hi
>
>
> In our OpenStack cloud we have two backends for Cinder (exposed using
> two
> volume types), and we set different quotas for these two volume types.
>
> The problem happens when a user, using the dashboard, tries to create a
> volume using a volume type for which the project quota is over:
>
> - the reported error message simply reports "unable to create volume",
> without mentioning that the problem is with quota
>
> - (by default) the dashboard only shows the overall Cinder quota (and
> not
> the quota per volume)
>
>
> Do you know if it possible in some to expose on the dashboard the cinder
> quota per volume type ?
>
>
> Thanks, Massimo
>
>
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>>>
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> --
> Arne Wiebalck
> CERN IT
>


--
Arne Wiebalck
CERN IT

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [openstack-dev] [docs][ptls][install] Install guide vs. tutorial

2017-09-25 Thread Alexandra Settle

 
> I completely agree consistency is more important, than bike shedding over 
the
> name :)
> To be honest, it would be easier to change everything to ‘guide’ – seeing 
as
> all our URLs are ‘install-guide’.
> But that’s the lazy in me speaking.
> 
> Industry wise – there does seem to be more of a trend towards ‘guide’ 
rather
> than ‘tutorial’. Although, that is at a cursory glance.
> 
> I am happy to investigate further, if this matter is of some contention to
> people?

This is the first time I'm hearing about "Install Tutorial". I'm also lazy, 
+1
with sticking to install guide.

Just to clarify: https://docs.openstack.org/install-guide/ The link is 
“install-guide” but the actual title on the page is “OpenStack Installation 
Tutorial”.

Apologies if I haven’t been clear enough in this thread! Context always helps :P

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

Just found that there is already this one:

https://bugs.launchpad.net/horizon/+bug/1717342

2017-09-25 10:28 GMT+02:00 Saverio Proto :

> Yes I am interested. Are you going to push them to gerrit ?
> Should we open a bug to track this change into Horizon ?
>
> massimo do you want to open the bug on Launchpad ? So if Arne pushed
> the patches on gerrit we can link them to the bug. I pointed
> robcresswell to this thread, he is reading us.
>
> thanks !
>
> Saverio
>
> 2017-09-25 10:13 GMT+02:00 Arne Wiebalck :
> > Massimo, Saverio,
> >
> > We faced the same issue and have created patches for Horizon to display
> > - the per volume quota in the volume request panel, and also
> > - additional information about the volume type (like IOPS and throughput
> limits, intended usage etc.)
> >
> > The patches will need some polishing before being sent upstream (I’ll
> need
> > need to cross-check with our Horizon experts), but we use them in prod
> since
> > quite a while and are happy to already share patch files if you’re
> interested.
> >
> > Cheers,
> >  Arne
> >
> >
> >
> >> On 25 Sep 2017, at 09:58, Saverio Proto  wrote:
> >>
> >> I am pinging on IRC robcresswell from the Horizon project. He is still
> >> PTL I think.
> >> If you are on IRC please join #openstack-horizon.
> >>
> >> We should ask the Horizon PTL how to get this feature request into
> >> implementation.
> >>
> >> With the command line interface, can you already see the two different
> >> quotas for the two different volume types ? Can you paste an example
> >> output from the CLI ?
> >>
> >> thank you
> >>
> >> Saverio
> >>
> >>
> >> 2017-09-25 9:55 GMT+02:00 Massimo Sgaravatto <
> massimo.sgarava...@gmail.com>:
> >>> We are currently running Mitaka (preparing to update to Ocata). I see
> the
> >>> same behavior on an Ocata based testbed
> >>>
> >>> Thanks, Massimo
> >>>
> >>> 2017-09-25 9:50 GMT+02:00 Saverio Proto :
> 
>  Hello Massimo,
> 
>  what is your version of Openstack ??
> 
>  thank you
> 
>  Saverio
> 
>  2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto
>  :
> > Hi
> >
> >
> > In our OpenStack cloud we have two backends for Cinder (exposed using
> > two
> > volume types), and we set different quotas for these two volume
> types.
> >
> > The problem happens when a user, using the dashboard, tries to
> create a
> > volume using a volume type for which the project quota is over:
> >
> > - the reported error message simply reports "unable to create
> volume",
> > without mentioning that the problem is with quota
> >
> > - (by default) the dashboard only shows the overall Cinder quota (and
> > not
> > the quota per volume)
> >
> >
> > Do you know if it possible in some to expose on the dashboard the
> cinder
> > quota per volume type ?
> >
> >
> > Thanks, Massimo
> >
> >
> >
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >
> >>>
> >>>
> >>
> >> ___
> >> OpenStack-operators mailing list
> >> OpenStack-operators@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > --
> > Arne Wiebalck
> > CERN IT
> >
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [octavia] haproxy fails to receive datagram

2017-09-25 Thread Yipei Niu

Hi, all,

I encounter some problems when using Octavia. After installing octavia with
devstack, I create a load balancer named lb1 (VIP: 10.0.1.9, IP of VRRP
port: 10.0.1.3) for a subnet (10.0.1.0/24), then a listener, a pool, and
two members. All the resources are created successfully. The two members
(VMs) reside in the same subnet, whose IP are 10.0.1.6 and 10.0.1.7,
respectively. To simulate a web server in each VM, I run "while true; do
echo -e "HTTP/1.0 200 OK\r\n\r\nWelcome to $VM_IP" | sudo nc -l -p 80;done"
to listen on port 80 and return the VM's IP if the request is accepted. I
run "sudo ip netns exec qdhcp- curl -v $VM_IP" to send requests to VMs,
the "web servers" in VMs work (already added corresponding security rules
to the VMs). Then I tried to run "sudo ip netns exec qdhcp- curl -v
$VIP" to send requests, the VMs do not respond, and finally returns a
timeout error.

The configuration details in local.conf are as follows.

*[[local|localrc]]*

*DATABASE_PASSWORD=password*
*RABBIT_PASSWORD=password*
*SERVICE_PASSWORD=password*
*SERVICE_TOKEN=password*
*ADMIN_PASSWORD=password*

*HOST_IP=192.168.56.9*

*LOGFILE=/opt/stack/logs/stack.sh.log*
*VERBOSE=True*
*LOG_COLOR=True*
*SCREEN_LOGDIR=/opt/stack/logs*

*# Neutron LBaaS*
*enable_plugin neutron-lbaas https://github.com/openstack/neutron-lbaas.git
*
*enable_plugin octavia https://github.com/openstack/octavia.git
*
*ENABLED_SERVICES+=,q-lbaasv2*
*ENABLED_SERVICES+=,octavia,o-cw,o-hk,o-hm,o-api*

*disable_service horizon*
*disable_service tempest*

To investigate the source of the error, I logon to the amphora. The details
of interfaces of amphora_haproxy network namespace are as follows.

*1: lo:  mtu 65536 qdisc noop state DOWN group default qlen 1*
*link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00*
*3: eth1:  mtu 1450 qdisc pfifo_fast state
UP group default qlen 1000*
*link/ether fa:16:3e:42:bf:d9 brd ff:ff:ff:ff:ff:ff*
*inet 10.0.1.3/24  brd 10.0.1.255 scope global eth1*
*   valid_lft forever preferred_lft forever*
*inet 10.0.1.9/24  brd 10.0.1.255 scope global
secondary eth1:0*
*   valid_lft forever preferred_lft forever*
*inet6 fe80::f816:3eff:fe42:bfd9/64 scope link*
*   valid_lft forever preferred_lft forever*

So I run "sudo ip netns exec amphora-haproxy tcpdump -i eth1 -nn 'tcp'" to
check whether amphora receive the request. The details are as follows.

*tcpdump: verbose output suppressed, use -v or -vv for full protocol decode*
*listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes*
*^C06:11:49.048973 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
1717936594, win 28200, options [mss 1410,sackOK,TS val 28032309 ecr
0,nop,wscale 7], length 0*
*06:11:50.031976 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
1717936594, win 28200, options [mss 1410,sackOK,TS val 28032559 ecr
0,nop,wscale 7], length 0*
*06:11:52.026565 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
1717936594, win 28200, options [mss 1410,sackOK,TS val 28033060 ecr
0,nop,wscale 7], length 0*
*06:11:56.002577 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
1717936594, win 28200, options [mss 1410,sackOK,TS val 28034062 ecr
0,nop,wscale 7], length 0*
*06:12:03.909721 IP 10.0.1.2.33700 > 10.0.1.9.80: Flags [S], seq
1717936594, win 28200, options [mss 1410,sackOK,TS val 28036064 ecr
0,nop,wscale 7], length 0*

Based on the trace, we can see that amphora do receive the request, but
haproxy does not send handshake datagram to respond. Then, to see whether
haproxy in the amphora listens on the right IP and port, I print
/var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57/haproxy.cfg in the
console and see the following info.

*# Configuration for lb1*
*global*
*daemon*
*user nobody*
*log /dev/log local0*
*log /dev/log local1 notice*
*stats socket
/var/lib/octavia/ec5ee7c5-7474-424f-9f44-71b338cf3e57.sock mode 0666 level
user*

*defaults*
*log global*
*retries 3*
*option redispatch*
*timeout connect 5000*
*timeout client 5*
*timeout server 5*

*frontend ec5ee7c5-7474-424f-9f44-71b338cf3e57*
*option httplog*
*bind 10.0.1.9:80 *
*mode http*
*default_backend 40537c80-979d-49c9-b3ae-8504812c0f42*

*backend 40537c80-979d-49c9-b3ae-8504812c0f42*
*mode http*
*balance roundrobin*
*server 73dc9a1d-1e92-479b-a6f3-8debd0ea17b8 10.0.1.6:80
 weight 1*
*server 4cdca33f-9cde-4ac2-a5bd-550d3e65f0f2 10.0.1.7:80
 weight 1*

Next, I print the info of all the running haproxy process in the console
and copy it below.

*root  2367  0.0  0.0   4228   740 ?Ss   07:14   0:00
/usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p
/run/haproxy.pid*
*haproxy   2370  0.0  0.5  37692  5340 ?S07:14   0:00

Re: [openstack-dev] [octavia][sqlalchemy] Specify 'extend_existing=True' to redefine options and columns on an existing Table object.

2017-09-25 Thread Pradeep Singh

I have sorted out the issue. There was fault in my code.
Thanks for the time.

On Sat, Sep 23, 2017 at 2:48 PM, Pradeep Singh 
wrote:

> Hello All,
>
> I added two tables schema in patch https://review.
> openstack.org/#/c/486499/, and when i run unit tests i am getting error
> which says,
> InvalidRequestError: Table 'provisioning_status' is already defined for
> this MetaData instance. Specify 'extend_existing=True' to redefine options
> and columns on an existing Table object.
>
> Log location: http://logs.openstack.org/99/486499/3/check/gate-octavia-
> python27-ubuntu-xenial/a7924bc/console.html
>
> Can any body help me.
>
> Thanks,
> Pradeep Singh
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

2017-09-25 Thread Arne Wiebalck

Massimo, Saverio,

We faced the same issue and have created patches for Horizon to display
- the per volume quota in the volume request panel, and also
- additional information about the volume type (like IOPS and throughput 
limits, intended usage etc.)

The patches will need some polishing before being sent upstream (I’ll need
need to cross-check with our Horizon experts), but we use them in prod since
quite a while and are happy to already share patch files if you’re interested.

Cheers,
 Arne



> On 25 Sep 2017, at 09:58, Saverio Proto  wrote:
> 
> I am pinging on IRC robcresswell from the Horizon project. He is still
> PTL I think.
> If you are on IRC please join #openstack-horizon.
> 
> We should ask the Horizon PTL how to get this feature request into
> implementation.
> 
> With the command line interface, can you already see the two different
> quotas for the two different volume types ? Can you paste an example
> output from the CLI ?
> 
> thank you
> 
> Saverio
> 
> 
> 2017-09-25 9:55 GMT+02:00 Massimo Sgaravatto :
>> We are currently running Mitaka (preparing to update to Ocata). I see the
>> same behavior on an Ocata based testbed
>> 
>> Thanks, Massimo
>> 
>> 2017-09-25 9:50 GMT+02:00 Saverio Proto :
>>> 
>>> Hello Massimo,
>>> 
>>> what is your version of Openstack ??
>>> 
>>> thank you
>>> 
>>> Saverio
>>> 
>>> 2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto
>>> :
 Hi
 
 
 In our OpenStack cloud we have two backends for Cinder (exposed using
 two
 volume types), and we set different quotas for these two volume types.
 
 The problem happens when a user, using the dashboard, tries to create a
 volume using a volume type for which the project quota is over:
 
 - the reported error message simply reports "unable to create volume",
 without mentioning that the problem is with quota
 
 - (by default) the dashboard only shows the overall Cinder quota (and
 not
 the quota per volume)
 
 
 Do you know if it possible in some to expose on the dashboard the cinder
 quota per volume type ?
 
 
 Thanks, Massimo
 
 
 
 
 
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
>> 
>> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

--
Arne Wiebalck
CERN IT

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

Yes. From the CLI I have the info. E.g in the following example I have
three volume-types (ceph, iscsi-infnpd, gluster) and for two of them a
quota was set

Thanks, Massimo

[sgaravat@lxsgaravat ~]$ cinder quota-usage ${OS_PROJECT_ID}
+++--+---+
| Type   | In_use | Reserved | Limit |
+++--+---+
| backup_gigabytes   | 0  | 0| 1000  |
| backups| 0  | 0| 10|
| gigabytes  | 120| 0| 300   |
| gigabytes_ceph | 85 | 0| 100   |
| gigabytes_gluster  | 0  | 0| -1|
| gigabytes_iscsi-infnpd | 35 | 0| 200   |
| per_volume_gigabytes   | 0  | 0| 1000  |
| snapshots  | 0  | 0| 10|
| snapshots_ceph | 0  | 0| -1|
| snapshots_gluster  | 0  | 0| -1|
| snapshots_iscsi-infnpd | 0  | 0| -1|
| volumes| 8  | 0| 20|
| volumes_ceph   | 6  | 0| -1|
| volumes_gluster| 0  | 0| -1|
| volumes_iscsi-infnpd   | 2  | 0| -1|
+++--+---+
[sgaravat@lxsgaravat ~]$


2017-09-25 9:58 GMT+02:00 Saverio Proto :

> I am pinging on IRC robcresswell from the Horizon project. He is still
> PTL I think.
>  If you are on IRC please join #openstack-horizon.
>
> We should ask the Horizon PTL how to get this feature request into
> implementation.
>
> With the command line interface, can you already see the two different
> quotas for the two different volume types ? Can you paste an example
> output from the CLI ?
>
> thank you
>
> Saverio
>
>
> 2017-09-25 9:55 GMT+02:00 Massimo Sgaravatto  >:
> > We are currently running Mitaka (preparing to update to Ocata). I see the
> > same behavior on an Ocata based testbed
> >
> > Thanks, Massimo
> >
> > 2017-09-25 9:50 GMT+02:00 Saverio Proto :
> >>
> >> Hello Massimo,
> >>
> >> what is your version of Openstack ??
> >>
> >> thank you
> >>
> >> Saverio
> >>
> >> 2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto
> >> :
> >> > Hi
> >> >
> >> >
> >> > In our OpenStack cloud we have two backends for Cinder (exposed using
> >> > two
> >> > volume types), and we set different quotas for these two volume types.
> >> >
> >> > The problem happens when a user, using the dashboard, tries to create
> a
> >> > volume using a volume type for which the project quota is over:
> >> >
> >> > - the reported error message simply reports "unable to create volume",
> >> > without mentioning that the problem is with quota
> >> >
> >> > - (by default) the dashboard only shows the overall Cinder quota (and
> >> > not
> >> > the quota per volume)
> >> >
> >> >
> >> > Do you know if it possible in some to expose on the dashboard the
> cinder
> >> > quota per volume type ?
> >> >
> >> >
> >> > Thanks, Massimo
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > ___
> >> > OpenStack-operators mailing list
> >> > OpenStack-operators@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack-operators
> >> >
> >
> >
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack] FW: [xenserver-ocata] ceilometer compute error Rrd_interface.Internal_error

2017-09-25 Thread Adhi Priharmanto

Hi Jianghua,

Thanks for your response and attention. For the error of  "
Rrd_interface.Internal_error" , I was installed this update on my xenserver
(https://support.citrix.com/article/CTX225676) , and RRD error now was gone
from ceilometer logs.

I'm still at ocata release , here is my openstack package list on my
compute node

> [root@cmp1-oc-srg ceilometer]# rpm -qa |grep openstack
> centos-release-openstack-ocata-1-1.el7.noarch
> openstack-selinux-0.7.13-2.el7.noarch
> openstack-nova-compute-15.0.0-1.el7.noarch
> openstack-neutron-common-10.0.1-1.el7.noarch
> openstack-ceilometer-polling-8.1.0-1.el7.noarch
> openstack-ceilometer-compute-8.1.0-1.el7.noarch
> openstack-neutron-openvswitch-10.0.1-1.el7.noarch
> openstack-neutron-ml2-10.0.1-1.el7.noarch
> openstack-ceilometer-common-8.1.0-1.el7.noarch
> openstack-nova-common-15.0.0-1.el7.noarch
> openstack-neutron-10.0.1-1.el7.noarch


And here's is my logs as your request
https://paste.fedoraproject.org/paste/Yv8DoGbLziE0~luY6qwbhQ

I still find error at ceilometer-compute logs like this one

2017-09-25 14:31:07.041 9048 INFO ceilometer.agent.manager [-] Polling
> pollster disk.device.iops in the context of all_pollsters
> 2017-09-25 14:31:07.042 9048 ERROR ceilometer.agent.manager [-] Prevent
> pollster disk.device.iops from polling [,  mon-srg>, ] on source all_pollsters anymore!
> 2017-09-25 14:31:07.043 9048 INFO ceilometer.agent.manager [-] Polling
> pollster disk.device.latency in the context of all_pollsters
> 2017-09-25 14:31:07.044 9048 ERROR ceilometer.agent.manager [-] Prevent
> pollster disk.device.latency from polling [,  mon-srg>, ] on source all_pollsters anymore!


I think this error maybe make some of measurement won't works at gnocchi,
and also some of gnocchi metric won't show the unit

[root@localhost ~]# gnocchi metric list |grep disk.device.iops
>
> +---+-+-+---++
> | id| archive_policy/name | name
>  | unit  | resource_id|
>
> +---+-+-+---++
>
>> | 0062d222-2874-4a19-be34-a5bee3051d21 | low |
>> disk.device.iops| None  |
>> 7b089e8e-5be7-599a-b279-15a8129f7bdd |
>
> | 3dc249e4-006d-47a3-935c-58e571ba086c | low |
>> disk.device.iops| None  |
>> 0efeccca-8313-5aec-a1e2-955e091419f9 |
>
> | c2c19329-1709-4165-bdea-3bcf81c5d9d4 | low |
>> disk.device.iops| None  |
>> 78aa9c1e-b199-551c-b295-fecb237639fc |
>
> | cfa1c4bf-591e-4229-bb76-7607fcba640e | low |
>> disk.device.iops| None  |
>> bdf98233-442b-5fe4-aa02-ba567e487dcc |
>
>

Any suggest about the last error of ceilometer-compute  ?

On Mon, Sep 25, 2017 at 1:02 PM, Jianghua Wang 
wrote:

> Adhi,
>
>   Do you still have this problem?
>
>   The following errors may be caused due to this xvda disk doesn’t exist.
> Did you see any issue from the nova?
>
> Rrd.Invalid_data_source(\\"vbd_xvda_read\\")")
>
>
>
> If you are still suffering from this issue, can you send me the following
> log files:
>
> 1.   Log files for the nova-compute and ceilometer services located
> in nova compute node.
>
> 2.   The /var/log/xensource.log from dom0 where the compute node is
> running on.
>
>
>
> And can you confirm the release version? From the title –
> [xenserver-ocata], it may be ocata. But by checking the code line from the
> log, it’s probably already in pike.
>
>
>
> Regards,
>
> Jianghua
>
>
>
> *From:* wjh_fresh [mailto:wjh_fr...@163.com]
> *Sent:* Monday, September 11, 2017 1:38 PM
> *To:* Jianghua Wang 
> *Subject:* Fw: [Openstack] [xenserver-ocata] ceilometer compute error
> Rrd_interface.Internal_error
>
>
>
> 发件人： Adhi Priharmanto 
>
> 发送日期： 2017年09月08日 21:56
>
> 收件人： openstack 
>
> 抄送人：
>
> 主题： [Openstack] [xenserver-ocata] ceilometer compute error
> Rrd_interface.Internal_error
>
> Hi all,
>
>
>
> I'm add ceilometer into my compute node, when I watch the ceilometer
> compute log , I found this error .
>
> 2017-09-08 20:21:59.214 14826 ERROR ceilometer.compute.pollsters [-] Could
> not get disk.device.write.requests.rate events for
> 59277f16-6ccf-4b5a-9204-c75c8a97dff7: ['INTERNAL_ERROR',
> 'Rrd_interface.Internal_error("Rrd.Invalid_data_source(\\"
> vbd_xvda_read\\")")']: Failure: ['INTERNAL_ERROR',
> 'Rrd_interface.Internal_error("Rrd.Invalid_data_source(\\"
> vbd_xvda_read\\")")']
> 2017-09-08 20:21:59.214 14826 ERROR ceilometer.compute.pollsters Traceback
> (most recent call last):
> 2017-09-08 20:21:59.214 14826 ERROR ceilometer.compute.pollsters   File
>

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

2017-09-25 Thread Saverio Proto

I am pinging on IRC robcresswell from the Horizon project. He is still
PTL I think.
 If you are on IRC please join #openstack-horizon.

We should ask the Horizon PTL how to get this feature request into
implementation.

With the command line interface, can you already see the two different
quotas for the two different volume types ? Can you paste an example
output from the CLI ?

thank you

Saverio


2017-09-25 9:55 GMT+02:00 Massimo Sgaravatto :
> We are currently running Mitaka (preparing to update to Ocata). I see the
> same behavior on an Ocata based testbed
>
> Thanks, Massimo
>
> 2017-09-25 9:50 GMT+02:00 Saverio Proto :
>>
>> Hello Massimo,
>>
>> what is your version of Openstack ??
>>
>> thank you
>>
>> Saverio
>>
>> 2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto
>> :
>> > Hi
>> >
>> >
>> > In our OpenStack cloud we have two backends for Cinder (exposed using
>> > two
>> > volume types), and we set different quotas for these two volume types.
>> >
>> > The problem happens when a user, using the dashboard, tries to create a
>> > volume using a volume type for which the project quota is over:
>> >
>> > - the reported error message simply reports "unable to create volume",
>> > without mentioning that the problem is with quota
>> >
>> > - (by default) the dashboard only shows the overall Cinder quota (and
>> > not
>> > the quota per volume)
>> >
>> >
>> > Do you know if it possible in some to expose on the dashboard the cinder
>> > quota per volume type ?
>> >
>> >
>> > Thanks, Massimo
>> >
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > OpenStack-operators mailing list
>> > OpenStack-operators@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> >
>
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

We are currently running Mitaka (preparing to update to Ocata). I see the
same behavior on an Ocata based testbed

Thanks, Massimo

2017-09-25 9:50 GMT+02:00 Saverio Proto :

> Hello Massimo,
>
> what is your version of Openstack ??
>
> thank you
>
> Saverio
>
> 2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto  >:
> > Hi
> >
> >
> > In our OpenStack cloud we have two backends for Cinder (exposed using two
> > volume types), and we set different quotas for these two volume types.
> >
> > The problem happens when a user, using the dashboard, tries to create a
> > volume using a volume type for which the project quota is over:
> >
> > - the reported error message simply reports "unable to create volume",
> > without mentioning that the problem is with quota
> >
> > - (by default) the dashboard only shows the overall Cinder quota (and not
> > the quota per volume)
> >
> >
> > Do you know if it possible in some to expose on the dashboard the cinder
> > quota per volume type ?
> >
> >
> > Thanks, Massimo
> >
> >
> >
> >
> >
> >
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Cinder quota per volume types in the dashboard

2017-09-25 Thread Saverio Proto

Hello Massimo,

what is your version of Openstack ??

thank you

Saverio

2017-09-25 9:13 GMT+02:00 Massimo Sgaravatto :
> Hi
>
>
> In our OpenStack cloud we have two backends for Cinder (exposed using two
> volume types), and we set different quotas for these two volume types.
>
> The problem happens when a user, using the dashboard, tries to create a
> volume using a volume type for which the project quota is over:
>
> - the reported error message simply reports "unable to create volume",
> without mentioning that the problem is with quota
>
> - (by default) the dashboard only shows the overall Cinder quota (and not
> the quota per volume)
>
>
> Do you know if it possible in some to expose on the dashboard the cinder
> quota per volume type ?
>
>
> Thanks, Massimo
>
>
>
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Cinder quota per volume types in the dashboard

Hi


In our OpenStack cloud we have two backends for Cinder (exposed using two
volume types), and we set different quotas for these two volume types.

The problem happens when a user, using the dashboard, tries to create a
volume using a volume type for which the project quota is over:

- the reported error message simply reports "unable to create volume",
without mentioning that the problem is with quota

- (by default) the dashboard only shows the overall Cinder quota (and not
the quota per volume)


Do you know if it possible in some to expose on the dashboard the cinder
quota per volume type ?


Thanks, Massimo
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] Help needed with migrating Fuel server

2017-09-25 Thread Raja T Nair

Hello All,

Can somebody help me with info on how to migrate OR backup/restore fuel
server to another hardware?
Fuel version - fuel-7.0.0-6122.1

We want to migrate fuel services to a new hardware.

Many Thanks.
Raja.

-- 
:^)
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] FW: [xenserver-ocata] ceilometer compute error Rrd_interface.Internal_error