[openstack-dev] [tc][solum] is solum-infra-guestagent an unmaintained project?

[Steve Martinelli]

When reviewing the projects necessary for the ocata community-wide goal,
(to remove old oslo-incubator code [1]) I noticed that solum-infra-guest
agent has had *very* few commits, 13 in total [2]. Almost half of which
were project cleanup type changes that all projects did. The last patch of
significance was over 2 years ago (Sept 2014).

I'm inquiring as to the status of the project, and what we should do about
it? It's still being maintained by the good will of some community members,
but it's eating up time nonetheless.

[1] https://etherpad.openstack.org/p/ocata-goal-oslo
[2] https://github.com/openstack/solum-infra-guestagent/commits/master
__
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] Live-migration CPU doesn't have compatibility

[William Josefsson]

hi, I did 'virsh capabilities' on the Haswell, which turned out to
list model: Haswell-noTSX. So I set in nova.conf
cpu_model=Haswell-noTSX on both Haswell and Broadwell hosts and it
seems to work. I believe this is my smallest common denominator. thx
will

On Fri, Oct 28, 2016 at 2:39 AM, Mohammed Naser  wrote:
> Depending on your workload, it will.  If they depend on any custom CPU
> extensions, they will miss out on them and performance will be
> decreased.  My personal suggestion is to read the docs for it and use
> the "smallest common denominator" in terms of CPU usage.
>
> On Thu, Oct 27, 2016 at 11:31 AM, William Josefsson
>  wrote:
>> On Thu, Oct 27, 2016 at 5:20 PM, Chris Friesen
>>  wrote:
>>> In your case you probably want to set both computes to have:
>>>
>>> [libvirt]
>>> cpu_mode = custom
>>> cpu_model = Haswell
>>>
>>
>> Hi Chris, thanks!  Yerps, I finally got it working. However, I set
>> cpu_model=kvm64 everywhere and it seems to work. It is listed here:
>> https://wiki.openstack.org/wiki/LibvirtXMLCPUModel  hopefully 'kvm64'
>> has no performance impact what cpu_model is set to, or would 'kvm64'
>> as model negatively affect my VMs? thx will
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
> --
> Mohammed Naser — vexxhost
> -
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mna...@vexxhost.com
> W. http://vexxhost.com

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

Re: [openstack-dev] [neutron] HostNotCompatibleWithFixedIps exception happens when setting router's gateway.

[zhi]

Unfortunately, I create two subnets like this :

neutron subnet-create 9bca94f8-3986-4900-a64e-e7f0cfc4c934 10.10.10.0/24
--service-types list=true network:router_gateway --enable_dhcp=False
neutron subnet-create 9bca94f8-3986-4900-a64e-e7f0cfc4c934 20.20.20.0/24
--service-types list=true network:floatingip --enable_dhcp=False

As shows above, one for router's gateway and the other is for floatingip.

But exception occurs again in neutron server, like this:

" IpAddressGenerationFailureNoMatchingSubnet: No valid service subnet for
the given device owner. "

Details info at [1].


Could you give some advice?


Thanks
Zhi Chang

[1]. http://paste.openstack.org/show/587223/

2016-10-28 10:25 GMT+08:00 zhi :

> Hi, Brian Haley, I reported a bug in launchpad at here [1]. I will disable
> DHCP in these subnets and try it again. :)
>
>
> Thanks
> Zhi Chang
>
>
> [1]. https://bugs.launchpad.net/neutron/+bug/1637366
>
> 2016-10-27 21:39 GMT+08:00 Brian Haley :
>
>> Hi Zhi,
>>
>> Thanks for the report, comment below.
>>
>> On 10/27/2016 05:04 AM, zhi wrote:
>>
>>> Hi, all.
>>>
>>> I installed a devstack in my local environment. All the code from
>>> master
>>> branch. After the installation, I have to show you some problems which I
>>> met.
>>>
>>> First of all, I create an external network by this command " neutron
>>> net-create public --router:external=True --provider:network_type=flat
>>> --provider:physical_network=public ".
>>>
>>> Secondly, I create a subnet with " subnet_type " by this command "
>>> neutron
>>> subnet-create [net-id] 20.20.20.0/24 
>>> --service-types
>>> list=true network:router_gateway ".
>>>
>>> At last, I create a router and setting this router's gateway by this
>>> command
>>> " neutron router-gateway-set [router-id] [net-id]".
>>>
>>> Exception happens in Neutron Server, it says "
>>> HostNotCompatibleWithFixedIps: Host devstack is not connected to a
>>> segment where
>>> the existing fixed_ips on port 0f38ba01-8dd0-43de-92e3-b294bd4ebed8 will
>>> function given the routed network topology. ".
>>>
>>
>> Subnet service types is new in Newton, and it seems you've found a bug -
>> can you file a bug on launchpad for it?
>>
>> The one thing you might try to get past this is to disable DHCP on these
>> subnets, but the error you linked seems different from [1].
>>
>> -Brian
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1636963
>>
>> After I did some research about the exception,  I found this patch[1]
>>> was
>>> adding this exception into neutron repo. I am confused about that. Why
>>> setting
>>> router's gateway will trigger this exception? I don't execute any
>>> commands about
>>> " routed_network ".
>>>
>>> What's wrong ?
>>>
>>> Could someone give some advice about that ? I upload all the network
>>> and
>>> subnets info at here [2]. Detail exception at here [3].
>>>
>>> BTW, what's the meaning of " tags " in network?
>>>
>>> Hope for your reply. :)
>>>
>>>
>>> Thanks
>>> Zhi Chang
>>>
>>>
>>> [1]. https://review.openstack.org/#/c/346217/3
>>> [2]. http://paste.openstack.org/show/587157/
>>> [3]. http://paste.openstack.org/show/587158/
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.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:unsubscrib
>> e
>> 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] [neutron] HostNotCompatibleWithFixedIps exception happens when setting router's gateway.

[zhi]

Hi, Brian Haley, I reported a bug in launchpad at here [1]. I will disable
DHCP in these subnets and try it again. :)


Thanks
Zhi Chang


[1]. https://bugs.launchpad.net/neutron/+bug/1637366

2016-10-27 21:39 GMT+08:00 Brian Haley :

> Hi Zhi,
>
> Thanks for the report, comment below.
>
> On 10/27/2016 05:04 AM, zhi wrote:
>
>> Hi, all.
>>
>> I installed a devstack in my local environment. All the code from
>> master
>> branch. After the installation, I have to show you some problems which I
>> met.
>>
>> First of all, I create an external network by this command " neutron
>> net-create public --router:external=True --provider:network_type=flat
>> --provider:physical_network=public ".
>>
>> Secondly, I create a subnet with " subnet_type " by this command "
>> neutron
>> subnet-create [net-id] 20.20.20.0/24 
>> --service-types
>> list=true network:router_gateway ".
>>
>> At last, I create a router and setting this router's gateway by this
>> command
>> " neutron router-gateway-set [router-id] [net-id]".
>>
>> Exception happens in Neutron Server, it says "
>> HostNotCompatibleWithFixedIps: Host devstack is not connected to a
>> segment where
>> the existing fixed_ips on port 0f38ba01-8dd0-43de-92e3-b294bd4ebed8 will
>> function given the routed network topology. ".
>>
>
> Subnet service types is new in Newton, and it seems you've found a bug -
> can you file a bug on launchpad for it?
>
> The one thing you might try to get past this is to disable DHCP on these
> subnets, but the error you linked seems different from [1].
>
> -Brian
>
> [1] https://bugs.launchpad.net/neutron/+bug/1636963
>
> After I did some research about the exception,  I found this patch[1]
>> was
>> adding this exception into neutron repo. I am confused about that. Why
>> setting
>> router's gateway will trigger this exception? I don't execute any
>> commands about
>> " routed_network ".
>>
>> What's wrong ?
>>
>> Could someone give some advice about that ? I upload all the network
>> and
>> subnets info at here [2]. Detail exception at here [3].
>>
>> BTW, what's the meaning of " tags " in network?
>>
>> Hope for your reply. :)
>>
>>
>> Thanks
>> Zhi Chang
>>
>>
>> [1]. https://review.openstack.org/#/c/346217/3
>> [2]. http://paste.openstack.org/show/587157/
>> [3]. http://paste.openstack.org/show/587158/
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-dev] [daisycloud-core] Agenda for IRC meeting 0800UTC Oct. 28 2016

[hu . zhijiang]

1) Roll Call
2) OPNFV: Escalator Support
3) OPNFV: Daisy4nfv CI Framework Progress
4) Core Code Abstraction
5) Newton Release Related

Action items follow-up

1) Newton deployment

B.R.,
Zhijiang


__
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] [neutron-lbaas][octavia] Error in installing octavia via devstack on ubuntu stable/mitaka

[Wanjing Xu (waxu)]

Hi

This is the first time  I tried to install octavia.  But it error out at(from 
stack.sh.log):


2016-10-25 22:50:45.270 | creating /usr/local/etc/octavia
2016-10-25 22:50:45.270 | copying etc/octavia.conf -> /usr/local/etc/octavia
2016-10-25 22:50:45.270 | running install_egg_info
2016-10-25 22:50:45.271 | Copying octavia.egg-info to 
/usr/local/lib/python2.7/dist-packages/octavia-0.9.1.dev57-py2.7.egg-info
2016-10-25 22:50:45.272 | running install_scripts
2016-10-25 22:50:45.288 | Installing octavia-worker script to /usr/local/bin
2016-10-25 22:50:45.288 | Installing octavia-health-manager script to 
/usr/local/bin
2016-10-25 22:50:45.289 | Installing octavia-housekeeping script to 
/usr/local/bin
2016-10-25 22:50:45.289 | Installing octavia-db-manage script to /usr/local/bin
2016-10-25 22:50:45.289 | Installing haproxy-vrrp-check script to /usr/local/bin
2016-10-25 22:50:45.289 | Installing amphora-agent script to /usr/local/bin
2016-10-25 22:50:45.289 | Installing octavia-api script to /usr/local/bin
2016-10-25 22:50:45.310 | + cp etc/init/amphora-agent.conf /etc/init/
2016-10-25 22:50:45.312 | cp: cannot stat 'etc/init/amphora-agent.conf': No 
such file or directory
2016-10-25 22:50:45.764 | Unmount 
/tmp/dib_build.EFA965tj/mnt/var/cache/apt/archives
2016-10-25 22:50:45.807 | Unmount /tmp/dib_build.EFA965tj/mnt/tmp/pip

This is stable/mitaka, even though I manually invoked the following, it errored 
out at the same place

/opt/stack/octavia/diskimage-create/diskimage-create.sh -s 2


Could somebody please help out on why it errored here.?

Here is a snippet of my local.conf:
...
enable_service q-lbaasv2
disable_service tempest
enable_service octavia o-cw o-hk o-hm o-api

enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas 
stable/mitaka
enable_plugin octavia https://git.openstack.org/openstack/octavia stable/mitaka


Thanks
Wanjing Xu
__
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] [openstack-ansible] Debugging slow Xenial gate

[Mike Carden]

Major,

I bounced this off my 'distro differences' goto guy, Chris Smart. Here are
his thoughts:

"Run the 14.04 kernel on 16.04 system and re-run the tests to see if it's
kernel related.

If 16.04 userland with 14.04 kernel is as fast as Ubuntu 14.04, then
compare the kernel .config files to see if there were major changes,
like switching out schedulers.

Also, when running the tests on both systems, track cpu usage and number
of threads to see if one has more restrictions than the other.

Check swappiness and also "vmstat 1" to see if you're getting more pages
swapped in and out in 16.04.

I'm assuming that the two virtual machines are identical (CPU type, memory,
threads, virtio, etc)."

-- 
MC
__
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] [oss-security] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Kurt Seifried]

Just a note this was assigned CVE-2016-8611

On Thu, Oct 27, 2016 at 3:42 PM, Luke Hinds  wrote:

> Glance Image service v1 and v2 api image-create vulnerability
> ---
>
> ### Summary ###
> No limits are enforced within the Glance image service for both v1 and
> v2 `/images` API POST method for authenticated users, resulting in
> possible denial of service attacks through database table saturation.
>
> ### Affected Services / Software ###
> All versions of Glance image service.
>
> ### Discussion ###
> Within the Glance image service, calls to the POST method within v1 or
> v2/images creates an image (record) in `queued` status. There is no
> limit enforced within the Glance API on the number of images a single
> tenant may create, just on the total amount of storage a single user may
> consume.
>
> Therefore a user could either maliciously or unintentionally fill
> multiple database tables (images, image_properties, image_tags,
> image_members) with useless image records, thereby causing a denial of
> service by lengthening transaction response times in the Glance database.
>
> ### Recommended Actions ###
> For all versions of Glance that expose either the v1 and v2/images API,
> operators are recommended to deploy external rate-limiting proxies or
> web application firewalls, to provide a front layer of protection to
> glance. The Glance database should be monitored for abnormal growth.
> Although rate-limiting does not eliminate this attack vector, it will
> slow it to the point where you can react prior to a denial of service
> occurring.
>
> The following solutions may be considered, however it is key that the
> operator carefully plans and considers the individual performance needs
> of users and services within their OpenStack cloud, when configuring any
> rate limiting functionality.
>
>  Repose 
> Repose provides a rate limiting filter, that can utilise limits by IP,
> Role (OpenStack Identity v3 filter) or header.
>
> https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter
>
>  NGINX 
> NGINX provides the limit_req_module, which can be used to provide a
> global rate
> limit. By means of a `map`, it can be limited to just the POST method.
>
> Further details can be found on the nginx site:
> http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
>
>  HAProxy 
> HAProxy can provide inherent rate-limiting using stick-tables with a
> General
> Purpose Counter (gpc)
>
> Further details can be found on the haproxy website:
>
> http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-
> a-first-row-of-defense-against-ddos
>
>  Apache 
> A number of solutions can be explored here as follows.
>
> # mod_ratelimit #
> http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html
>
> # mod_qos #
> http://opensource.adnovum.ch/mod_qos/dos.html
>
> # mod_evasive #
> https://www.digitalocean.com/community/tutorials/how-to-
> protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7
>
> # mod_security #
> https://www.modsecurity.org/
>
>  Limit `add_image` to admin role 
>
> Another possible mitigation is to restrict image creation to the admin
> role, however this should only be done for those cases in which there
> are Glance nodes dedicated to end-user access only. Restriction to admin
> only on Glance nodes that serve OpenStack services will for example,
> remove the ability to create snapshots from the Compute API or to create
> bootable volumes from Cinder.
>
> To restrict image creation to the role admin only, amend
> `/etc/glance/policy.json` accordingly.
>
> "add_image": "role:admin",
>
> ### Contacts / References ###
> Author: Luke Hinds, Red Hat
> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
> Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
> OpenStack Security ML : openstack-secur...@lists.openstack.org
> OpenStack Security Group : https://launchpad.net/~openstack-ossg
>
>
>


-- 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secal...@redhat.com
___
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] [neutron] proposal to resolve a rootwrap problem for XenServer

[Jianghua Wang]

Hi Neutron guys,

I'm trying to explain a problem with the XenServer rootwrap and give a proposal 
to resolve it. I need some input on how to proceed with this proposal: e.g. if 
requires a spec? Any concerns need further discussion or clarification?

Problem description:
As we've known, some neutron services need run commands with root privileges 
and it's achieved by running commands via the rootwrap. And in order to resolve 
performance issue, it has been improved to support daemon mode for the rootwrap 
[1]. Either way has the commands running on the same node/VM which has relative 
neutron services running on.

But as a type-1 hypervisor, XenServer OpenStack has different behavior. 
Neutron's compute agent neutron-openvswitch-agent need run commands in dom0, as 
the tenants' interfaces are plugged in an integration OVS which locates in 
Dom0. Currently the script of 
https://github.com/openstack/neutron/blob/master/bin/neutron-rootwrap-xen-dom0 
is used as XenServer OpenStack's rootwrap. This script will create a XenAPI 
session with dom0 and passes the commands to dom0 for the real execution. Each 
command execution will run this script once. So it has the similar performance 
issue as the non-daemon mode of rootwrap on other hypervisors:  For each 
command, it has to parse the neutron-rootwrap-xen-dom0 script and the rootwrap 
configure file. Furthermore, this rootwrap script will create a XenAPI for each 
command execution and XenServer by default will log the XenAPI session creation 
events. It will cause frequent log file rotation and so other real useful log 
is lost.

Proposal:
The os.rootwrap support daemon mode for other hypervisors; but XenServer's 
compute agent can't use that as again it need run commands in Dom0. But we can 
refer to that design and implement the daemon mode for XenServer. After 
creating a XenAPI session, Dom0's XAPI will accept the command running requests 
from the session and reply with the running result. So logically we've had a 
daemon in dom0. So we can support daemon mode rootwrap with the following 
design:
1. Develop a daemon client module for XenServer: The agent service will use 
this client module to create a XenAPI session, and keep this session during the 
service's whole life.
2. once need run command on dom0, use the above client to runs commands in dom0.
It should be able to result the issues mentioned above, as the client module 
need import only once for each agent service and only use a single session for 
all commands. The prototype code[3] works well.

Any concern or comments for the above proposal? And how I can proceed with 
solution? We've filed a RFE bug[2] which is in wishlist status. Per 
the neutron policy[4], it seems need neutron-drivers team to evaluate the RFE 
and determine if a spec is required. Could anyone help to evaluate this 
proposal and tell me how I should proceed? And I'm also open and happy for any 
comments. Thanks very much.

[1] 
https://specs.openstack.org/openstack/oslo-specs/specs/juno/rootwrap-daemon-mode.html
[2] https://bugs.launchpad.net/neutron/+bug/1585510
[3]prototype code: https://review.openstack.org/#/c/390931/
[4] http://docs.openstack.org/developer/neutron/policies/blueprints.html

Regards,
Jianghua

__
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] [oss-security] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Kurt Seifried]

Just a note this was assigned CVE-2016-8611

On Thu, Oct 27, 2016 at 3:42 PM, Luke Hinds  wrote:

> Glance Image service v1 and v2 api image-create vulnerability
> ---
>
> ### Summary ###
> No limits are enforced within the Glance image service for both v1 and
> v2 `/images` API POST method for authenticated users, resulting in
> possible denial of service attacks through database table saturation.
>
> ### Affected Services / Software ###
> All versions of Glance image service.
>
> ### Discussion ###
> Within the Glance image service, calls to the POST method within v1 or
> v2/images creates an image (record) in `queued` status. There is no
> limit enforced within the Glance API on the number of images a single
> tenant may create, just on the total amount of storage a single user may
> consume.
>
> Therefore a user could either maliciously or unintentionally fill
> multiple database tables (images, image_properties, image_tags,
> image_members) with useless image records, thereby causing a denial of
> service by lengthening transaction response times in the Glance database.
>
> ### Recommended Actions ###
> For all versions of Glance that expose either the v1 and v2/images API,
> operators are recommended to deploy external rate-limiting proxies or
> web application firewalls, to provide a front layer of protection to
> glance. The Glance database should be monitored for abnormal growth.
> Although rate-limiting does not eliminate this attack vector, it will
> slow it to the point where you can react prior to a denial of service
> occurring.
>
> The following solutions may be considered, however it is key that the
> operator carefully plans and considers the individual performance needs
> of users and services within their OpenStack cloud, when configuring any
> rate limiting functionality.
>
>  Repose 
> Repose provides a rate limiting filter, that can utilise limits by IP,
> Role (OpenStack Identity v3 filter) or header.
>
> https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter
>
>  NGINX 
> NGINX provides the limit_req_module, which can be used to provide a
> global rate
> limit. By means of a `map`, it can be limited to just the POST method.
>
> Further details can be found on the nginx site:
> http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
>
>  HAProxy 
> HAProxy can provide inherent rate-limiting using stick-tables with a
> General
> Purpose Counter (gpc)
>
> Further details can be found on the haproxy website:
>
> http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-
> a-first-row-of-defense-against-ddos
>
>  Apache 
> A number of solutions can be explored here as follows.
>
> # mod_ratelimit #
> http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html
>
> # mod_qos #
> http://opensource.adnovum.ch/mod_qos/dos.html
>
> # mod_evasive #
> https://www.digitalocean.com/community/tutorials/how-to-
> protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7
>
> # mod_security #
> https://www.modsecurity.org/
>
>  Limit `add_image` to admin role 
>
> Another possible mitigation is to restrict image creation to the admin
> role, however this should only be done for those cases in which there
> are Glance nodes dedicated to end-user access only. Restriction to admin
> only on Glance nodes that serve OpenStack services will for example,
> remove the ability to create snapshots from the Compute API or to create
> bootable volumes from Cinder.
>
> To restrict image creation to the role admin only, amend
> `/etc/glance/policy.json` accordingly.
>
> "add_image": "role:admin",
>
> ### Contacts / References ###
> Author: Luke Hinds, Red Hat
> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
> Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
> OpenStack Security ML : openstack-secur...@lists.openstack.org
> OpenStack Security Group : https://launchpad.net/~openstack-ossg
>
>
>


-- 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secal...@redhat.com
__
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] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Luke Hinds]

Glance Image service v1 and v2 api image-create vulnerability
---

### Summary ###
No limits are enforced within the Glance image service for both v1 and
v2 `/images` API POST method for authenticated users, resulting in
possible denial of service attacks through database table saturation.

### Affected Services / Software ###
All versions of Glance image service.

### Discussion ###
Within the Glance image service, calls to the POST method within v1 or
v2/images creates an image (record) in `queued` status. There is no
limit enforced within the Glance API on the number of images a single
tenant may create, just on the total amount of storage a single user may
consume.

Therefore a user could either maliciously or unintentionally fill
multiple database tables (images, image_properties, image_tags,
image_members) with useless image records, thereby causing a denial of
service by lengthening transaction response times in the Glance database.

### Recommended Actions ###
For all versions of Glance that expose either the v1 and v2/images API,
operators are recommended to deploy external rate-limiting proxies or
web application firewalls, to provide a front layer of protection to
glance. The Glance database should be monitored for abnormal growth.
Although rate-limiting does not eliminate this attack vector, it will
slow it to the point where you can react prior to a denial of service
occurring.

The following solutions may be considered, however it is key that the
operator carefully plans and considers the individual performance needs
of users and services within their OpenStack cloud, when configuring any
rate limiting functionality.

 Repose 
Repose provides a rate limiting filter, that can utilise limits by IP,
Role (OpenStack Identity v3 filter) or header.

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

 NGINX 
NGINX provides the limit_req_module, which can be used to provide a
global rate
limit. By means of a `map`, it can be limited to just the POST method.

Further details can be found on the nginx site:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

 HAProxy 
HAProxy can provide inherent rate-limiting using stick-tables with a General
Purpose Counter (gpc)

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

 Apache 
A number of solutions can be explored here as follows.

# mod_ratelimit #
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

# mod_qos #
http://opensource.adnovum.ch/mod_qos/dos.html

# mod_evasive #
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

# mod_security #
https://www.modsecurity.org/

 Limit `add_image` to admin role 

Another possible mitigation is to restrict image creation to the admin
role, however this should only be done for those cases in which there
are Glance nodes dedicated to end-user access only. Restriction to admin
only on Glance nodes that serve OpenStack services will for example,
remove the ability to create snapshots from the Compute API or to create
bootable volumes from Cinder.

To restrict image creation to the role admin only, amend
`/etc/glance/policy.json` accordingly.

"add_image": "role:admin",

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
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] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Luke Hinds]

Glance Image service v1 and v2 api image-create vulnerability
---

### Summary ###
No limits are enforced within the Glance image service for both v1 and
v2 `/images` API POST method for authenticated users, resulting in
possible denial of service attacks through database table saturation.

### Affected Services / Software ###
All versions of Glance image service.

### Discussion ###
Within the Glance image service, calls to the POST method within v1 or
v2/images creates an image (record) in `queued` status. There is no
limit enforced within the Glance API on the number of images a single
tenant may create, just on the total amount of storage a single user may
consume.

Therefore a user could either maliciously or unintentionally fill
multiple database tables (images, image_properties, image_tags,
image_members) with useless image records, thereby causing a denial of
service by lengthening transaction response times in the Glance database.

### Recommended Actions ###
For all versions of Glance that expose either the v1 and v2/images API,
operators are recommended to deploy external rate-limiting proxies or
web application firewalls, to provide a front layer of protection to
glance. The Glance database should be monitored for abnormal growth.
Although rate-limiting does not eliminate this attack vector, it will
slow it to the point where you can react prior to a denial of service
occurring.

The following solutions may be considered, however it is key that the
operator carefully plans and considers the individual performance needs
of users and services within their OpenStack cloud, when configuring any
rate limiting functionality.

 Repose 
Repose provides a rate limiting filter, that can utilise limits by IP,
Role (OpenStack Identity v3 filter) or header.

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

 NGINX 
NGINX provides the limit_req_module, which can be used to provide a
global rate
limit. By means of a `map`, it can be limited to just the POST method.

Further details can be found on the nginx site:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

 HAProxy 
HAProxy can provide inherent rate-limiting using stick-tables with a General
Purpose Counter (gpc)

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

 Apache 
A number of solutions can be explored here as follows.

# mod_ratelimit #
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

# mod_qos #
http://opensource.adnovum.ch/mod_qos/dos.html

# mod_evasive #
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

# mod_security #
https://www.modsecurity.org/

 Limit `add_image` to admin role 

Another possible mitigation is to restrict image creation to the admin
role, however this should only be done for those cases in which there
are Glance nodes dedicated to end-user access only. Restriction to admin
only on Glance nodes that serve OpenStack services will for example,
remove the ability to create snapshots from the Compute API or to create
bootable volumes from Cinder.

To restrict image creation to the role admin only, amend
`/etc/glance/policy.json` accordingly.

"add_image": "role:admin",

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


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][taas] Tap-as-a-Service meeting on 28th Oct

[Shigeta, Soichi]

Hi,

  Tap-as-a-Service team will have a face to face meeting in Barcelona Summit:

  Date: 28th Oct, Friday
  Time & Place: meet at the “registration” area (P0) at 9:00am then we will move
to a room (somewhere we can use)

 Please feel free to join us if you are interested in Tap-as-a-Service.

  Best regards,
  Soichi


__
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] Centralizing some config options will break many stadium projects

[Brandon Logan]

Hello Neutrinos,
I've come across an issue that I'd like to get input/opinions on.  I've
been reviewing some of the centralize config options reviews and have
come across a few that would cause issues with other projects that are
importing these options, especially stadium projects.  High level view
of the issue:

[1] would cause at least 22 projects to need to be fixed based on [2]

[3] would cause at least 12 projects to need to be fixed based on [4]

[5] looks to affect many other projects as well (I'm being lazy and
not  counting them right now)

Initially, the thinking was that moving the config options around would
cause some breakage with projects outside of neutron, but that would be
fine because projects shouldn't really be using neutron as a library
and using it to register config options.  However, with these 3
patches, I definitely don't feel comfortable breaking the amount of
projects these would break.  It also makes me think that maybe these
options should be in neutron-lib since they're consumed so widely. 
Anyway, I've come up with some possible options to deal with this, but
would like to hear others' opinions on this:

1) Let the patches merge and break those projects as a signal that
importing these shouldn't be done.  The affected projects can choose to
push fixes that continue importing the neutron config options or
defining their own config options.
2) Deprecate the old locations for some timeframe, and then remove
later.
3) Texas Three-Step: change the neutron patches to keep pointers in the
old locations to the new, and then push patches to the affected repos
with Depends-On directives.  Once all patches merge, push up one more
patch to neutron to remove the old location.
4) Abandon these reviews and do nothing.
5) Move these config options to neutron-lib so that they can be used by
any project.  This still requires doing one of the above options,
however.
6) Any others I can't think of?



[1] https://review.openstack.org/#/c/343045/
[2] http://codesearch.openstack.org/?q=from%20neutron.agent.common%20im
port%20config=nope==

[3] https://review.openstack.org/#/c/340228/
[4] http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20c
onfig=nope==

[5] https://review.openstack.org/#/c/347867/
__
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] Live-migration CPU doesn't have compatibility

[Mohammed Naser]

Depending on your workload, it will.  If they depend on any custom CPU
extensions, they will miss out on them and performance will be
decreased.  My personal suggestion is to read the docs for it and use
the "smallest common denominator" in terms of CPU usage.

On Thu, Oct 27, 2016 at 11:31 AM, William Josefsson
 wrote:
> On Thu, Oct 27, 2016 at 5:20 PM, Chris Friesen
>  wrote:
>> In your case you probably want to set both computes to have:
>>
>> [libvirt]
>> cpu_mode = custom
>> cpu_model = Haswell
>>
>
> Hi Chris, thanks!  Yerps, I finally got it working. However, I set
> cpu_model=kvm64 everywhere and it seems to work. It is listed here:
> https://wiki.openstack.org/wiki/LibvirtXMLCPUModel  hopefully 'kvm64'
> has no performance impact what cpu_model is set to, or would 'kvm64'
> as model negatively affect my VMs? thx will
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Mohammed Naser — vexxhost
-
D. 514-316-8872
D. 800-910-1726 ext. 200
E. mna...@vexxhost.com
W. http://vexxhost.com

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

Re: [Openstack] UnsupportedVersion Endpoint does not support RPC version

[Mohammed Naser]

Hi there,

We ran into that same issue.  It was a Liberty -> Mitaka upgrade, control
plane was all Mitaka with a few Liberty nodes.  We couldn't live migrate
till everything was up to Mitaka

Thanks
Mohammed

On Thu, Oct 27, 2016 at 12:53 PM, John Petrini 
wrote:

> I don't have any further suggestions. Since the 7th parameter was added in
> API version 4.2 the issue you're having doesn't really surprise me. However
> it seems like you have a workaround for migrating either direction. Is that
> not enough for what you're trying to accomplish?
>
> ___
>
> John Petrini
>
> NOC Systems Administrator   //   *CoreDial, LLC*   //   coredial.com
>//   [image: Twitter]    [image:
> LinkedIn]    [image: Google Plus]
>    [image: Blog]
> 
> Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
> *P: *215.297.4400 x232   //   *F: *215.297.4401   //   *E: *
> jpetr...@coredial.com
>
> [image: Exceptional people. Proven Processes. Innovative Technology.
> Discover CoreDial - watch our video]
> 
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission,  dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete the material from any
> computer.
>
> On Wed, Oct 26, 2016 at 9:12 PM, Oisin O'Malley <
> oisin.omal...@iocane.com.au> wrote:
>
>> Thanks John,
>>
>> > I think it may be your API version. See here:
>> https://github.com/openstack/nova/blob/2014.2/nova/compute/rpcapi.py#L270
>>
>> There seems to be a discrepancy in the rpcapi.py "kilo" alias between the
>> Kilo and Liberty releases. In the Kilo release the compute alias is
>> "kilo=3.40" but in Liberty it is "kilo=4.0". Setting the compute API
>> version to 4.0 on the Kilo compute node or removing it entirely appears to
>> resolve the issue. Though has either caused or led to another issue.
>>
>> I've testing and can live migrate from Kilo -> Liberty compute nodes, but
>> fails on migrating from  Liberty -> Kilo. I suspect another API version
>> issue. With compute API level pined to 4.0 across all Nova nodes,  the
>> following error is raised in the Liberty Nova compute nodes log when I try
>> live migrate from Liberty to Kilo;
>>
>>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 142, in _dispatch_and_reply
>>  executor_callback))
>>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 186, in _dispatch
>>  executor_callback)
>>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 129, in _do_dispatch
>>  result = func(ctxt, **new_args)
>>File "/usr/lib/python2.7/site-packages/nova/exception.py", line 89,
>> in wrapped
>>  payload)
>>File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
>> 195, in __exit__
>>  six.reraise(self.type_, self.value, self.tb)
>>File "/usr/lib/python2.7/site-packages/nova/exception.py", line 72,
>> in wrapped
>>  return f(self, context, *args, **kw)
>>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> 400, in decorated_function
>>  return function(self, context, *args, **kwargs)
>>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> 378, in decorated_function
>>  kwargs['instance'], e, sys.exc_info())
>>File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
>> 195, in __exit__
>>  six.reraise(self.type_, self.value, self.tb)
>>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
>> 366, in decorated_function
>>  return function(self, context, *args, **kwargs)
>>  TypeError: live_migration() takes exactly 7 arguments (6 given)
>>
>> There appears to of been a few bugs raised previously for this. The 4.2
>> API version of live_migration with 7 parameters appears to be getting
>> called with the 6 parameters from API version 4.0. I'm not sure why.
>>
>> https://bugs.launchpad.net/nova/+bug/1595864
>> I've unsuccessful tried the suggestion in the above and restarted all
>> nova-conductor services to no effect.
>>
>> Any suggestions?
>>
>>
>> Oisin O'Malley
>> Systems Engineer
>> Iocane Pty Ltd
>> 763 South Road
>> Black Forest SA 5035
>>
>> Office:+61 (8) 8413 1010
>> Fax:+61 (8) 8231 2050
>> Email:oisin.omal...@iocane.com.au
>> Web:www.iocane.com.au
>>
>> Better for business
>>
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack

Re: [openstack-dev] [TripleO] Your draft logo & a sneak peek

[Ryan Brady]

On Thu, Oct 27, 2016 at 12:48 PM, Sven Anderson  wrote:

> Hi all,
>
> On 25.10.2016 14:28, Ryan Brady wrote:
> > I feel the logo draft is missing a lot of the detail and fidelity of our
> > current logo.
> > The draft logo has lines that are much too thick especially in the face
> > area.  It's
> > recognizable from a shorter distance than our current logo.
> >
> > Our current logo has more of a cartoon / angry birds type feel to it -
> > something
> > with personality.  To me, the draft logo is devoid of personality. I
> > understand why
> > the foundation wants to have more consistency between logos, but I'm
> hoping
> > this isn't the final design approach.
>
> to balance the feedback a bit: I like the new logo. I'm sure it could be
> improved, but in general I think it qualifies as a logo, while the old
> version does not really from my perspective. Logos _have_ to be sparse
> in detail and still expressive.


How is the current draft logo expressive?  What does it express to you?

- Ryan


> That's what differentiates it from a
> normal drawing.
>
> Cheers,
>
> Sven
>
> __
> 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
>



-- 
Ryan Brady
Cloud Engineering
rbr...@redhat.com
919.890.8925
__
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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Bashmakov, Alexander]

Hi Jay,

Thanks for the explanation. While I agree that there is a distinction between a 
distributed architecture like Nova and a centralized one like Glance, I would 
respectfully disagree with the statement that Glance cannot participate in 
rolling upgrades in a very similar fashion. We are currently working on a 
rolling upgrade POC in Glance (https://review.openstack.org/331740/). To date, 
we've successfully been able to run through a simple scenario with two Glance 
nodes running Newton and Ocata code base respectively. The latter introduces 
schema changes which are reconciled in the DB via a two-way trigger.

Regards,
Alex

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Friday, October 14, 2016 1:56 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: 
database triggers and oslo.versionedobjects

Alex, so sorry for the long delayed response! :( This just crept to the back of 
my inbox unfortunately. Answer inline...

On 09/14/2016 07:24 PM, Bashmakov, Alexander wrote:
>> Glance and Keystone do not participate in a rolling upgrade, because 
>> Keystone and Glance do not have a distributed component architecture. 
>> Online data migrations will reduce total downtime experienced during 
>> an *overall upgrade procedure* for an OpenStack cloud, but Nova, 
>> Neutron and Cinder are the only parts of OpenStack that are going to 
>> participate in a rolling upgrade because they are the services that 
>> are distributed across all the many compute nodes.
>
> Hi Jay, I'd like to better understand why your definition of rolling 
> upgrades excludes Glance and Keystone? Granted they don't run multiple 
> disparate components over distributed systems, however, they can still 
> run the same service on multiple distributed nodes. So a rolling 
> upgrade can still be applied on a large cloud that has, for instance 
> 50 Glance nodes.

If you've seen a cloud with 50 Glance nodes, I would be astonished :) That 
said, the number 50 doesn't really have to do with my definition of rolling... 
lemme explain.

The primary thing that, to me at least, differentiates rolling upgrades of 
distributed software is that different nodes can contain multiple versions of 
the software and continue to communicate with other nodes in the system without 
issue.

In the case of Glance, you cannot have different versions of the Glance service 
running simultaneously within an environment, because those Glance services 
each directly interface with the Glance database and therefore expect the 
Glance DB schema to look a particular way for a specific version of the Glance 
service software.

In contrast, Nova's distributed service nodes -- the nova-compute services and 
(mostly) the nova-api services do *not* talk directly to the Nova database. If 
those services need to get or set data in the database, they communicate with 
the nova-conductor services which are responsible for translating (called 
back-versioning) the most updated object model schema that matches the Nova 
database to the schema that the calling node understands. This means that Nova 
deployers can update the Nova database schema and not have to at the same time 
update the software on the distributed compute nodes. In this way deployers can 
"roll out" an upgrade of the Nova software across many hundreds of compute 
nodes over an extended period of time without needing to restart/upgrade 
services all at once.

Hope this clarifies things.

Best,
-jay

p.s. I see various information on the web referring to "rolling updates" 
or "rolling releases" as simply the process of continuously applying new 
versions of software to a deployment. This is decidedly *not* what I refer to 
as a "rolling upgrade". Perhaps we should invent a different term from "rolling 
upgrade" to refer to the attributes involved in being able to run multiple 
versions of distributed software with no impact on the control plane? Is that 
what folks call a "partial upgrade"? Not sure...

  > In this case different versions of the
> same service will run on different nodes simultaneously. Regards, Alex



__
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] [ironic] OneView CI results not publicly viewable

[Mario Villaplana]

Hi all,

I discovered today that the OneView CI result links currently point to
internal (10.*) IP addresses. See here for an example:
https://review.openstack.org/#/c/372762/14

According to OpenStack's third-party testing requirements [0],
third-party test artifacts should be public and retained for 1 month.
I believe this applies to non-voting CI as well.

I've CC'ed the current maintainers from the wiki. [1]

Should this job be removed until this is corrected?

Thanks,
Mario

[0] http://docs.openstack.org/infra/system-config/third_party.html#requirements
[1] https://wiki.openstack.org/wiki/ThirdPartySystems/UFCG_OneView_CI

__
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] UnsupportedVersion Endpoint does not support RPC version

[John Petrini]

I don't have any further suggestions. Since the 7th parameter was added in
API version 4.2 the issue you're having doesn't really surprise me. However
it seems like you have a workaround for migrating either direction. Is that
not enough for what you're trying to accomplish?

___

John Petrini

NOC Systems Administrator   //   *CoreDial, LLC*   //   coredial.com
//   [image:
Twitter]    [image: LinkedIn]
   [image: Google Plus]
   [image: Blog]

Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422
*P: *215.297.4400 x232   //   *F: *215.297.4401   //   *E: *
jpetr...@coredial.com

[image: Exceptional people. Proven Processes. Innovative Technology.
Discover CoreDial - watch our video]


The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission,  dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from any
computer.

On Wed, Oct 26, 2016 at 9:12 PM, Oisin O'Malley  wrote:

> Thanks John,
>
> > I think it may be your API version. See here:
> https://github.com/openstack/nova/blob/2014.2/nova/compute/rpcapi.py#L270
>
> There seems to be a discrepancy in the rpcapi.py "kilo" alias between the
> Kilo and Liberty releases. In the Kilo release the compute alias is
> "kilo=3.40" but in Liberty it is "kilo=4.0". Setting the compute API
> version to 4.0 on the Kilo compute node or removing it entirely appears to
> resolve the issue. Though has either caused or led to another issue.
>
> I've testing and can live migrate from Kilo -> Liberty compute nodes, but
> fails on migrating from  Liberty -> Kilo. I suspect another API version
> issue. With compute API level pined to 4.0 across all Nova nodes,  the
> following error is raised in the Liberty Nova compute nodes log when I try
> live migrate from Liberty to Kilo;
>
>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 142, in _dispatch_and_reply
>  executor_callback))
>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 186, in _dispatch
>  executor_callback)
>File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 129, in _do_dispatch
>  result = func(ctxt, **new_args)
>File "/usr/lib/python2.7/site-packages/nova/exception.py", line 89, in
> wrapped
>  payload)
>File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
> 195, in __exit__
>  six.reraise(self.type_, self.value, self.tb)
>File "/usr/lib/python2.7/site-packages/nova/exception.py", line 72, in
> wrapped
>  return f(self, context, *args, **kw)
>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 400, in decorated_function
>  return function(self, context, *args, **kwargs)
>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 378, in decorated_function
>  kwargs['instance'], e, sys.exc_info())
>File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
> 195, in __exit__
>  six.reraise(self.type_, self.value, self.tb)
>File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 366, in decorated_function
>  return function(self, context, *args, **kwargs)
>  TypeError: live_migration() takes exactly 7 arguments (6 given)
>
> There appears to of been a few bugs raised previously for this. The 4.2
> API version of live_migration with 7 parameters appears to be getting
> called with the 6 parameters from API version 4.0. I'm not sure why.
>
> https://bugs.launchpad.net/nova/+bug/1595864
> I've unsuccessful tried the suggestion in the above and restarted all
> nova-conductor services to no effect.
>
> Any suggestions?
>
>
> Oisin O'Malley
> Systems Engineer
> Iocane Pty Ltd
> 763 South Road
> Black Forest SA 5035
>
> Office:+61 (8) 8413 1010
> Fax:+61 (8) 8231 2050
> Email:oisin.omal...@iocane.com.au
> Web:www.iocane.com.au
>
> Better for business
>
___
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] Your draft logo & a sneak peek

[Sven Anderson]

Hi all,

On 25.10.2016 14:28, Ryan Brady wrote:
> I feel the logo draft is missing a lot of the detail and fidelity of our
> current logo. 
> The draft logo has lines that are much too thick especially in the face
> area.  It's
> recognizable from a shorter distance than our current logo. 
> 
> Our current logo has more of a cartoon / angry birds type feel to it -
> something
> with personality.  To me, the draft logo is devoid of personality. I
> understand why
> the foundation wants to have more consistency between logos, but I'm hoping
> this isn't the final design approach.

to balance the feedback a bit: I like the new logo. I'm sure it could be
improved, but in general I think it qualifies as a logo, while the old
version does not really from my perspective. Logos _have_ to be sparse
in detail and still expressive. That's what differentiates it from a
normal drawing.

Cheers,

Sven

__
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-ansible] Debugging slow Xenial gate

[Major Hayden]

Hey there,

We've talked about the slow Xenial gate during the OpenStack Summit this week 
and I decided to do a little digging.  I built two quick test instances: one 
with Trusty and the other with Xenial.

Trusty comes with python 2.7.6 and Xenial has 2.7.12.  Here are the initial 
comparisons:

  https://gist.github.com/major/20d7d11442685355c30d0abf0c07be98

The worst test shows that 2.7.12 on Xenial is 1.88 slower than 2.7.6 on Trusty. 
Wow.

I compiled 2.7.12 from source on Xenial to see if it's a packaging issue, but 
that didn't change anything much.  I then compiled 2.7.12 on 14.04 and found it 
be to be slightly slower than 2.7.6 on 14.04, but faster than 2.7.12 on 16.04.  
That's confusing, so here's a ranking from fastest to slowest performance:

1) 2.7.6 on Ubuntu 14.04 (fastest)
2) 2.7.12 compiled from source on Ubuntu 14.04 (a little slower than #1)
3) 2.7.12 compiled from source on Ubuntu 16.04 (slightly faster than #4)
4) 2.7.12 on Ubuntu 16.04 (significant slower than #1)

It's evident that 2.7.12 is a little bit slower, but something in Ubuntu 16.04 
makes it much worse.  I checked sysctl settings and the only big difference was 
the max threads per process (16.04 was about half of 14.04).  I set them both 
to the same value but the performance testing didn't change.

Does anyone else have any ideas of what might be causing this?

--
Major Hayden



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][n8n-bgpvpn] meeting on BGP VPN in Barcelona: Fri 1pm

[Thomas Morin]

Hi folks,

For those who are interested to discuss networking-bgpvpn Ocata, I 
propose that we meet tomorrow at 1pm in the Contributors' meetup room 
(CCIB 114).


Among the things we can discuss:
- pending things related to neutron stadium
-   ^ in particular, CI testing
- what API evolutions to prioritize for Ocata (E-VPN, static routes, 
Port associations)
- discuss the idea of supporting multiple drivers simultaneously (e.g. 
per compute) and how

- update on bagpipe reference driver
- update on other drivers
- packaging work and related questions
- things happening in OPNFV/SDNVPN
-...

See you tomorrow, or at the Neutron social tonight...

-Thomas


__
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] Live-migration CPU doesn't have compatibility

[William Josefsson]

On Thu, Oct 27, 2016 at 5:20 PM, Chris Friesen
 wrote:
> In your case you probably want to set both computes to have:
>
> [libvirt]
> cpu_mode = custom
> cpu_model = Haswell
>

Hi Chris, thanks!  Yerps, I finally got it working. However, I set
cpu_model=kvm64 everywhere and it seems to work. It is listed here:
https://wiki.openstack.org/wiki/LibvirtXMLCPUModel  hopefully 'kvm64'
has no performance impact what cpu_model is set to, or would 'kvm64'
as model negatively affect my VMs? thx will

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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[reedip banerjee]

-1, need to cancel, will meet you guys tomorrow :)

On Oct 27, 2016 14:50, "Andreas Scheuring" 
wrote:

> -1 I'm sorry, but I also need to cancel.
>
> Andreas
>
> On 10/26/2016 08:10 PM, John McDowall wrote:
>
> -1
>
>
>
> Unfortunately, a business meeting has come up
>
>
>
> Regards
>
>
>
> John
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Disable console for an instance

[George Mihaiescu]

You're right, it's probably the following you would want changed:

"compute:get_vnc_console": "",
"compute:get_spice_console": "",
"compute:get_rdp_console": "",
"compute:get_serial_console": "",
"compute:get_mks_console": "",
"compute:get_console_output": "",

I thought the use case is to limit console access to users in a shared
project environment, where you might have multiple users seeing each other
instances, and you don't want them to try logging on the console.

You could create a special role that has console access and change the
policy file to reference that role for the "compute:get_vnc_console", for
example.

I don't think you can do it on per-flavor basis.

Cheers,
George

On Thu, Oct 27, 2016 at 10:24 AM, Blair Bethwaite  wrote:

> Hi George,
>
> On 27 October 2016 at 16:15, George Mihaiescu 
> wrote:
> > Did you try playing with Nova's policy file and limit the scope for
> > "compute_extension:console_output": "" ?
>
> No, interesting idea though... I suspect it's actually the
> get_*_console policies we'd need to tweak, I think console_output
> probably refers to the console log? Anyway, not quite sure how we'd
> craft policy that would enable us to disable these on a per instance
> basis though - is it possible to reference image metadata in the
> context of the policy rule?
>
> --
> Cheers,
> ~Blairo
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] Search in OpenStack IRC logs

[Vikram Hosakote (vhosakot)]

At the kolla design summit yesterday in Barcelona, someone said there is no
tool to search words in the logs of an OpenStack IRC channel.

https://wiki.openstack.org/wiki/IRC

The OpenStack IRC logs have invaluable information and solutions to many
problems.

Attached is a little script I wrote to search regular expressions in the
#openstack-kolla IRC channel.  It can be updated to search words in any
OpenStack IRC channel.

For example, if you need help about the error "DockerException: Error while
fetching server API version" in the logs of the #openstack-kolla IRC channel,
just do the following.

$ ./search_openstack_irc.py ".*DockerException: Error while fetching server API 
version.*"
Found in  
http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/%23openstack-kolla.2016-09-05.log.html

Below is the snippet in the IRC log.

[cid:FEBA5E60-8D92-47C5-93E9-0F3DA57C2E84]

Hope it helps and let me know if you find any bug in the script!

Regards,
Vikram Hosakote
IRC:  vhosakot
#! /usr/bin/python

##
# 
# Author:  Vikram Hosakote (vhosa...@cisco.com)
#
# This script searches a regular expression in OpenStack Kolla's IRC logs
# in a multi-threaded manner.
#
# The "link" variable in this script can be changed to search any 
# OpenStack project's IRC logs.
#
# For example:  To search OpenStack Neutron IRC logs, set
# link = "http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/;
#
# Usage:   ./search_openstack_irc.py 
#
# Examples:
#
# To search a whole word, escape \b as \\b
#
# $ ./search_openstack_irc.py "\\bvhosakot\\b"
# [u'vhosakot']
# 
# $ ./search_openstack_irc.py "\\bvho\\b"
# 
# $ ./search_openstack_irc.py "vhosakot"
# [u'vhosakot']
# 
# $ ./search_openstack_irc.py "vhosakot.*"
# [u'vhosakot has joined #openstack-kolla15:30']
# 
# $ ./search_openstack_irc.py ".*akot"
# [u'*** vhosakot']
# 
# $ ./search_openstack_irc.py ".*akot.*"
# [u'*** vhosakot has joined #openstack-kolla15:30']
#
##

from bs4 import BeautifulSoup
from multiprocessing import Pool
import re
import sys
import urllib

def print_usage():
print "\
$ ./search_openstack_irc.py \"bvhosakotb\"  \n\
[u'vhosakot']  \n\
  \n\
$ ./search_openstack_irc.py \"bvhob\"  \n\
  \n\
$ ./search_openstack_irc.py \"vhosakot\"  \n\
[u'vhosakot']  \n\
  \n\
$ ./search_openstack_irc.py \"vhosakot.*\"  \n\
[u'vhosakot has joined #openstack-kolla15:30']  \n\
  \n\
$ ./search_openstack_irc.py \".*akot\"  \n\
[u'*** vhosakot']  \n\
  \n\
$ ./search_openstack_irc.py \".*akot.*\"  \n\
[u'*** vhosakot has joined #openstack-kolla15:30']  \n\
"

if len(sys.argv) < 2:
print "\nNothing to search."
print "\nUsage:   ./search_openstack_irc.py \n"
print "Examples:"
print_usage()
sys.exit()

if len(sys.argv) > 2:
print "\nEnter the regular expression to search in quotes."
print "\nUsage:   ./search_openstack_irc.py \n"
print "Examples:"
print_usage()
sys.exit()

regexp_to_search = sys.argv[1]

# The link below can be changed to search any OpenStack project's IRC logs
# For example:  To search OpenStack Neutron IRC logs, set
# link = "http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/;

link = "http://eavesdrop.openstack.org/irclogs/%23openstack-kolla/;
f = urllib.urlopen(link)
irc_page = f.read()

def t_search_in_each_irc_link(irc_link, regexp_to_search):
f = urllib.urlopen(irc_link)
html_page = f.read()
soup = BeautifulSoup(html_page, "lxml")
irc_logs = soup.text
r = re.findall(regexp_to_search, irc_logs, re.IGNORECASE)
if r != []:
print "Found in ", irc_link

pool = Pool(processes=100)

for line in irc_page.splitlines():
if ".html" in line and "href" in line:
link_suffix = re.findall(r'"([^"]*)"', line)[0]
irc_link = link + link_suffix
pool.apply_async(t_search_in_each_irc_link, (irc_link, regexp_to_search))

pool.close()
pool.join()
__
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] Disable console for an instance

[Blair Bethwaite]

Lol! I don't mind - Microsoft do support and produce some pretty good
research, I just wish they'd fix licensing!

On 27 October 2016 at 16:11, Jonathan D. Proulx  wrote:
> On Thu, Oct 27, 2016 at 04:08:26PM +0200, Blair Bethwaite wrote:
> :On 27 October 2016 at 16:02, Jonathan D. Proulx  wrote:
> :> don't put a getty on the TTY :)
> :
> :Do you know how to do that with Windows? ...you can see the desire for
> :sandboxing now :-).
>
> Sigh yes I see, http://goodbye-microsoft.com/ has a good solution IMHO
>
> :--
> :Cheers,
> :~Blairo



-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] Disable console for an instance

[Blair Bethwaite]

Hi George,

On 27 October 2016 at 16:15, George Mihaiescu  wrote:
> Did you try playing with Nova's policy file and limit the scope for
> "compute_extension:console_output": "" ?

No, interesting idea though... I suspect it's actually the
get_*_console policies we'd need to tweak, I think console_output
probably refers to the console log? Anyway, not quite sure how we'd
craft policy that would enable us to disable these on a per instance
basis though - is it possible to reference image metadata in the
context of the policy rule?

-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] Disable console for an instance

[George Mihaiescu]

Hi Blair,

Did you try playing with Nova's policy file and limit the scope for
"compute_extension:console_output": "" ?

Cheers,
George

On Thu, Oct 27, 2016 at 10:08 AM, Blair Bethwaite  wrote:

> On 27 October 2016 at 16:02, Jonathan D. Proulx  wrote:
> > don't put a getty on the TTY :)
>
> Do you know how to do that with Windows? ...you can see the desire for
> sandboxing now :-).
>
> --
> Cheers,
> ~Blairo
>
> ___
> 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] [Horizon] Rework Access & Security panel

[Hayes, Graham]

On 27/10/2016 04:15, Adrian Turjak wrote:
> Hello OpenstackDevs,
>
> In our deployment we keep running into a problem where customers forget
> about the existence of floating ips once disassociated from an instance,
> and when they then need to release them they often can't find where
> because expecting them to be in 'Access & Security' is odd.
>
> Why don't we move Floating ips out to their own panel either at the
> compute or network layer on the dashboard so they are easy to find. They
> are their own resource and having them in a shared panel like Access &
> Security seems usual and rather confusing UX. All the remaining
> resources in Access & Security make sense, but floating ips really
> shouldn't be there.
>
> If there aren't any arguments against it, I can put together a
> blueprint/patch for this myself, but would like to know people are happy
> with the change.
>
> Any alternate ideas? Vehement opposition to the change?

I think it is a great idea :)

We should also move the security groups out to the networking section,
the API access to somewhere else, and just leave SSH keys where they
are.

Having these things under the compute section has always irked me. :)

> Cheers,
> Adrian Turjak
>
>
> __
> 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] Disable console for an instance

[Jonathan D. Proulx]

On Thu, Oct 27, 2016 at 04:08:26PM +0200, Blair Bethwaite wrote:
:On 27 October 2016 at 16:02, Jonathan D. Proulx  wrote:
:> don't put a getty on the TTY :)
:
:Do you know how to do that with Windows? ...you can see the desire for
:sandboxing now :-).

Sigh yes I see, http://goodbye-microsoft.com/ has a good solution IMHO

:-- 
:Cheers,
:~Blairo

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

Re: [Openstack-operators] Disable console for an instance

[Blair Bethwaite]

On 27 October 2016 at 16:02, Jonathan D. Proulx  wrote:
> don't put a getty on the TTY :)

Do you know how to do that with Windows? ...you can see the desire for
sandboxing now :-).

-- 
Cheers,
~Blairo

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

Re: [Openstack-operators] Disable console for an instance

[Jonathan D. Proulx]

On Thu, Oct 27, 2016 at 02:27:48PM +0200, Blair Bethwaite wrote:
:   Looks like this is not currently possible. Does anyone else have an
:   interest in such a feature?
:   I'm thinking about it from the perspective of a public cloud user who
:   wants to build highly secure / sandboxed instances. Having a virtual
:   terminal straight into a guest login prompt, especially one that allows
:   reset of the guest, is not desirable.

don't put a getty on the TTY :)

Of course there's still race conditions where you could get to boot
loader or something.

Snarkless answer: I can imagine a use case for wanting to toggle this
on a per VM basis but don't actually have one myself.

-Jon

:
:   On 13 October 2016 at 04:37, Blair Bethwaite
:   <[1]blair.bethwa...@gmail.com> wrote:
:
: Hi all,
:
: Does anyone know whether there is a way to disable the novnc console
: on a per instance basis?
:
: Cheers,
: Blair
:
:   --
:   Cheers,
:   ~Blairo
:
:References
:
:   1. mailto:blair.bethwa...@gmail.com

:___
: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] [neutron] HostNotCompatibleWithFixedIps exception happens when setting router's gateway.

[Brian Haley]

Hi Zhi,

Thanks for the report, comment below.

On 10/27/2016 05:04 AM, zhi wrote:

Hi, all.

I installed a devstack in my local environment. All the code from master
branch. After the installation, I have to show you some problems which I met.

First of all, I create an external network by this command " neutron
net-create public --router:external=True --provider:network_type=flat
--provider:physical_network=public ".

Secondly, I create a subnet with " subnet_type " by this command " neutron
subnet-create [net-id] 20.20.20.0/24  --service-types
list=true network:router_gateway ".

At last, I create a router and setting this router's gateway by this command
" neutron router-gateway-set [router-id] [net-id]".

Exception happens in Neutron Server, it says "
HostNotCompatibleWithFixedIps: Host devstack is not connected to a segment where
the existing fixed_ips on port 0f38ba01-8dd0-43de-92e3-b294bd4ebed8 will
function given the routed network topology. ".


Subnet service types is new in Newton, and it seems you've found a bug - can you 
file a bug on launchpad for it?


The one thing you might try to get past this is to disable DHCP on these 
subnets, but the error you linked seems different from [1].


-Brian

[1] https://bugs.launchpad.net/neutron/+bug/1636963


After I did some research about the exception,  I found this patch[1] was
adding this exception into neutron repo. I am confused about that. Why setting
router's gateway will trigger this exception? I don't execute any commands about
" routed_network ".

What's wrong ?

Could someone give some advice about that ? I upload all the network and
subnets info at here [2]. Detail exception at here [3].

BTW, what's the meaning of " tags " in network?

Hope for your reply. :)


Thanks
Zhi Chang


[1]. https://review.openstack.org/#/c/346217/3
[2]. http://paste.openstack.org/show/587157/
[3]. http://paste.openstack.org/show/587158/


__
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] [Neutron] Neutron team social event in Barcelona

[Andreas Scheuring]

-1 I'm sorry, but I also need to cancel.

Andreas


On 10/26/2016 08:10 PM, John McDowall wrote:


-1

Unfortunately, a business meeting has come up

Regards

John



__
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] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads

[Matthias Runge]

On 27/10/16 11:08, Erik McCormick wrote:
> The PTG is for devs to get together and get real work done. We would be
> a distraction from that goal. They will also be attending the forum
> which will run with the summits and will be able to spend more time in
> groups with ops for requirements gathering and such.
> 
> -Erik
> 
> 
> On Oct 27, 2016 11:05 AM, "Jesse Keating"  > wrote:
> 
> I may have missed something, but why aren't we meeting at the
> Project Technical Gathering, which is at the end of February in Atlanta?

>From my experience with OpenStack, feedback from operators have been
invaluable.

You can easily run things in devstack (or all-in-one deployments), but
this is completely different from running in scale. Operators do tell
you, were the pain-points are. Having a dedicated gathering without
involving actual operators/users is not that useful IMO.

Matthias
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

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

Re: [Openstack-operators] Disable console for an instance

[Blair Bethwaite]

Looks like this is not currently possible. Does anyone else have an
interest in such a feature?

I'm thinking about it from the perspective of a public cloud user who wants
to build highly secure / sandboxed instances. Having a virtual terminal
straight into a guest login prompt, especially one that allows reset of the
guest, is not desirable.

On 13 October 2016 at 04:37, Blair Bethwaite 
wrote:

> Hi all,
>
> Does anyone know whether there is a way to disable the novnc console on a
> per instance basis?
>
> Cheers,
> Blair
>



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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Sandhya Dasu (sadasu)]

+1

Looking fwd to it.

Sandhya

From: Sukhdev Kapur >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 27, 2016 at 5:57 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1

Count me in...

-Sukhdev


On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
> wrote:
Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

__
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] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads

[Jon Proulx]

Being a 'distraction' isn't exactly the issue.

The ptg/ops-midcycle events are focused inward so where the 'forum' 
(summit-thing) as focused across. The hope is this make us both more effective 
in both directions. 

So there's no need to collocate. Additionally collocation would require bigger, 
more expensive, more difficult to site venues.

Also agreed location is 'not north america'. There's APAC and EU proposals. 
Since it's sandwiched between EU summit and NA summit I'd advocate an APAC 
midcyle to spread the love, but that's IMHO...

On October 27, 2016 11:08:24 AM GMT+02:00, Erik McCormick 
 wrote:
>The PTG is for devs to get together and get real work done. We would be
>a
>distraction from that goal. They will also be attending the forum which
>will run with the summits and will be able to spend more time in groups
>with ops for requirements gathering and such.
>
>-Erik
>
>On Oct 27, 2016 11:05 AM, "Jesse Keating"  wrote:
>
>> I may have missed something, but why aren't we meeting at the Project
>> Technical Gathering, which is at the end of February in Atlanta?
>>
>> I understand that this mid-cycle is targeting EU, which is totally
>> awesome; and if that happens, will there also be operator focused
>sessions
>> and such at the PTG?
>> -jlk
>>
>>
>>
>> - Original message -
>> From: Tom Fifield 
>> To: Chris Morgan , OpenStack Operators <
>> OpenStack-operators@lists.openstack.org>
>> Cc:
>> Subject: Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle
>> Meetups - venue selection etherpads
>> Date: Tue, Oct 25, 2016 6:47 PM
>>
>> Reminder!
>>
>> If you're interested in hosting the Feb/March Ops Meetup, get your
>> proposal in by November 7th! Feel free to ask for help :)
>>
>>
>> Regards,
>>
>>
>>
>> Tom
>>
>> On 廿十六年十月廿日 暮 11:51, Chris Morgan wrote:
>> > Hello Everyone,
>> >
>> > Here are etherpads for the collection of venue hosting proposals
>and
>> > assessment:
>> >
>> >
>https://etherpad.openstack.org/p/ops-meetup-venue-discuss-spring-2017
>> > https://etherpad.openstack.org/p/ops-meetup-venue-discuss-aug-2017
>> >
>> > For your reference, the previous etherpad (for august 2016 was
>> > eventually was decided to be in NYC) was :
>> >
>> > https://etherpad.openstack.org/p/ops-meetup-venue-discuss
>> >
>> > --
>> > Chris Morgan > >>
>>
>> ___
>> 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 mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [openstack-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

Hi all,

We are at Ballroom B. First table on the right.

Best regards,
Igor.


-Original Appointment-
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, October 24, 2016 3:45 PM
To: OpenStack Development Mailing List (not for usage questions); Miguel Angel 
Ajo Pelayo; 'Ihar Hrachyshka'; 'Vikram Choudhary'; 'Sean M. Collins'; 'Haim 
Daniel'; 'Mathieu Rohon'; Shaughnessy, David; Eichberger, German; Cathy Zhang; 
Henry Fourie; Armando M.
Subject: [openstack-dev] [neutron] [classifier] At the Summit: Common 
Classifier + OVS Flow Management
When: 27 October 2016 12:30-14:00 (UTC+01:00) Brussels, Copenhagen, Madrid, 
Paris.
Where: Hilton (P0 - Ballroom Foyer)


Hi again,

I'm setting the meeting for Thursday 12:30pm, at the Hilton (P0 - Ballroom 
Foyer).
Let's gather together and talk about these 2 efforts.

_
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Thursday, October 20, 2016 3:08 PM
To: 
openstack-dev@lists.openstack.org; 
Miguel Angel Ajo Pelayo >; 
'Ihar Hrachyshka' >; 'Vikram 
Choudhary' >; 
'Sean M. Collins' >; 'Haim 
Daniel' >; 'Mathieu Rohon' 
>; Shaughnessy, David 
>; Eichberger, 
German >; Cathy 
Zhang >; Henry Fourie 
>; Armando M. 
>
Subject: [openstack-dev] [neutron] [classifier] At the Summit: Common 
Classifier + OVS Flow Management


Hi,

Two etherpads were created on the last meeting as placeholders to what can be 
discussed at the summit regarding the common classification 
framework/classifier and the OVS flow manager:
https://etherpad.openstack.org/p/neutron-common-classification-framework-barcelona
https://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona
Feel free to add topics to the pads.

How/where would you like to meet at the summit to discuss future work on these 
2 efforts?
I'm okay meeting during lunch time from Tuesday to Friday, or even during 
Monday, or at the contributors meet-up on Friday.
Thoughts?

Best regards,
Igor.
  << File: ATT1.txt >>

__
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] Neutron team social event in Barcelona

[Sukhdev Kapur]

+1

Count me in...

-Sukhdev


On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> 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] [NSX][DVS] Multiple dvs config in single neutron instance

[Vaidyanath Manogaran]

Can I manage multiple dv switches with a single neutron?
I have a single entry in the nsx.ini but can I have multiple entries of DVS
in nsx,ini?

-- 
Regards,

Vaidyanath
+91-9483465528(M)
___
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-operators] Live-migration CPU doesn't have compatibility

[Chris Friesen]

On 10/26/2016 06:07 AM, William Josefsson wrote:

Hi list,

I'm facing issues on Liberty/CentOS7 doing live migrations between to
hosts. The hosts are Haswell and Broadwell. However, there is not
feature specific running on my VMs

Haswell -> Broadwell works
Broadwell -> Haswell fails with the error below.


I have on both hosts configured
[libvirt]
cpu_mode=none

and restarted openstack-nova-compute on hosts, however that didn't
help, with the same error. there gotta be a way of ignoring this
check? pls advice. thx will


If you are using kvm/qemu and set cpu_mode=none, then it will use 'host-model', 
and any instances started on Broadwell can't be live-migrated onto Haswell.


In your case you probably want to set both computes to have:

[libvirt]
cpu_mode = custom
cpu_model = Haswell

This will cause nova to start guests with the "Haswell" model on both nodes.

Chris

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

Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle Meetups - venue selection etherpads

[Erik McCormick]

The PTG is for devs to get together and get real work done. We would be a
distraction from that goal. They will also be attending the forum which
will run with the summits and will be able to spend more time in groups
with ops for requirements gathering and such.

-Erik

On Oct 27, 2016 11:05 AM, "Jesse Keating"  wrote:

> I may have missed something, but why aren't we meeting at the Project
> Technical Gathering, which is at the end of February in Atlanta?
>
> I understand that this mid-cycle is targeting EU, which is totally
> awesome; and if that happens, will there also be operator focused sessions
> and such at the PTG?
> -jlk
>
>
>
> - Original message -
> From: Tom Fifield 
> To: Chris Morgan , OpenStack Operators <
> OpenStack-operators@lists.openstack.org>
> Cc:
> Subject: Re: [Openstack-operators] 2017 Openstack Operators Mid-Cycle
> Meetups - venue selection etherpads
> Date: Tue, Oct 25, 2016 6:47 PM
>
> Reminder!
>
> If you're interested in hosting the Feb/March Ops Meetup, get your
> proposal in by November 7th! Feel free to ask for help :)
>
>
> Regards,
>
>
>
> Tom
>
> On 廿十六年十月廿日 暮 11:51, Chris Morgan wrote:
> > Hello Everyone,
> >
> > Here are etherpads for the collection of venue hosting proposals and
> > assessment:
> >
> > https://etherpad.openstack.org/p/ops-meetup-venue-discuss-spring-2017
> > https://etherpad.openstack.org/p/ops-meetup-venue-discuss-aug-2017
> >
> > For your reference, the previous etherpad (for august 2016 was
> > eventually was decided to be in NYC) was :
> >
> > https://etherpad.openstack.org/p/ops-meetup-venue-discuss
> >
> > --
> > Chris Morgan  >>
>
> ___
> 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 mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [neutron] HostNotCompatibleWithFixedIps exception happens when setting router's gateway.

[zhi]

Hi, all.

I installed a devstack in my local environment. All the code from
master branch. After the installation, I have to show you some problems
which I met.

First of all, I create an external network by this command " neutron
net-create public --router:external=True --provider:network_type=flat
--provider:physical_network=public ".

Secondly, I create a subnet with " subnet_type " by this command "
neutron subnet-create [net-id] 20.20.20.0/24 --service-types list=true
network:router_gateway ".

At last, I create a router and setting this router's gateway by this
command " neutron router-gateway-set [router-id] [net-id]".

Exception happens in Neutron Server, it says "
HostNotCompatibleWithFixedIps: Host devstack is not connected to a segment
where the existing fixed_ips on port 0f38ba01-8dd0-43de-92e3-b294bd4ebed8
will function given the routed network topology. ".

After I did some research about the exception,  I found this patch[1]
was adding this exception into neutron repo. I am confused about that. Why
setting router's gateway will trigger this exception? I don't execute any
commands about " routed_network ".

What's wrong ?

Could someone give some advice about that ? I upload all the network
and subnets info at here [2]. Detail exception at here [3].

BTW, what's the meaning of " tags " in network?

Hope for your reply. :)


Thanks
Zhi Chang


[1]. https://review.openstack.org/#/c/346217/3
[2]. http://paste.openstack.org/show/587157/
[3]. http://paste.openstack.org/show/587158/
__
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] [OpenStack][Nova][virt][hyperv]

[zhaolihuisky]

Thanks for reply.
I have fellowed this doc to install nova-compute.But there was an error on the 
step with command 'C:\Python27\python.exe c:\Python27\Scripts\nova-compute 
--config-file c:\etc\nova\nova.conf', and error is:"  File 
"C:\Python27\Scripts\nova-compute.exe", line 1
SyntaxError: Non-ASCII character '\x90' in file 
C:\Python27\Scripts\nova-compute.exe on line 1, but no encoding declared
; see http://python.org/dev/peps/pep-0263/ for 
details"--From:Matt
 Riedemann Send Time:2016年10月27日(星期四) 
16:14To:openstack Subject:Re: [Openstack] 
[OpenStack][Nova][virt][hyperv]
On 10/27/2016 8:38 AM, zhaolihuisky wrote:
> Hi, all
> I want to use hyperv.
> How to install nova-compute with source code on windows 2012 operation system?
>
> Best Regards.
> ___
> 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
>

http://docs.openstack.org/newton/config-reference/compute/hypervisor-hyper-v.html

Claudiu Belu is a good contact for this. He works on the hyper-v compute 
driver code in Nova.

-- 

Thanks,

Matt Riedemann


___
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] [OpenStack][Nova][virt][hyperv]

[Matt Riedemann]

On 10/27/2016 8:38 AM, zhaolihuisky wrote:

Hi, all
I want to use hyperv.
How to install nova-compute with source code on windows 2012 operation system?

Best Regards.
___
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



http://docs.openstack.org/newton/config-reference/compute/hypervisor-hyper-v.html

Claudiu Belu is a good contact for this. He works on the hyper-v compute 
driver code in Nova.


--

Thanks,

Matt Riedemann


___
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] Resigning from horizon core

[David Lyle]

Thank you Matthias for all your contributions over the past several
years. Horizon is much better for having you and I have personally
benefited from your leadership and mentoring.

Thank you,
David

On Wed, Oct 26, 2016 at 5:27 PM, Matthias Runge  wrote:
> Hello,
>
> this has been long due (and thank you Richard for reminding me),
> my job responsibilities changed a while ago, and I don't have the
> time anymore to review patches in Horizon or even to submit new ones.
>
> Please remove my horizon core status (and the horizon-stable-maint as
> well).
>
> Thank you, and best,
> Matthias
> --
> Matthias Runge 
>
> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Michael Cunningham,
> Michael O'Neill, Eric Shander
>
> __
> 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] [Neutron] Neutron team social event in Barcelona

[Trinath Somanchi]

-1.

Occupied for the day.

From: Mohan Kumar [mailto:nmohankumar1...@gmail.com]
Sent: Wednesday, October 26, 2016 7:44 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1

On Sat, Oct 15, 2016 at 12:00 AM, Miguel Lavalle 
> wrote:
Dear Neutrinos,
I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm
It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.
Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

__
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] [OpenStack][Nova][virt][hyperv]

[zhaolihuisky]

Hi, all
I want to use hyperv.
How to install nova-compute with source code on windows 2012 operation system?

Best Regards.
___
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] Your draft logo & a sneak peek

[Steven Hardy]

On Wed, Oct 26, 2016 at 05:09:54PM +0200, Carlos Camacho Gonzalez wrote:
> Here you have my 2 cents,
> 
> I think the proposed draft does not fit with what we currently have/want.
> 
> I'm 100% sure that can be improved but here it goes.

Thanks to everyone for the feedback (both on and off list), but a quick
reminder, please do provide your feedback via the link in the original mail
(http://tinyurl.com/OSmascot).  This will ensure that your concerns are
seen by the team producing the logos, so hopefully another revision can be
produced which everyone is happy with.

FWIW I do agree this initial logo does somewhat miss the mark and I'm
hoping we'll be able to reach another revision which is more in keeping
with (and/or more directly derived from) our current logo.

Thanks!

Steve

__
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] [Ceilometer]: Instance creation and deletion metrics in ceilometer !

[Ganpat Agarwal]

Hi Raghunath,

I am not able to understand your use case for compute.instance.* events.

You are trying to catch the instance start and end events OR you want the
samples related with these events?

Regards,
Ganpat

On Wed, Oct 26, 2016 at 6:00 PM, Raghunath D  wrote:

> Hi Ganpat/Gord,
>
> Callback for compute.instance.create.end events under 
> ceilometer.compute.notifications
> should be invoked for those notification events on the nova exchange using
> the notifications.info topic.
> But this is not happening,we can see events related to them and can
> receive events over kafka.
>
> I can see from logs which print my debug print during the loading of
> notification plugin.
> "2016-10-26 03:46:32.010 34977 INFO ceilometer.compute.notifications.instance
> [req-1ad3d5c9-5eab-404d-9fbe-f1605e93691f - - - - -] Check
> ComputeInstanceNotificationBase notification:"
>
> Do we need to change any thing in the configuration file of ceilometer or
> nova to achive this.
> It would be great help for me if this is fixed.
>
> With Best Regards
> Raghunath Dudyala
> Tata Consultancy Services Limited
> Mailto: raghunat...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -Ganpat Agarwal  wrote: -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: Ganpat Agarwal 
> Date: 10/25/2016 09:32PM
>
> Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion
> metrics in ceilometer !
>
> Hi Raghunath,
>
> You can look at this file for details of meters related with
> compute.instance.*
>
> ceilometer/meter/data/meters.yaml
>
> Additionally, you can look at this link for compute meters documentation
>
> http://docs.openstack.org/admin-guide/telemetry-measurements.html
>
>
> Also, have a look at "Meters definitions" section on this link
>
> http://docs.openstack.org/admin-guide/telemetry-data-
> collection.html#meter-definitions
>
> Regards,
> Ganpat
>
>
> On Tue, Oct 25, 2016 at 5:45 PM, Raghunath D  wrote:
>
>> Hi Ganpat,
>>
>>  Are you able to see merers/samples related to compute.instance.* in
>> ceilometer meter-list or ceilometer sample-list.
>> My application which will read info from ceilometer publisher
>> (pipeline.yaml) and I am looking for meters realted to ceilometer.instance.*
>>
>> With Best Regards
>> Raghunath Dudyala
>> Tata Consultancy Services Limited
>> Mailto: raghunat...@tcs.com
>> Website: http://www.tcs.com
>> 
>> Experience certainty. IT Services
>> Business Solutions
>> Consulting
>> 
>>
>>
>> -Ganpat Agarwal  wrote: -
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> From: Ganpat Agarwal 
>> Date: 10/25/2016 05:05PM
>> Subject: Re: [openstack-dev] [Ceilometer]: Instance creation and deletion
>> metrics in ceilometer !
>>
>>
>> Hi,
>>
>> I am able to get event notifications on kafka by applying these
>> configurations:
>>
>> nova.conf
>>
>> instance_usage_audit = True
>>
>> instance_usage_audit_period = hour
>>
>> notify_on_state_change = vm_and_task_state
>>
>> notification_driver = messagingv2
>>
>> Restart nova compute service
>>
>> ceilometer.conf
>>
>> [event]
>>
>> drop_unmatched_notifications = False
>>
>> definitions_cfg_file = /etc/ceilometer/event_definitions.yaml
>>
>>
>> event_pipeline.yaml
>>
>> ---
>>
>> sources:
>>
>> - name: event_source
>>
>>   events:
>>
>>  - compute.instance.*
>>
>>   sinks:
>>
>>   - event_sink
>>
>> sinks:
>>
>> - name: event_sink
>>
>>   transformers:
>>
>>   triggers:
>>
>>   publishers:
>>
>>   #- notifier://
>>
>>   #- file:///home/stack/test?max_bytes=1000_count=5
>>
>>   - kafka://kafka-broker:9092?topic=ceilometer
>>
>>
>> service ceilometer-api restart
>>
>> service ceilometer-agent-notification restart
>>
>>
>> Wait for couple of minutes and you should be getting the events on your
>> kafka consumer and in ceilometer notifications logs as well
>>
>> tail -f /var/log/ceilometer/ceilometer-agent-notification.log
>>
>>
>> Let me know if it helps.
>>
>>
>> Regards,
>>
>> Ganpat
>>
>>
>>
>> On Tue, Oct 25, 2016 at 3:02 PM, Raghunath D  wrote:
>>
>>> Hi ,
>>>
>>> Can some one please suggest how to instance notifications in ceilometer.
>>>
>>> With Best Regards
>>> Raghunath Dudyala
>>> Tata Consultancy Services Limited
>>> Mailto: raghunat...@tcs.com
>>> Website: http://www.tcs.com
>>> 
>>> Experience certainty. IT Services
>>> Business Solutions
>>> Consulting
>>> 

[OpenStack-Infra] [kolla][ci] Can someone from infra make it to a Kolla session today?

[Steven Dake (stdake)]

Hey infra folks,

https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/17109/kolla-work-session

Thursday 3:30 – 4:10

One of the main topics will be multi-node gating.  We have multi node gating in 
kolla-kubernetes with 2 nodes.  We need 3, 4, 5 :)

We want to go to 4 nodes if possible next (3 HA + 1 compute).  There is no 
resource type to make this happen in pc atm.  I have heard that this is 
possible with zuul v3 but we don’t want to wait until March if at all possible.

Unfortunately I have a presentation conflict at this time – but please 
introduce yourself to Michal (Kolla PTL) and I’m sure he can get the discussion 
going.

Regards
-steve

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