Re: [openstack-dev] [Openstack-operators] [openstack-operators][neutron[dhcp][dnsmask]: duplicate entries in addn_hosts causing no IP allocation

[Daniel Comnea]

Hi,

sorry for no feedback, i've been doing more and more test and after enabled
the dnsmasq log i found the error which i'm not longer sure if is related
to having duplicated entries

dnsmasq-dhcp[21231]: 0 DHCPRELEASE(tap8ecf66b6-72) 192.168.111.24
fa:16:3e:72:04:82 unknown lease

Looking around it seems i'm hitting this bug [1] but not clear from the
description what was the problem on dnsmasp 2.59 (which comes wiht Fuel 5.1)

Any ideas?

Cheers,
Dani

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

On Wed, Jun 10, 2015 at 7:13 AM, Daniel Comnea 
wrote:

> Thanks a bunch Kevin!
>
> I'll try this patch and report back.
>
> Dani
>
>
> On Tue, Jun 9, 2015 at 2:50 AM, Kevin Benton  wrote:
>
>> Hi Daniel,
>>
>> I'm concerned that we are encountered out-of-order port events on the
>> DHCP agent side so the delete message is processed before the create
>> message. Would you be willing to apply a small patch to your dhcp agent to
>> see if it fixes the issue?
>>
>> If it does fix the issue, you should see occasional warnings in the DHCP
>> agent log that show "Received message for port that was already deleted".
>> If it doesn't fix the issue, we may be losing the delete event entirely. If
>> that's the case, it would be great if you can enable debuging on the agent
>> and upload a log of a run when it happens.
>>
>> Cheers,
>> Kevin Benton
>>
>> Here is the patch:
>>
>> diff --git a/neutron/agent/dhcp_agent.py b/neutron/agent/dhcp_agent.py
>> index 71c9709..9b9b637 100644
>> --- a/neutron/agent/dhcp_agent.py
>> +++ b/neutron/agent/dhcp_agent.py
>> @@ -71,6 +71,7 @@ class DhcpAgent(manager.Manager):
>>  self.needs_resync = False
>>  self.conf = cfg.CONF
>>  self.cache = NetworkCache()
>> +self.deleted_ports = set()
>>  self.root_helper = config.get_root_helper(self.conf)
>>  self.dhcp_driver_cls =
>> importutils.import_class(self.conf.dhcp_driver)
>>  ctx = context.get_admin_context_without_session()
>> @@ -151,6 +152,7 @@ class DhcpAgent(manager.Manager):
>>  LOG.info(_('Synchronizing state'))
>>  pool = eventlet.GreenPool(cfg.CONF.num_sync_threads)
>>  known_network_ids = set(self.cache.get_network_ids())
>> +self.deleted_ports = set()
>>
>>  try:
>>  active_networks = self.plugin_rpc.get_active_networks_info()
>> @@ -302,6 +304,10 @@ class DhcpAgent(manager.Manager):
>>  @utils.synchronized('dhcp-agent')
>>  def port_update_end(self, context, payload):
>>  """Handle the port.update.end notification event."""
>> +if payload['port']['id'] in self.deleted_ports:
>> +LOG.warning(_("Received message for port that was "
>> +  "already deleted: %s"), payload['port']['id'])
>> +return
>>  updated_port = dhcp.DictModel(payload['port'])
>>  network = self.cache.get_network_by_id(updated_port.network_id)
>>  if network:
>> @@ -315,6 +321,7 @@ class DhcpAgent(manager.Manager):
>>  def port_delete_end(self, context, payload):
>>  """Handle the port.delete.end notification event."""
>>  port = self.cache.get_port_by_id(payload['port_id'])
>> +self.deleted_ports.add(payload['port_id'])
>>  if port:
>>  network = self.cache.get_network_by_id(port.network_id)
>>  self.cache.remove_port(port)
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 8, 2015 at 8:26 AM, Daniel Comnea 
>> wrote:
>>
>>> Any help, ideas please?
>>>
>>> Thx,
>>> Dani
>>>
>>> On Mon, Jun 8, 2015 at 9:25 AM, Daniel Comnea 
>>> wrote:
>>>
 + Operators

 Much thanks in advance,
 Dani




 On Sun, Jun 7, 2015 at 6:31 PM, Daniel Comnea 
 wrote:

> Hi all,
>
> I'm running IceHouse (build using Fuel 5.1.1) on Ubuntu where dnsmask
> version 2.59-4.
> I have a very basic network layout where i have a private net which
> has 2 subnets
>
>  2fb7de9d-d6df-481f-acca-2f7860cffa60 | private-net
>| e79c3477-d3e5-471c-a728-8d881cf31bee
> 192.168.110.0/24 |
> |
> | |
> f48c3223-8507-455c-9c13-8b727ea5f441 192.168.111.0/24 |
>
> and i'm creating VMs via HEAT.
> What is happening is that sometimes i get duplicated entries in [1]
> and because of that the VM which was spun up doesn't get an ip.
> The Dnsmask processes are running okay [2] and i can't see anything
> special/ wrong in it.
>
> Any idea why this is happening? Or are you aware of any bugs around
> this area? Do you see a problems with having 2 subnets mapped to 1
> private-net?
>
>
>
> Thanks,
> Dani
>
> [1]
> /var/lib/neutron/dhcp/2fb7de9d-d6df-481f-acca-2f7860cffa60/addn_hosts
> [2]
>
> nobody5664 1  0 Jun02 ?00:00:08 dnsmasq --no-hosts
> --no-resolv --strict-order --bind-interfaces --inte

[openstack-dev] Magnum Midcycle Event Scheduling Doodle Poll closes July 7th

[Steven Dake (stdake)]

Ton Ngo of IBM Silicon Valley Research has graciously offered to host the 2 day 
Magnum midcycle event at IBM’s facilities.

The sessions will run from 9AM – 5PM and catered lunch and refreshments 
(soda/water) will be provided.

The mid-cycle will be a standard mid-cycle with a 1 hour introduction followed 
by two days of design sessions.

Please cast your votes on any days you can make.

http://doodle.com/pinkuc5hw688zhxw

There are ~25 seats available.  Preference will be given to in-person core 
reviewers, followed by any folks that have made commits to the repository.  
After dates are settled, a separate eventbrite event will be setup to sort out 
the specifics such as  dietary needs, etc and confirm in-person seating if we 
are past capacity limits.

We will make remote participation available, but the experience will likely be 
less then optimal for remote participants.

Regards
-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

[openstack-dev] [Neutron] - breaking changes for plugins/drivers

[Kevin Benton]

Hi,

We have had at least two breaking changes merge this week for out-of-tree
drivers/plugins. These are just the two I noticed that broke the Big Switch
CI (the one I keep an eye on since I had set it up):

1. Removed test_lib that changes config files.
https://review.openstack.org/#/c/196583/
2. Removed the loopingcall common util with no deprecation cycle or
announcement. https://review.openstack.org/#/c/192999/

I proposed a revert for 1 that merged, but I don't particularly want to
keep fighting this. What is our current policy on this? Just change
whatever we want and tell plugin maintainers this is just the way things
work?

-- 
Kevin Benton
__
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] dangerous allowed_address_pairs?

[Kevin Benton]

Yes, this is expected behavior. Allows address pairs were mainly intended
for a few extra IP addresses that the port owns. Using /0 implies that the
Neutron port is responsible for all of those addresses. So if you allow
traffic from that Neutron port, it allows traffic from /0.

The router use-case should probably be documented to use either a separate
security group or to disable the security groups completely on the router
port using the port-security-enabled flag.
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-ovs-portsecurity.html


On Tue, Jun 30, 2015 at 6:42 PM, James Dempsey 
wrote:

> Hi All,
>
> Would someone help me understand some potentially dangerous interactions
> between allowed_address_pairs and security groups?  My cloud is Icehouse
> at the moment, but the behaviour seems unchanged in master. [1]
>
> Suppose a User wants to build an instance that acts as a router.
>
> User creates an instance named ROUTER with an interface that has an
> allowed_address_pair of 0.0.0.0/0. (to bypass the anti-spoofing security
> group feature)
>
> By default, ROUTER is in the 'default' security group.
>
> User also creates an instance named WEB.
>
> By default, WEB is in the 'default' security group.
>
> The 'default' security group allows inbound traffic from other hosts(and
> associated allowed_address_pairs) in the 'default' security group.
>
> Now, WEB receives all traffic from 0.0.0.0/0 because User didn't realize
> that allowed_address_pairs associated with ROUTER would effectively
> change all associated security groups to be fully permissive.
>
>
> Have I missed something?  This seems like exceedingly dangerous
> behaviour.  I've already seen two instances of this from my users.
>
> [1]
>
> https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L287
>
> Cheers,
> James
>
>
> --
> James Dempsey
> Senior Cloud Engineer
> Catalyst IT Limited
> +64 4 803 2264
> --
>
> __
> 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
>



-- 
Kevin Benton
__
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] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Kevin Benton]

This looks like a different issue. The problem you have identified is
specific to a DHCP agent port being deleted.

Shraddha's question seems to be about all ports. All of the port
information is synced on startup via sync_state here:
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L147
so there shouldn't be any issues there.



On Tue, Jun 30, 2015 at 7:09 PM, shihanzhang  wrote:

> hi Shraddha Pandhe,
>   I think your analysis is right, I also encountered the same problem， I
> have filed a bug[1] and commit a patch [2] for this bug.
>
> thanks,
>   hanzhang shi
>
> [1] https://launchpad.net/bugs/1469615
> [2] https://review.openstack.org/#/c/196927/
>
>
> 在 2015-07-01 08:25:48，"Shraddha Pandhe"  写道：
>
> Hi folks..
>
> I have a question about neutron dhcp agent restart scenario. It seems
> like, when the agent restarts, it recovers the known network IDs in cache,
> but we don't recover the known ports [1].
>
> So if a port that was present before agent restarted, is deleted after
> agent restart, the agent wont have it in its cache. So port here [2] will
> be None. So the port will actually never get deleted.
>
> Same problem will happen if a port is updated. Has anyone seen these
> issues? Am I missing something?
>
> [1]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87
> [2]
> https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
>
>
>
>
> __
> 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
>
>


-- 
Kevin Benton
__
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] [Glance] Liberty mid-cycle meet up.

[Bhandaru, Malini K]

Nikhil any chance we can have remote participation? Based on the agenda folks 
can remote dial in.
Regards,
Malini

From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
Sent: Tuesday, June 30, 2015 9:19 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Glance] Liberty mid-cycle meetup.

Hi all,
As discussed in the earlier Glance weekly meeting, the mid-cycle meetup for 
Glance would be at Blacksburg, VA from July 28-July30. A tentative schedule and 
some details have been put in the etherpad. Please fill in your details in the 
survey and the etherpad so as to help the site manager handle surrounding 
details.

https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup
Thanks,
Nikhil
__
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] [kolla][release] Announcing Liberty-1 release of Kolla

[Sam Yaple]

Ian,

The most significant difference would be that Kolla uses image based
deployment rather than building from source on each node at runtime
allowing for a more consistent and repeatable deployment.

On Tue, Jun 30, 2015 at 2:28 PM, Ian Cordasco 
wrote:

>
>
> On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>
> >The Kolla community
> >is pleased to announce the
> > release of the
> > Kolla Liberty 1 milestone.  This release fixes 56 bugs
> > and implements 14 blueprints!
> >
> >
> >Our community developed the following notable features:
> >
> >
> >
> >* A start at
> >source-basedcontainers
>
> So how does this now compare to the stackforge/os-ansible-deployment (soon
> to be openstack/openstack-ansible) project?
>
> __
> 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] [nova] schedule instance based on CPU frequency ?

[ChangBo Guo]

thanks Dan and Jay,  we don't need add new scheduler for that  :-),
what about provide cpu frequency to  api  /os-hypervisors,  that  means we
can
report this value automatically,  the value can be used in high level mange
tools.

2015-07-01 2:58 GMT+08:00 Jay Pipes :

> On 06/30/2015 02:42 AM, ChangBo Guo wrote:
>
>> CPU frequency  is an import performance parameter,  currently  nova
>> drivers just  report cpu_info without frequency.   we stored the compute
>> node cpu_info in database with colum compute_nodes.cpu_info,  we can add
>> the frequency  easily.
>>
>> The usage of  cpu frequency  I  can think is used to schedule to meet
>> applications which need high frequency.  add a frequency based filter ?
>> if we need this , I would like to propose  a spec for this .
>>
>>
>> There are two steps to leverage cpu frequency:
>> 1.  report cpu frequency  and record the value,  nova hypervisor-show
>> will include the value .
>>
>> 2.  filter compute nodes based  cpu frequency.
>>  add a new scheduler filter to do that
>>
>> before I start to do these stuff.  I would like to your  input .
>>
>> Do we need leverage CPU frequency  in Nova ?
>> if yes, do we need a new filter  or  leverage existing filter to use
>> frequency ?
>>
>
> Like Dan B, I question whether CPU frequency really is a useful metric for
> scheduling decisions.
>
> That said, it is already possible to use CPU frequency in the
> MetricsWeigher scheduler weigher. The compute monitor plugin system is
> currently being overhauled [1], but the functionality to monitor
> CPU-related metrics already exists in Nova and can be enabled by doing the
> following in your nova-compute nova.conf:
>
> compute_monitors = ComputeDriverCPUMonitor
>
> Note that with the refactoring of the monitoring plugin interface, the
> above option will change due to using stevedore to load monitor extensions:
>
> compute_monitors = nova.compute.monitors.cpu.virt_driver:Monitor
>
> In your Nova scheduler nova.conf, you will need to add the following in
> the [metrics] section of the file:
>
> weights_setting = cpu.frequency=10.0
>
> Again, I'm not saying that the above will result in any appreciable
> enhancement to the scheduler's decision-making, but it will do what you're
> trying to accomplish :)
>
> Best,
> -jay
>
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1468012,n,z
>
>
> __
> 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
>



-- 
ChangBo Guo(gcb)
__
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] [Glance] Liberty mid-cycle meetup.

[Nikhil Komawar]

Hi all,

As discussed in the earlier Glance weekly meeting, the mid-cycle meetup for
Glance would be at Blacksburg, VA from July 28-July30. A tentative schedule
and some details have been put in the etherpad. Please fill in your details
in the survey and the etherpad so as to help the site manager handle
surrounding details.

https://etherpad.openstack.org/p/liberty-glance-mid-cycle-meetup

Thanks,
Nikhil
__
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] [nova][scheduler] New Scheduler Meeting Time

[Dugger, Donald D]

What Ed said.  I've proposed a change to the infra tree that should percolate 
this time change up through the system but, starting next Mon, 4/6, we'll be 
talking scheduler at the new time & place.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-Original Message-
From: Ed Leafe [mailto:e...@leafe.com] 
Sent: Tuesday, June 30, 2015 3:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][scheduler] New Scheduler Meeting Time

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So the poll results are in, and it looks like we have a winner:
Mondays at 1400 UTC. It seems that the #openstack-meeting-alt channel is the 
only one available, so we'll use that.

Don Duggar will be updating the wiki and other official resources to reflect 
this, but I wanted to send something out now so that you can update your 
calendars. See you Monday!

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVkxEkAAoJEKMgtcocwZqLGAcP/3HQqJ8zlEjtlLL0yac6+zK/
05F6puIXuQzpdGV1AZHXKtNqcjdm7a3m4YMgiozaLG7Svoi7dCbWbflapu5XSkDV
BHGDUkOM/yLnO1pVnmWGN4c5qdv2o/UxLwlLNmFOCgtoee7J9Gh0wZecUvIM107p
ddWqNiQqdn8Nl47X+/L+NdOp9TjjGzgB2cJrjiyHUc8GIq+pm7j/5gCg7Q7RCWvq
6EZzebrMOP6BrVHBMyjnrv7J+9oPMqHtsUonCmBloAQ6frZ/kse3Kxl/DGp8IHMI
DxJkl3bROv8heiiRsHwN7Po75Cv3ImAj0O86dER4ACGTkoWUfQZOTXWVnkPc/xxb
AeTNFX3KgkOUEJ7XHzqEeHu3VmYqZ7exj2LZCLwI7W5PfhpzD8KbC68HTne9mNla
RXYCW0RDcS80p1q9xxSfmJZl88HONrbaoXb3xcGaROhEQFhjQEiNo1cvheR/X9B8
hx5I7zNMErBSnMxRdyA5Vu0mXUC9cyUdYaXCxdoNw4RC7ZAt/u3NxNaovjUMDGv0
Vum/AgozxRlrBmRzIJRE3oegtp+bVkYJ6nDg1PVUrCQ8KKQenFWEErwQeKbK++8J
81chRjsXwrl7fnM4F7nIbGbVzOUD3Bida33DOa6pkOoxHkz2vDHNGhqs5ZfyS44R
zTKrXMHrU5XHHOockryS
=OjA3
-END PGP SIGNATURE-

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

__
OpenStack 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] [Magnum] Continuing with heat-coe-templates

[Kai Qiang Wu]

For @Tom's suggestion, I +1 about it, maintain a separate
heat-coe-templates is very inefficient.[As @HongBin's comments below]



Thanks


Best Wishes,

Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wk...@cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
 No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193

Follow your heart. You are miracle!



From:   "Fox, Kevin M" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   06/30/2015 11:40 PM
Subject:Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates



Whats the timeframe? I was really hoping for Liberty but its sounding like
thats unlikely? M then? The app catalog really needs conditionals for the
same reason. :/

Thanks,
Kevin

From: Angus Salkeld [asalk...@mirantis.com]
Sent: Monday, June 29, 2015 6:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M  wrote:
  Needing to fork templates to tweak things is a very common problem.

  Adding conditionals to Heat was discussed at the Summit. (
  https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I
  want to say, someone was going to prototype it using YAQL, but I don't
  remember who.

I was going to do that, but I would not expect that ready in a very short
time frame. It needs
some investigation and agreement from others. I'd suggest making you
decision based
on what we have now.

-Angus


  Would it be reasonable to keep if conditionals worked?

  Thanks,
  Kevin
  
  From: Hongbin Lu [hongbin...@huawei.com]
  Sent: Monday, June 29, 2015 3:01 PM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

  Agree. The motivation of pulling templates out of Magnum tree is hoping
  these templates can be leveraged by a larger community and get more
  feedback. However, it is unlikely to be the case in practise, because
  different people has their own version of templates for addressing
  different use cases. It is proven to be hard to consolidate different
  templates even if these templates share a large amount of duplicated code
  (recall that we have to copy-and-paste the original template to add
  support for Ironic and CoreOS). So, +1 for stopping usage of
  heat-coe-templates.

  Best regards,
  Hongbin

  -Original Message-
  From: Tom Cammann [mailto:tom.camm...@hp.com]
  Sent: June-29-15 11:16 AM
  To: openstack Development Mailing List (not for usage questions)
  Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates

  Hello team,

  I've been doing work in Magnum recently to align our templates with the
  "upstream" templates from larsks/heat-kubernetes[1]. I've also been
  porting these changes to the stackforge/heat-coe-templates[2] repo.

  I'm currently not convinced that maintaining a separate repo for Magnum
  templates (stackforge/heat-coe-templates) is beneficial for Magnum or the
  community.

  Firstly it is very difficult to draw a line on what should be allowed
  into the heat-coe-templates. We are currently taking out changes[3] that
  introduced "useful" autoscaling capabilities in the templates but that
  didn't fit the Magnum plan. If we are going to treat the
  heat-coe-templates in that way then this extra repo will not allow
  organic development of new and old container engine templates that are
  not tied into Magnum.
  Another recent change[4] in development is smart autoscaling of bays
  which introduces parameters that don't make a lot of sense outside of
  Magnum.

  There are also difficult interdependency problems between the templates
  and the Magnum project such as the parameter fields. If a required
  parameter is added into the template the Magnum code must be also updated
  in the same commit to avoid functional test failures. This can be avoided
  using "Depends-On:
  #xx"
  feature of gerrit, but it is an additional overhead and will require some
  CI setup.

  Additionally we would have to version the templates, which I assume would
  be necessary to allow for packaging. This brings with it is own problems.

  As far as I am aware there are no other people using the
  heat-coe-templates beyond the Magnum team, if we want independent growth
  of this repo it will need to be adopted by other people rather than
  Magnum commiters.

  I don't see the heat templates as a dependency of Magnum, I see them as a
  truly fundamental part of Magnum which is going to be very difficult to
  cut out and make reusable without compromising Magnum's develo

Re: [openstack-dev] [puppet] weekly meeting #40

[Emilien Macchi]

We did our meeting, you can read the notes here:
http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-30-15.00.html

Best,

On Sun, Jun 28, 2015 at 3:01 PM, Emilien Macchi  wrote:

> Hi everyone,
>
> Here's an initial agenda for our weekly meeting next Tuesday at 1500 UTC
> in #openstack-meeting-4:
>
> https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150630
>
> Please add additional items you'd like to discuss.
> --
> Emilien Macchi
>
>
> __
> 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
>
>


-- 
Emilien Macchi
__
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] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[shihanzhang]

hi Shraddha Pandhe,
  I think your analysis is right, I also encountered the same problem， I have 
filed a bug[1] and commit a patch [2] for this bug.


thanks,
  hanzhang shi


[1] https://launchpad.net/bugs/1469615
[2] https://review.openstack.org/#/c/196927/



在 2015-07-01 08:25:48，"Shraddha Pandhe"  写道：

Hi folks..


I have a question about neutron dhcp agent restart scenario. It seems like, 
when the agent restarts, it recovers the known network IDs in cache, but we 
don't recover the known ports [1].


So if a port that was present before agent restarted, is deleted after agent 
restart, the agent wont have it in its cache. So port here [2] will be None. So 
the port will actually never get deleted. 


Same problem will happen if a port is updated. Has anyone seen these issues? Am 
I missing something?


[1] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87
[2] 
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349

__
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] [cinder] Huawei CI's problem have been solved, and is reporting stably now.

[liuxinguo]

Hi Mike,

We have solved the problem of Huawei CI, and it is running and reporting stably 
now. The logs is also ok to access.

Following are the very recently patchs it have been posted to:

https://review.openstack​.org/180873
https://review.openstack​.org/186312
https://review.openstack​.org/193954
https://review.openstack​.org/195027
https://review.openstack​.org/163641
https://review.openstack​.org/196818
https://review.openstack​.org/177054
https://review.openstack​.org/184404
https://review.openstack​.org/196888
https://review.openstack​.org/193937
https://review.openstack​.org/195795
https://review.openstack​.org/193003
https://review.openstack​.org/188328
https://review.openstack​.org/194549
https://review.openstack​.org/188240
https://review.openstack​.org/196966
https://review.openstack​.org/194524
https://review.openstack​.org/196979
https://review.openstack​.org/163641
https://review.openstack​.org/195027
https://review.openstack​.org/193124
https://review.openstack​.org/194532
https://review.openstack​.org/180873
https://review.openstack​.org/139071
https://review.openstack​.org/156939
https://review.openstack​.org/196071
https://review.openstack​.org/197049
https://review.openstack​.org/197065

We will be very appreciate if you can have a consider of remove the -2 review 
to Huawei driver, thanks! ☺
The following patchs of Huawei driver is still marked as “CI failure”:
https://review.openstack.org/#/c/188240/
https://review.openstack.org/#/c/188732/
https://review.openstack.org/#/c/188365/
https://review.openstack.org/#/c/188360/
https://review.openstack.org/#/c/188251/

Thanks,
Liu

__
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] [all][packaging] Adding files to /etc in a package

[Tony Breeds]

On Wed, Jul 01, 2015 at 03:55:53AM +0200, Thomas Goirand wrote:

> Please don't do this. This is the kind of job to be done by package
> maintainers in distribution, because mostly, Python maintainers wouldn't
> know how to do things correctly. Here we've got a good example: the bash
> completion scripts are now to be installed in
> /usr/share/bash-completion/completions and not in /etc.
> 
> As for the general project config files, I often install them in
> /usr/share/-common, and then copy the file in /etc/ in
> a postinst, so that the file isn't marked as CONFFILE.
> 
> So please don't attempt to do the work of distributions. We then end up
> with config files in /usr/etc (as per what happen with Neutron
> packages), and it's a mess to un-cruft.

Okay so I take you point no problem, but I'm not running distro packages and I
still want completions.  There must be a way to package the file to at least
make it easier to achieve both our goals.

Right now I have to manually wget the file from git.o.o which isn't really okay
IMO.

Could the python package make /usr/share/doc/python-novaclient/tools and ship
it there.  That would mean that distribution packaging could just take that file
and install it in the correct and usful location AND I could just symlink it
and we both win.

Yours Tony.


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

Re: [openstack-dev] [all][packaging] Adding files to /etc in a package

[Thomas Goirand]

On 07/01/2015 03:26 AM, Tony Breeds wrote:
> Hi All,
> I'm pretty new to this but I'll ask anyway.  python-novaclient contains a
> bash completion script .  When installed from pypi this script isn't packaged
> (and therefore it isn't installed).
> 
> I created https://review.openstack.org/#/c/196919/ to gather feedback on:
> a) this this a thing we can/should do ;
> b) How do we (in the package) handle the case where /etc/bash_completion.d 
> dosn't exist
> 
> I'm using python-novaclient here but I suspect this applies to all the
> python0*client repos.
> 
> Yours Tony.

Hi,

Please don't do this. This is the kind of job to be done by package
maintainers in distribution, because mostly, Python maintainers wouldn't
know how to do things correctly. Here we've got a good example: the bash
completion scripts are now to be installed in
/usr/share/bash-completion/completions and not in /etc.

As for the general project config files, I often install them in
/usr/share/-common, and then copy the file in /etc/ in
a postinst, so that the file isn't marked as CONFFILE.

So please don't attempt to do the work of distributions. We then end up
with config files in /usr/etc (as per what happen with Neutron
packages), and it's a mess to un-cruft.

Cheers,

Thomas Goirand (zigo)


__
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] Python 2.6 failed jobs for SQLA-Migrate

[Thomas Goirand]

Hi,

Mike nicely tried to help me to get sqla-migrate to work with sqlalchemy
1.0.6 which is now in Debian. But there's some failures in Python 2.6:

https://review.openstack.org/#/c/197144/

Do we still care about them? Can we get them removed from -migrate? IMO,
supporting the last SQLA is more important than the old Py 2.6.

Thoughts anyone?

Cheers,

Thomas Goirand (zigo)

__
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] dangerous allowed_address_pairs?

[James Dempsey]

Hi All,

Would someone help me understand some potentially dangerous interactions
between allowed_address_pairs and security groups?  My cloud is Icehouse
at the moment, but the behaviour seems unchanged in master. [1]

Suppose a User wants to build an instance that acts as a router.

User creates an instance named ROUTER with an interface that has an
allowed_address_pair of 0.0.0.0/0. (to bypass the anti-spoofing security
group feature)

By default, ROUTER is in the 'default' security group.

User also creates an instance named WEB.

By default, WEB is in the 'default' security group.

The 'default' security group allows inbound traffic from other hosts(and
associated allowed_address_pairs) in the 'default' security group.

Now, WEB receives all traffic from 0.0.0.0/0 because User didn't realize
that allowed_address_pairs associated with ROUTER would effectively
change all associated security groups to be fully permissive.


Have I missed something?  This seems like exceedingly dangerous
behaviour.  I've already seen two instances of this from my users.

[1]
https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L287

Cheers,
James


-- 
James Dempsey
Senior Cloud Engineer
Catalyst IT Limited
+64 4 803 2264
--

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

[openstack-dev] [all][packaging] Adding files to /etc in a package

[Tony Breeds]

Hi All,
I'm pretty new to this but I'll ask anyway.  python-novaclient contains a
bash completion script .  When installed from pypi this script isn't packaged
(and therefore it isn't installed).

I created https://review.openstack.org/#/c/196919/ to gather feedback on:
a) this this a thing we can/should do ;
b) How do we (in the package) handle the case where /etc/bash_completion.d 
dosn't exist

I'm using python-novaclient here but I suspect this applies to all the
python0*client repos.

Yours Tony.


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

[openstack-dev] [Neutron] Issue with neutron-dhcp-agent not recovering known ports cache after restart

[Shraddha Pandhe]

Hi folks..

I have a question about neutron dhcp agent restart scenario. It seems like,
when the agent restarts, it recovers the known network IDs in cache, but we
don't recover the known ports [1].

So if a port that was present before agent restarted, is deleted after
agent restart, the agent wont have it in its cache. So port here [2] will
be None. So the port will actually never get deleted.

Same problem will happen if a port is updated. Has anyone seen these
issues? Am I missing something?

[1]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L82-L87
[2]
https://github.com/openstack/neutron/blob/master/neutron/agent/dhcp/agent.py#L349
__
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] [kolla][release] Announcing Liberty-1 release of Kolla

[Ian Cordasco]

On 6/30/15, 18:36, "Daniel Comnea"  wrote:

>Ian,
>
>
>a while ago it was discussed on operator's mailing list between Kevin,
>Steve & co
>
>http://lists.openstack.org/pipermail/openstack-operators/2015-June/007267.
>html
>

Thanks for that pointer Daniel, I missed that.

>
>On Tue, Jun 30, 2015 at 8:28 PM, Ian Cordasco
> wrote:
>
>
>
>On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>
>>The Kolla community
>>is pleased to announce the
>> release of the
>> Kolla Liberty 1 milestone.  This release fixes 56 bugs
>> and implements 14 blueprints!
>>
>>
>>Our community developed the following notable features:
>>
>>
>>
>>* A start at
>>source-basedcontainers
>
>So how does this now compare to the stackforge/os-ansible-deployment (soon
>to be openstack/openstack-ansible) project?
>
>__
>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] [nova][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends

[Mike Perez]

On 12:24 Jun 26, Matt Riedemann wrote:
 
> So the question is, is everyone OK with this and ready to make that change?

Thanks for all your work on this Matt.

I'm fine with this. I say bite the bullet and we'll see the CI's surface that
aren't skipping or failing this test.

I will communicate with CI maintainers on the CI list about failures as I've
been doing, and reference this thread and the meeting discussion.

-- 
Mike Perez

__
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] [kolla][release] Announcing Liberty-1 release of Kolla

[Daniel Comnea]

Ian,

a while ago it was discussed on operator's mailing list between Kevin,
Steve & co

http://lists.openstack.org/pipermail/openstack-operators/2015-June/007267.html



On Tue, Jun 30, 2015 at 8:28 PM, Ian Cordasco 
wrote:

>
>
> On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:
>
> >The Kolla community
> >is pleased to announce the
> > release of the
> > Kolla Liberty 1 milestone.  This release fixes 56 bugs
> > and implements 14 blueprints!
> >
> >
> >Our community developed the following notable features:
> >
> >
> >
> >* A start at
> >source-basedcontainers
>
> So how does this now compare to the stackforge/os-ansible-deployment (soon
> to be openstack/openstack-ansible) project?
>
> __
> 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] [puppet][ceph] puppet-ceph CI status

[David Moreau Simard]

I merged the https://review.openstack.org/#/c/197302/ as we had agreed that 
once we had enough +1's on the EL7 review we would merge it.

The Puppet4 spec tests had already been approved.

--
David Moreau Simard
Cloud Engineering | Operations

On 2015-06-30 07:06 PM, Andrew Woodward wrote:


On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi 
mailto:emil...@redhat.com>> wrote:


On 06/29/2015 11:16 PM, Matt Fischer wrote:
> Ah, I don't have +2 on that repo, but the lgtm so your original plan is
> fine.
>
> On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer 
> <m...@mattfischer.com
> >> wrote:
>
> I can take a look at these tonight. Maybe also Clayton can review
> them? Neither of us were involved in the patches to my knowledge.
>
> On Jun 29, 2015 5:09 PM, "Andrew Woodward" 
> <xar...@gmail.com
> >> wrote:
>
> Hi
>
> Recent changes in the puppet modules infra left
> stackforge/puppet-ceph CI broken. We've resolved the issues in
> [1][2] However we are short on non-involved core-reviewers.

You'll have to sqash the commits because our CI is voting for puppet4 &
beaker.
Thanks

David squished it up into [3]. The same message applies I'm going to use lazy 
census here and if we don't have any negative feed back we should just merge it 
so we get CI back to passing

[3] https://review.openstack.org/#/c/197302/


If this module does not fit for you, you can still patch project-config,
otherwise you'll need to fix everything in one single commit.

> I propose that we leave the patchs open through Wednesday and
> use lazy consensus and merge it if we don't receive any negative
> feedback.
>
> [1] https://review.openstack.org/#/c/179645/
> [2] https://review.openstack.org/#/c/195959/
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
>
> 
> __
> 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
>

--
Emilien Macchi

__
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
--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community

__
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] Friday 1900UTC etherpad.openstack.org downtime for DB maintenance

[Clark Boylan]

Hello,

The Infra team will be taking etherpad.openstack.org offline this Friday
(July 3rd) at 1900UTC to upgrade the database instance that backs this
service. This upgrade will allow us to convert the utf8 character set in
the db to one supporting 4 byte characters fixing a major bug discovered
during the last summit. Expect total downtime to be about half an hour.

Thank you for your patience and as always let us know if you have
questions/concerns.

Clark

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

Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

[Andrew Woodward]

On Tue, Jun 30, 2015 at 6:28 AM Emilien Macchi  wrote:

>
>
> On 06/29/2015 11:16 PM, Matt Fischer wrote:
> > Ah, I don't have +2 on that repo, but the lgtm so your original plan is
> > fine.
> >
> > On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer  > > wrote:
> >
> > I can take a look at these tonight. Maybe also Clayton can review
> > them? Neither of us were involved in the patches to my knowledge.
> >
> > On Jun 29, 2015 5:09 PM, "Andrew Woodward"  > > wrote:
> >
> > Hi
> >
> > Recent changes in the puppet modules infra left
> > stackforge/puppet-ceph CI broken. We've resolved the issues in
> > [1][2] However we are short on non-involved core-reviewers.
>
> You'll have to sqash the commits because our CI is voting for puppet4 &
> beaker.
>
Thanks

David squished it up into [3]. The same message applies I'm going to use
lazy census here and if we don't have any negative feed back we should just
merge it so we get CI back to passing

[3] https://review.openstack.org/#/c/197302/


>
> If this module does not fit for you, you can still patch project-config,
> otherwise you'll need to fix everything in one single commit.
>
> > I propose that we leave the patchs open through Wednesday and
> > use lazy consensus and merge it if we don't receive any negative
> > feedback.
> >
> > [1] https://review.openstack.org/#/c/179645/
> > [2] https://review.openstack.org/#/c/195959/
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://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
> >
>
> --
> Emilien Macchi
>
> __
> 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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
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] [Mistral][Murano] What's the latest/greatest on YAQL?

[Thomas Goirand]

On 06/30/2015 07:09 AM, Dmitri Zimine wrote:
> Thanks Stan, 
> 
> This release is few more months. How soon?  Are you planning to support
> 0.2 in the meantime?
> 
> We are really pressed on this transition to 1.0. 
> For instance. Number 1 user error while dealing with YAQL is using ==
> instead of =. 
> We had this discussion and you and Alex and you suggested it’s easy to
> redefine. 
> 
> But… … The short is we need to move to 1.0 to do it. Because from what I
> figured so far, in 0.2 I can’t naively extend the an operator, as it
> won’t parse. I did make it work on 0.2 but this required a hack in the
> YAQL library itself, need to add ‘==‘ to both lexer.py and parser.py. At
> least what I figured. 
> 
> I see the tokens are already generalized in 1.0. It doesn’t seem to
> worth backporting it to 0.2, but if this is a way, let us know.
> 
> Mistral is betting on YAQL, please help.
> 
> DZ. 

FYI, I'm also looking forward switching to Yaql 1.0 on the packaging
level, because 0.2.6 has lost support for Py3 (I added some Py3 patches
in Debian for 0.2.4, but 0.2.6 completely broke that...).

Cheers,

Thomas Goirand (zigo)


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

Re: [openstack-dev] [devstack] Use devstack/master to install older releases

[Dean Troyer]

On Tue, Jun 30, 2015 at 7:04 AM, Emmanuel Cazenave  wrote:

> My first approach was to use devstack/icehouse to install swift/icehouse,
> devstack/juno for swift/juno, etc
>

This is the only approach that is sane...


> I am now trying to use devstack/master in every cases because I need this
> : https://review.openstack.org/#/c/115307/ which allow not to install
> nova+glance which I don't need at all, and whose installation takes a
> really long time.
>

We would probably consider a backport of that to DevStack Juno, but
Icehouse is effectively EOL and we will be removing that branch soon (days
or weeks, not months).


> Is my use case of installing older releases with devstack/master not
> supported ?
>

No.  Even on master you may have issues trying to run a early cycle project
with a late-cycle DevStack.  DevStack evolves to meet the needs of the
projects as they develop.

That Tempest fix is pretty straightforward, with only the one code block
move not being a "skip this if project is not enabled" check.  With
Icehouse EOL, there will be no additional updates so maintaining that
backport in a local private branch should not be a big deal.  You will need
that anyway to keep using icehouse after we remove that branch from the
DevStack repo.

dt

-- 

Dean Troyer
dtro...@gmail.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-dev] [nova][scheduler] New Scheduler Meeting Time

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So the poll results are in, and it looks like we have a winner:
Mondays at 1400 UTC. It seems that the #openstack-meeting-alt channel
is the only one available, so we'll use that.

Don Duggar will be updating the wiki and other official resources to
reflect this, but I wanted to send something out now so that you can
update your calendars. See you Monday!

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJVkxEkAAoJEKMgtcocwZqLGAcP/3HQqJ8zlEjtlLL0yac6+zK/
05F6puIXuQzpdGV1AZHXKtNqcjdm7a3m4YMgiozaLG7Svoi7dCbWbflapu5XSkDV
BHGDUkOM/yLnO1pVnmWGN4c5qdv2o/UxLwlLNmFOCgtoee7J9Gh0wZecUvIM107p
ddWqNiQqdn8Nl47X+/L+NdOp9TjjGzgB2cJrjiyHUc8GIq+pm7j/5gCg7Q7RCWvq
6EZzebrMOP6BrVHBMyjnrv7J+9oPMqHtsUonCmBloAQ6frZ/kse3Kxl/DGp8IHMI
DxJkl3bROv8heiiRsHwN7Po75Cv3ImAj0O86dER4ACGTkoWUfQZOTXWVnkPc/xxb
AeTNFX3KgkOUEJ7XHzqEeHu3VmYqZ7exj2LZCLwI7W5PfhpzD8KbC68HTne9mNla
RXYCW0RDcS80p1q9xxSfmJZl88HONrbaoXb3xcGaROhEQFhjQEiNo1cvheR/X9B8
hx5I7zNMErBSnMxRdyA5Vu0mXUC9cyUdYaXCxdoNw4RC7ZAt/u3NxNaovjUMDGv0
Vum/AgozxRlrBmRzIJRE3oegtp+bVkYJ6nDg1PVUrCQ8KKQenFWEErwQeKbK++8J
81chRjsXwrl7fnM4F7nIbGbVzOUD3Bida33DOa6pkOoxHkz2vDHNGhqs5ZfyS44R
zTKrXMHrU5XHHOockryS
=OjA3
-END PGP SIGNATURE-

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

[openstack-dev] [os-ansible-deployment] new features needing reviewers

[Kevin Carter]

Hello all, 

The os-ansible-deployment/OpenStack-Ansible project is gearing up for a couple 
feature drops and looking for reviews from interested people within the greater 
deployer/operator/dev community to ensure that we're developing the 
features/support people are looking for.


Ceilometer:
  This review[0] completes the ceilometer blueprint[1] which adds support for 
ceilometer throughout the stack. While the change doesn't bring with it a 
salable mongodb deployment the solution does add ceilometer to OSAD as a first 
class capability and is tested using mongodb via our gate scripts. That said, 
if anyone knows of or has an Ansible solution for deploying, managing, and 
scaling mongodb we'd love to review, contribute, and pull it in as an external 
dependency when deploying Ceilometer with OSAD.


Ceph:
  This review[2] adds ceph support for the various OpenStack service that can 
consume ceph. This is not a way to deploy a ceph infrastructure using Ansible, 
for that we're still recommending the upstream ceph playbooks/roles[3]. 
Additionally, this is not implementing ceph as a replacement to swift.


These reviews are presently targeted at "master" which is gating on upstream 
liberty but we're intending to bring these changes into our kilo branch, which 
is tracking upstream kilo, to be released with the 11.1.0 tag and is scheduled 
to drop in the next few weeks[4]. We have lots of new goodness coming for 
11.1.0 but these two features are largish so we'd appreciate some additional 
feedback/reviews. If you have some time and are interested in the OSAD project, 
we'd love to hear from you.


--

Kevin Carter

[0] https://review.openstack.org/#/c/173067/
[1] 
https://github.com/stackforge/os-ansible-deployment-specs/blob/master/specs/kilo/implement-ceilometer.rst
[2] https://review.openstack.org/#/c/181957/
[3] https://github.com/ceph/ceph-ansible
[4] https://launchpad.net/openstack-ansible/+milestone/11.1.0
__
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] Out Of Office

[wo]

I am currently travelling and am out of the office until Thursday the 9th July, 
I will be picking up emails periodically.


__
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] [cinder][stable] Cinder client broken in Juno

[Duncan Thomas]

Sorry, I don't think I was entirely clear with my proposal - I meant that
we release a new current that will default to the old behavior, but allow
the new behavior to be tested by explicitly choosing the value 'auto'. This
allows people to test their config with version discovery, without breaking
normal usage.
On 30 Jun 2015 19:28, "John Griffith"  wrote:

>
>
> On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas 
> wrote:
>
>> We already have an environment variable for version... 'auto'?
>> On 30 Jun 2015 07:57, "John Griffith"  wrote:
>>
>>>
>>>
>>> On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant <
>>> jsbry...@electronicjungle.net> wrote:
>>>
 I too would prefer option 2. Would rather do the pack ports than remove
 the functionality.

 Jay

 On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor 
 wrote:

> On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote:
> > There was a bug raised [1] from some large deployments that the
> Cinder
> > client 1.2.0 and beyond is not working because of version discovery.
> > Unfortunately it's not taking into account of deployments that have a
> > proxy.
>
> A little bit unrelated, but volume pagination in Cinder client is also
> broken due to Version Discovery:
> https://bugs.launchpad.net/python-cinderclient/+bug/1453755
>
> >
> > Cinder client asks Keystone to find a publicURL based on a version.
> > Keystone will gather data from the service catalog and ask Cinder for
> > a list of the public endpoints and compare. For the proxy cases,
> > Cinder is giving internal URLs back to the proxy and Keystone ends up
> > using that instead of the publicURL in the service catalog. As a
> > result, clients usually won't be able to use the internal URL and
> > rightfully so.
> >
> > This is all correctly setup on the deployer's side, this an issue
> with
> > the server side code of Cinder.
> >
> > There is a patch that allows the deployer to specify a configuration
> > option public_endpoint [2] which was introduced in a patch in Kilo
> > [3]. The problem though is we can't expect people to already be
> > running Kilo to take advantage of this, and it leaves deployers
> > running stable releases of Juno in the dark with clients upgrading
> and
> > using the latest.
> >
> > Two options:
> >
> > 1) Revert version discovery which was introduced in Kilo for Cinder
> client.
> >
> > 2) Grant exception on backporting [4] a patch that helps with this
> > problem, and introduces a config option that does not change default
> > behavior. I'm also not sure if this should be considered for
> Icehouse.
>
> +1 to option 2 and I wouldn't be totally against considering it for
> Icehouse.
>
> Cheers,
> Gorka.
> >
> >
> > [1] - https://launchpad.net/bugs/1464160
> > [2] -
> http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html
> > [3] - https://review.openstack.org/#/c/159374/
> > [4] - https://review.openstack.org/#/c/194719/
> >
> > --
> > Mike Perez
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

 ​I'll echo Jeremy and Dave's statements regarding compatibility, seems
>>> really pretty lame that this can't work.  If it's not possible to support
>>> both scenarios in the client in a reasonable manner without long timeout
>>> periods my vote is for a revert and new client version. Sorry, but in my
>>> opinion backports to Cinder itself don't cut it in this case.  It's
>>> unfortunate we got to this point.
>>>
>>> Why can't we make this a config option in cinderclient itself?  Like
>>> "USE_AUTO_DISCOVERY=True|False" with a default of False in the client and
>>> just deal with it or as others have asked can't we make all of this
>>> "smarter"?  I mean it's sort of odd to have a discovery option that only
>>> works with 'new' versions of the API doesn't it?
>>>
>>>
>>>
>>> 

Re: [openstack-dev] [kolla][release] Announcing Liberty-1 release of Kolla

[Ian Cordasco]

On 6/29/15, 23:59, "Steven Dake (stdake)"  wrote:

>The Kolla community
>is pleased to announce the
> release of the
> Kolla Liberty 1 milestone.  This release fixes 56 bugs
> and implements 14 blueprints!
>
>
>Our community developed the following notable features:
>
>
>
>* A start at
>source-basedcontainers

So how does this now compare to the stackforge/os-ansible-deployment (soon
to be openstack/openstack-ansible) project?

__
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] Aodh has been imported, next steps

[Ildikó Váncsa]

Hmm, as it is a change that affects the user, in my opinion it is still an API 
change.

Have we decided about the client, whether the alarming module will have a 
separate client or we will keep the current ceilometer-client? I guess more the 
latter one at least as a starting point, I just wanted to double check.

Ildikó 

Sent from my iPad

> On 30 Jun 2015, at 14:18, Julien Danjou  wrote:
> 
>> On Tue, Jun 30 2015, Ildikó Váncsa wrote:
>> 
>> Will this be accessible in the same way as currently or it needs
>> changes on client side?
> 
> You may just need to pass more options to the client to force another
> endpoint to be used when talking to the alarming part.
> We could make this change in the client by default though.
> 
> -- 
> Julien Danjou
> # Free Software hacker
> # http://julien.danjou.info

__
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] [nova] schedule instance based on CPU frequency ?

[Jay Pipes]

On 06/30/2015 02:42 AM, ChangBo Guo wrote:

CPU frequency  is an import performance parameter,  currently  nova
drivers just  report cpu_info without frequency.   we stored the compute
node cpu_info in database with colum compute_nodes.cpu_info,  we can add
the frequency  easily.

The usage of  cpu frequency  I  can think is used to schedule to meet
applications which need high frequency.  add a frequency based filter ?
if we need this , I would like to propose  a spec for this .


There are two steps to leverage cpu frequency:
1.  report cpu frequency  and record the value,  nova hypervisor-show
will include the value .

2.  filter compute nodes based  cpu frequency.
 add a new scheduler filter to do that

before I start to do these stuff.  I would like to your  input .

Do we need leverage CPU frequency  in Nova ?
if yes, do we need a new filter  or  leverage existing filter to use
frequency ?


Like Dan B, I question whether CPU frequency really is a useful metric 
for scheduling decisions.


That said, it is already possible to use CPU frequency in the 
MetricsWeigher scheduler weigher. The compute monitor plugin system is 
currently being overhauled [1], but the functionality to monitor 
CPU-related metrics already exists in Nova and can be enabled by doing 
the following in your nova-compute nova.conf:


compute_monitors = ComputeDriverCPUMonitor

Note that with the refactoring of the monitoring plugin interface, the 
above option will change due to using stevedore to load monitor extensions:


compute_monitors = nova.compute.monitors.cpu.virt_driver:Monitor

In your Nova scheduler nova.conf, you will need to add the following in 
the [metrics] section of the file:


weights_setting = cpu.frequency=10.0

Again, I'm not saying that the above will result in any appreciable 
enhancement to the scheduler's decision-making, but it will do what 
you're trying to accomplish :)


Best,
-jay

[1] 
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1468012,n,z


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

Re: [openstack-dev] [TripleO][Heat] Tuskar v. Heat responsibilities

[Steven Hardy]

On Mon, Jun 29, 2015 at 04:42:00PM -0400, Jay Dobies wrote:
> >I had originally been thinking of it like slagle describes, from the
> >child up to the parent as well. What I like about that approach is that
> >it achieves a more pluggable model when you think about extensions that
> >aren't accepted or applicable in TripleO upstream.
> >
> >If someone comes along and adds a new ControllerConfig to your above
> >example, they have to edit whatever environment you're talking about
> >that defines the constraints (I'm call it overcloud-something.yaml for
> >now).
> >
> >This becomes a problem from a packaging point of view, especially when
> >you factor in non-TripleO integrators (without revealing too much inside
> >baseball, think partner integrations). How do I add in an extra package
> >(RPM, DEB, whatever) that provides that ControllerConfig and have it
> >picked up as a valid option?
> >
> >We don't want to be editing the overcloud-something.yaml because it's
> >owned by another package and there's the potential for conflicts if
> >multiple extra implementations start stepping on each other.
> >
> >An interface/discovery sort of mechanism, which I agree is more complex,
> >would be easier to work with in those cases.
> 
> I'm effectively replying to my own e-mail here, but I've expressed these
> thoughts on the spec and it'd probably be better to continue this train of
> thought there:
> 
> https://review.openstack.org/#/c/196656/

Thanks for all the great feedback!

So, based on your (and others) feedback, I've revised it to more of a
discovery based model, where we add an optional new annotation to HOT:

 resource_type_mapping:
   resource_type: OS::TripleO::Controller

This is analogous to the "subsitution_mappings" section defined in TOSCA,
but renamed to make it a bit more HOT-ish:

This would then be discoverable via heatclient, e.g:

heat resource-find-template OS::TripleO::Controller

which might return:

puppet/controller.yaml
docker/controller.yaml
...

And heat would enforce type->mapping when validating the resource_registry.

We could make heatclient support discovering via local filesystem, URL and
Swift bucket (it already supports getting templates via all these).

I've also taken a first-pass at the recursive validation spec discussed in
my other thread:

https://review.openstack.org/#/c/197199/

Thanks for the help defining this so far, any further feedback or ideas
much appreciated! :)

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

[openstack-dev] Out Of Office

[wo]

I am currently travelling and am out of the office until Thursday the 9th July, 
I will be picking up emails periodically.


__
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] Why doesn't Gerrit email me?

[Neil Jerram]

On 30/06/15 16:14, Jeremy Stanley wrote:

On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote:
[...]

I keep going back to Gerrit jobs that I've reviewed or commented
on, and finding that there have been other comments since mine,
but that Gerrit didn't email me about.

[...]

Looking in our MTA logs for review.openstack.org, I see lots of "550
5.7.1 Message rejected due to content restrictions" errors for your
address and other addresses at your domain. I recommend having your
mailserver administrators review their logs for additional detail.


Thanks very much, Jeremy, that's really useful information.  Hopefully 
with this I can get the problem fixed at my end.


Regards,
Neil


__
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] [os-ansible-deployment] Feedback on Keystone Federation Spec

[Steve Martinelli]

I've already looked at some of the work, and intend to look at all of it
more closely. But I wanted to publicly thank you and the rest of the folks
that made this possible (sigmavirus24, dolphm, lbragstad, ken johnston, i'm
sure i'm missing others). This is a huge plus for user experience, and will
make consumer the federation capabilities of Keystone much easier.

Thanks,

Steve Martinelli
OpenStack Keystone Core

Jesse Pretorius  wrote on 2015/06/30 12:21:51
PM:

> From: Jesse Pretorius 
> To: openstack-dev@lists.openstack.org,
openstack-operat...@lists.openstack.org
> Date: 2015/06/30 12:22 PM
> Subject: [openstack-dev] [os-ansible-deployment] Feedback on
> Keystone Federation Spec
>
> Hi everyone,
>
> There was quite a bit of fanfare around the new federation features
> in OpenStack Kilo.
>
> In the os-ansible-deployment/openstack-ansible project we've been
> putting together a view on how to implement federation with as
> little complexity as possible.
>
> We've been working on some prototype code which can be seen by
> looking at the patches on the blueprint whiteboard [1] and have also
> prepared a spec for the implementation [2].
>
> We'd like to get some feedback from the broader community - from
> deployers interested in using the feature and from developers/
> deployers who've worked with federation. The feedback we'd like to
> see is both in terms of the spec and the prototype code (which is
> changing quite frequently as we figure out the bits and pieces).
>
> The follow-on to this work will be to specifically add the
> capability to make use of an ADFS IdP for a Keystone SP. This work
> will be linked to another blueprint [3] which is still a work in
progress.
>
> I look forward to the review feedback!
>
> [1] https://blueprints.launchpad.net/openstack-ansible/+spec/
> keystone-federation
> [2] https://review.openstack.org/194147
> [3] https://blueprints.launchpad.net/openstack-ansible/+spec/
> keystone-sp-adfs-idp
>
> --
> Jesse Pretorius
> IRC: odyssey4me
>
__
> 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] [cinder][stable] Cinder client broken in Juno

[John Griffith]

On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas 
wrote:

> We already have an environment variable for version... 'auto'?
> On 30 Jun 2015 07:57, "John Griffith"  wrote:
>
>>
>>
>> On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant <
>> jsbry...@electronicjungle.net> wrote:
>>
>>> I too would prefer option 2. Would rather do the pack ports than remove
>>> the functionality.
>>>
>>> Jay
>>>
>>> On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor 
>>> wrote:
>>>
 On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote:
 > There was a bug raised [1] from some large deployments that the Cinder
 > client 1.2.0 and beyond is not working because of version discovery.
 > Unfortunately it's not taking into account of deployments that have a
 > proxy.

 A little bit unrelated, but volume pagination in Cinder client is also
 broken due to Version Discovery:
 https://bugs.launchpad.net/python-cinderclient/+bug/1453755

 >
 > Cinder client asks Keystone to find a publicURL based on a version.
 > Keystone will gather data from the service catalog and ask Cinder for
 > a list of the public endpoints and compare. For the proxy cases,
 > Cinder is giving internal URLs back to the proxy and Keystone ends up
 > using that instead of the publicURL in the service catalog. As a
 > result, clients usually won't be able to use the internal URL and
 > rightfully so.
 >
 > This is all correctly setup on the deployer's side, this an issue with
 > the server side code of Cinder.
 >
 > There is a patch that allows the deployer to specify a configuration
 > option public_endpoint [2] which was introduced in a patch in Kilo
 > [3]. The problem though is we can't expect people to already be
 > running Kilo to take advantage of this, and it leaves deployers
 > running stable releases of Juno in the dark with clients upgrading and
 > using the latest.
 >
 > Two options:
 >
 > 1) Revert version discovery which was introduced in Kilo for Cinder
 client.
 >
 > 2) Grant exception on backporting [4] a patch that helps with this
 > problem, and introduces a config option that does not change default
 > behavior. I'm also not sure if this should be considered for Icehouse.

 +1 to option 2 and I wouldn't be totally against considering it for
 Icehouse.

 Cheers,
 Gorka.
 >
 >
 > [1] - https://launchpad.net/bugs/1464160
 > [2] -
 http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html
 > [3] - https://review.openstack.org/#/c/159374/
 > [4] - https://review.openstack.org/#/c/194719/
 >
 > --
 > Mike Perez
 >
 >
 __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> ​I'll echo Jeremy and Dave's statements regarding compatibility, seems
>> really pretty lame that this can't work.  If it's not possible to support
>> both scenarios in the client in a reasonable manner without long timeout
>> periods my vote is for a revert and new client version. Sorry, but in my
>> opinion backports to Cinder itself don't cut it in this case.  It's
>> unfortunate we got to this point.
>>
>> Why can't we make this a config option in cinderclient itself?  Like
>> "USE_AUTO_DISCOVERY=True|False" with a default of False in the client and
>> just deal with it or as others have asked can't we make all of this
>> "smarter"?  I mean it's sort of odd to have a discovery option that only
>> works with 'new' versions of the API doesn't it?
>>
>>
>> __
>> 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.

[openstack-dev] [os-ansible-deployment] Feedback on Keystone Federation Spec

[Jesse Pretorius]

Hi everyone,

There was quite a bit of fanfare around the new federation features in
OpenStack Kilo.

In the os-ansible-deployment/openstack-ansible project we've been putting
together a view on how to implement federation with as little complexity as
possible.

We've been working on some prototype code which can be seen by looking at
the patches on the blueprint whiteboard [1] and have also prepared a spec
for the implementation [2].

We'd like to get some feedback from the broader community - from deployers
interested in using the feature and from developers/deployers who've worked
with federation. The feedback we'd like to see is both in terms of the spec
and the prototype code (which is changing quite frequently as we figure out
the bits and pieces).

The follow-on to this work will be to specifically add the capability to
make use of an ADFS IdP for a Keystone SP. This work will be linked to
another blueprint [3] which is still a work in progress.

I look forward to the review feedback!

[1]
https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-federation
[2] https://review.openstack.org/194147
[3]
https://blueprints.launchpad.net/openstack-ansible/+spec/keystone-sp-adfs-idp

-- 
Jesse Pretorius
IRC: odyssey4me
__
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] [designate] and [lbaas] - GSLB API and backend support

[Hayes, Graham]

I have started to put together a working draft of an API here:

https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing

I would suggest we skip this weeks meeting, and review this doc, and 
circle back next week?

I have opened it for comment, and I will add anyone who sends on their 
email to the editors list.

Thanks,

Graham

On 24/06/15 15:16, Samuel Bercovici wrote:
> Great!
>
> Thanks you. I have missed this one.
>
> *From:*Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
> *Sent:* Wednesday, June 24, 2015 12:21 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
> backend support
>
> Hi Sam
>
> Yes. we discussed the use cases 2 weeks ago on irc. The IRC logs can be
> found here
> http://eavesdrop.openstack.org/meetings/gslb/2015/gslb.2015-06-09-16.00.log.html
>
> and the use case document can be found here
> https://docs.google.com/document/d/1016shVnPaK8l8HxMpjADiYtY2O94p4g7JxjuIA-qv7w/edit?usp=sharing
>
> Regards
>
> Kunal
>
> On Jun 24, 2015, at 12:35 AM, Samuel Bercovici  > wrote:
>
> Hi Kunal,
>
> Did you also include use cases per our last discussion on IRC?
> I prefer to start with use cases before we dive into APIs.
>
> Thanks,
> -Sam.
>
>
> -Original Message-
> From: Gandhi, Kunal [mailto:kunalhgan...@gmail.com]
> Sent: Wednesday, June 24, 2015 6:47 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
> backend support
>
> Hi All,
>
> I have a very draft for the GSLB API and would like to upload it
> somewhere for discussion. What is the best place to upload and
> collaborate the draft ? Since the API docs have a lot of JSON
> payloads in it, I am not sure whether Google Docs will be
> appropriate for that.
>
> Regards
> Kunal
>
>
> On Jun 15, 2015, at 10:03 PM, Doug Wiegley
> mailto:doug...@parksidesoftware.com>>
> wrote:
>
> Hi all,
>
> We don’t have a rough draft API doc yet, so I’m suggesting that we
> postpone tomorrow morning’s meeting until next week. Does anyone
> have any other agenda items, or want the meeting tomorrow?
>
> Thanks,
> doug
>
>
>
> On Jun 2, 2015, at 10:52 AM, Doug Wiegley
> mailto:doug...@parksidesoftware.com>>
> wrote:
>
> Hi all,
>
> The initial meeting logs can be found at
> http://eavesdrop.openstack.org/meetings/gslb/2015/ , and we will be
> having another meeting next week, same time, same channel.
>
> Thanks,
> doug
>
>
>
> On May 31, 2015, at 1:27 AM, Samuel Bercovici  > wrote:
>
> Good for me - Tuesday at 1600UTC
>
>
> -Original Message-
> From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
> Sent: Thursday, May 28, 2015 10:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API and
> backend support
>
>
>
> On May 28, 2015, at 12:47 PM, Hayes, Graham  > wrote:
>
> On 28/05/15 19:38, Adam Harwell wrote:
>
> I haven't seen any responses from my team yet, but I know we'd be
> interested as well - we have done quite a bit of work on this in
> the past, including dealing with the Designate team on this very
> subject.
> We can be available most hours between 9am-6pm Monday-Friday CST.
>
> --Adam
>
> https://keybase.io/rm_you
>
>
> From: Rakesh Saha   >>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>   
> >>
> Date: Thursday, May 28, 2015 at 12:22 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
>   
> >>
> Subject: Re: [openstack-dev] [designate] and [lbaas] - GSLB API
> and backend support
>
> Hi Kunal,
> I would like to participate as well.
> Mon-Fri morning US Pacific time works for me.
>
> Thanks,
> Rakesh Saha
>
> On Tue, May 26, 2015 at 8:45 PM, Vijay Venkatachalam
>   
> >>
> wrote:
>
> We would like to participate as well.
>
> __ __
>
> Monday-Friday Morning US time works for me..
>
> __ __
>
> Thanks,
>
> Vijay V.
>
> __ __
>
> 

Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

[Fox, Kevin M]

Whats the timeframe? I was really hoping for Liberty but its sounding like 
thats unlikely? M then? The app catalog really needs conditionals for the same 
reason. :/

Thanks,
Kevin

From: Angus Salkeld [asalk...@mirantis.com]
Sent: Monday, June 29, 2015 6:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M 
mailto:kevin@pnnl.gov>> wrote:
Needing to fork templates to tweak things is a very common problem.

Adding conditionals to Heat was discussed at the Summit. 
(https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I want to 
say, someone was going to prototype it using YAQL, but I don't remember who.

I was going to do that, but I would not expect that ready in a very short time 
frame. It needs
some investigation and agreement from others. I'd suggest making you decision 
based
on what we have now.

-Angus


Would it be reasonable to keep if conditionals worked?

Thanks,
Kevin

From: Hongbin Lu [hongbin...@huawei.com]
Sent: Monday, June 29, 2015 3:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

Agree. The motivation of pulling templates out of Magnum tree is hoping these 
templates can be leveraged by a larger community and get more feedback. 
However, it is unlikely to be the case in practise, because different people 
has their own version of templates for addressing different use cases. It is 
proven to be hard to consolidate different templates even if these templates 
share a large amount of duplicated code (recall that we have to copy-and-paste 
the original template to add support for Ironic and CoreOS). So, +1 for 
stopping usage of heat-coe-templates.

Best regards,
Hongbin

-Original Message-
From: Tom Cammann [mailto:tom.camm...@hp.com]
Sent: June-29-15 11:16 AM
To: openstack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates

Hello team,

I've been doing work in Magnum recently to align our templates with the 
"upstream" templates from larsks/heat-kubernetes[1]. I've also been porting 
these changes to the stackforge/heat-coe-templates[2] repo.

I'm currently not convinced that maintaining a separate repo for Magnum 
templates (stackforge/heat-coe-templates) is beneficial for Magnum or the 
community.

Firstly it is very difficult to draw a line on what should be allowed into the 
heat-coe-templates. We are currently taking out changes[3] that introduced 
"useful" autoscaling capabilities in the templates but that didn't fit the 
Magnum plan. If we are going to treat the heat-coe-templates in that way then 
this extra repo will not allow organic development of new and old container 
engine templates that are not tied into Magnum.
Another recent change[4] in development is smart autoscaling of bays which 
introduces parameters that don't make a lot of sense outside of Magnum.

There are also difficult interdependency problems between the templates and the 
Magnum project such as the parameter fields. If a required parameter is added 
into the template the Magnum code must be also updated in the same commit to 
avoid functional test failures. This can be avoided using "Depends-On:
#xx"
feature of gerrit, but it is an additional overhead and will require some CI 
setup.

Additionally we would have to version the templates, which I assume would be 
necessary to allow for packaging. This brings with it is own problems.

As far as I am aware there are no other people using the heat-coe-templates 
beyond the Magnum team, if we want independent growth of this repo it will need 
to be adopted by other people rather than Magnum commiters.

I don't see the heat templates as a dependency of Magnum, I see them as a truly 
fundamental part of Magnum which is going to be very difficult to cut out and 
make reusable without compromising Magnum's development process.

I would propose to delete/deprecate the usage of heat-coe-templates and 
continue with the usage of the templates in the Magnum repo. How does the team 
feel about that?

If we do continue with the large effort required to try and pull out the 
templates as a dependency then we will need increase the visibility of repo and 
greatly increase the reviews/commits on the repo. We also have a fairly 
significant backlog of work to align the heat-coe-templates with the templates 
in heat-coe-templates.

Thanks,
Tom

[1] https://github.com/larsks/heat-kubernetes
[2] https://github.com/stackforge/heat-coe-templates
[3] https://review.openstack.org/#/c/184687/
[4] https://review.openstack.org/#/c/196505/

__
OpenStack Developm

Re: [openstack-dev] [TripleO] diskimage-builder 1.0.0

[James Slagle]

On Mon, Jun 29, 2015 at 8:44 AM, Gregory Haynes  wrote:
> Hello all,
>
> DIB has come a long way and we seem to have a fairly stable interface
> for the elements and the image creation scripts. As such, I think it's
> about time we commit to a major version release. Hopefully this can give
> our users the (correct) impression that DIB is ready for use by folks
> who want some level of interface stability.
>
> AFAICT our bug list does not have any major issues that might require us
> to break our interface, so I dont see any harm in 'just going for it'.
> If anyone has input on fixes/features we should consider including
> before a 1.0.0 release please speak up now. If there are no objections
> by next week I'd like to try and cut a release then. :)

Sounds good to me. I think the stable interfaces also includes the
elements expected environment variables. It probably makes sense to
document somewhere what the stable interfaces are, so that people
doing releases know how to version the release appropriately based on
any changes to those interfaces.

Should we also remove the deprecated disk-image-get-kernel prior to
the 1.0.0? There's a few other deprecations as well (map-packages),
but I don't think we ever fully moved off of that in dib itself.


>
> Cheers,
> Greg
>
> __
> 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



-- 
-- James Slagle
--

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

[openstack-dev] [Nova] Serial console protocol type setting --

[Liu, Gene]

Hi team,

After I searched around a while and looked into some of the nova source
code I could not still figure out how to manage a feature my project
requires. I would like to post it here for help, suggestions. Appreciate
any inputs!

Problem: In my project, I need VMs on openstack support serial console
with "" instead the default one "". I attached the chunk of the xml as below.


   
 *--> *
   
   


   
 *--> 
*   
   


Thanks,
Gene
__
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] Hyper-V meeting

[Peter Pouliot]

Too many people on vacation this week.   Postponing the meeting until there is 
quorum.
p

Peter J. Pouliot CISSP
Microsoft Enterprise Cloud Solutions
C:\OpenStack
New England Research & Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.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

Re: [openstack-dev] Why doesn't Gerrit email me?

[Jeremy Stanley]

On 2015-06-30 14:25:27 + (+), Dulko, Michal wrote:
> I'm also experiencing some difficulties with Gerrit email
> notifications. Around the time Kilo was released it became
> unreliable. Some notifications are coming after few days, some of
> them instantly. In particular I'm often receiving comments on a
> patch in invalid order.

Yes, I spoke with someone else on IRC last week who has an address
at your domain and was experiencing similar issues with our mailing
lists. There are lots of "452 Too many recipients received this
hour" errors in our review.openstack.org MTA logs for addresses at
that domain. Please follow up with your mailserver administrators to
get this resolved.
-- 
Jeremy Stanley


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

Re: [openstack-dev] Why doesn't Gerrit email me?

[Jeremy Stanley]

On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote:
[...]
> I keep going back to Gerrit jobs that I've reviewed or commented
> on, and finding that there have been other comments since mine,
> but that Gerrit didn't email me about.
[...]

Looking in our MTA logs for review.openstack.org, I see lots of "550
5.7.1 Message rejected due to content restrictions" errors for your
address and other addresses at your domain. I recommend having your
mailserver administrators review their logs for additional detail.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all] OpenStack CI harddisk failure - jobs are UNSTABLE

[Davanum Srinivas]

Thanks a ton fungi!

On Tue, Jun 30, 2015 at 10:55 AM, Jeremy Stanley  wrote:
> On 2015-06-30 10:59:24 +0200 (+0200), Andreas Jaeger wrote:
>> static.openstack.org has a harddisk failure for the log volume
>> which causes jobs to fail with "UNSTABLE" when uploading log files.
> [...]
>
> The log volume was repaired and brought back online at 14:00 UTC.
> Log links today from before that time may be missing, and changes
> should be rechecked if fresh job logs are desired for them.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [all] OpenStack CI harddisk failure - jobs are UNSTABLE

[Jeremy Stanley]

On 2015-06-30 10:59:24 +0200 (+0200), Andreas Jaeger wrote:
> static.openstack.org has a harddisk failure for the log volume
> which causes jobs to fail with "UNSTABLE" when uploading log files.
[...]

The log volume was repaired and brought back online at 14:00 UTC.
Log links today from before that time may be missing, and changes
should be rechecked if fresh job logs are desired for them.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [heat] status of instance_user/admin_user in heat

[Thomas Herve]

 
> Looks like this change is what I need, but was the code supposed to not set
> it to ec2-user when instance_user is unset? I've always had it unset and
> it's always set it to ec2-user, certainly for Ubuntu images anyway, I've
> not tested others.

It's a common misconception. Unset is different from the empty string. If you 
don't set it, it keeps using the default value, which is ec2-user. If you set 
it to the empty string, it keeps whatever the image is using. If you don't that 
you shouldn't need this change.

-- 
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-dev] Why doesn't Gerrit email me?

[Neil Jerram]

Thanks Sean, + Andreas for your similar reply...

Yes, I guess that could be it.  My company's setup is Exchange, and the 
IT folk here assure me that any spam emails would be in my Junk folder - 
and the missing Gerrit emails aren't there.  But, maybe that's not the 
100% full story, for some reason.


Perhaps I should add lots of watched projects as a way of testing my 
local mail server... :-)


But perhaps also worth keeping an open mind about the possibility of 
Gerrit notification having regressed in some way.


Regards,
Neil


On 30/06/15 15:24, Sean McGinnis wrote:

I had issues with our mail server filtering them out as spam or
something. It wasn't even at my client, so I couldn't do much about it.
I eventually ended up using a new mail provider for my OpenStack emails.



At the moment, however, I have nothing configured here - and AFAIK I
never have had - and I _have_ received emails in the past for most of
the Gerrit jobs that I have commented on.  Presumably, therefore,
there is a default email notification behaviour that doesn't require
anything under "Watched Projects".  I wonder why that would mostly
work, but sometimes (apparently) not.

Regards,
Neil


__

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



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


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

Re: [openstack-dev] [heat] status of instance_user/admin_user in heat

[Matt Fischer]

Looks like this change is what I need, but was the code supposed to not set
it to ec2-user when instance_user is unset? I've always had it unset and
it's always set it to ec2-user, certainly for Ubuntu images anyway, I've
not tested others.


On Tue, Jun 30, 2015 at 8:22 AM, Thomas Herve  wrote:

>
> > Heat devs,
> >
> > What is the status of the instance_user config option and the corollary
> > OS::Nova::Server::admin_user field? Our users find it very confusing when
> > Heat creates a VM with a user called ec2-user. While I've told them to
> > explicitly set admin_user, the documentation claims its deprecated since
> > Icehouse. Will it be removed? Along the same lines, instance_user in the
> > config also claims to be deprecated and slated for removal in Kilo, it is
> > also still there in master. So what's the right behavior here? Should I
> > tell heat users that it's safe/recommended to set admin_user or not?
>
> Hi,
>
> It's been deprecated for a while, and will be hidden in the next release
> (see https://review.openstack.org/#/c/103928/) if everything goes well.
>
> As an operator, you shoud set the instance_user configuration value to the
> empty string, so that your users get the default user from the image.
> That's the recommanded mode of operation.
>
> Cheers,
>
> --
> 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
>
__
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] Cross-project meeting today, Tue Jun 30th, 21:00 UTC

[Anne Gentle]

Dear PTLs, cross-project liaisons, and interested team members,

We'll have a cross-project meeting today at 21:00 UTC, with the following
agenda:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda

* Team announcements (horizontal, vertical, diagonal)
* Translation for non user facing messages (yamamoto) [1]
* API WG spec review: Clarifications on state-conflicting requests [2]
* Return request ID to caller (tpatil): Spec review [3]

If you're from an horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, please attend and use
the #info meetbot command to ensure it gets in the meeting summary.

If you're interested in chairing a cross-project meeting, please talk to
Thierry Carrez (ttx).

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

See you there!

Thanks,
Anne

1. https://review.openstack.org/#/c/185300
2. https://review.openstack.org/#/c/180094
3. https://review.openstack.org/#/c/156508
--
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.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

Re: [openstack-dev] Why doesn't Gerrit email me?

[Andreas Jaeger]

On 06/30/2015 03:08 PM, Neil Jerram wrote:

Apologies if this is an FAQ - I tried a quick search, but that didn't
find anything that looked both up to date and authoritative.

I keep going back to Gerrit jobs that I've reviewed or commented on, and
finding that there have been other comments since mine, but that Gerrit
didn't email me about.

Does anyone know why that happens?  It's really important to my
workflow, and to continuing review conversations effectively, that
Gerrit emails new comments reliably and in good time.  Could I be doing
something wrong that is causing this not to happen?


It works fine for me - do they end in some mail filter at your side?

Recently I discussed with somebody who found them all in his junk folder ;(

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Why doesn't Gerrit email me?

[Dulko, Michal]

I'm also experiencing some difficulties with Gerrit email notifications. Around 
the time Kilo was released it became unreliable. Some notifications are coming 
after few days, some of them instantly. In particular I'm often receiving 
comments on a patch in invalid order.

> -Original Message-
> From: Louis Taylor [mailto:lo...@kragniz.eu]
> Sent: Tuesday, June 30, 2015 3:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Why doesn't Gerrit email me?
> 
> On Tue, Jun 30, 2015 at 02:08:45PM +0100, Neil Jerram wrote:
> > Apologies if this is an FAQ - I tried a quick search, but that didn't
> > find anything that looked both up to date and authoritative.
> >
> > I keep going back to Gerrit jobs that I've reviewed or commented on,
> > and finding that there have been other comments since mine, but that
> > Gerrit didn't email me about.
> >
> > Does anyone know why that happens?  It's really important to my
> > workflow, and to continuing review conversations effectively, that
> > Gerrit emails new comments reliably and in good time.  Could I be
> > doing something wrong that is causing this not to happen?
> 
> This is probably a silly question, but have you enabled email notifications 
> for
> all comments in your watched projects? You can create a watch item for a
> particular project with 'owner:me' in the 'Only If' field to prevent a deluge 
> of
> comment notifications.
> 
> Cheers,
> Louis

__
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] Why doesn't Gerrit email me?

[Sean McGinnis]

I had issues with our mail server filtering them out as spam or 
something. It wasn't even at my client, so I couldn't do much about it. 
I eventually ended up using a new mail provider for my OpenStack emails.




At the moment, however, I have nothing configured here - and AFAIK I 
never have had - and I _have_ received emails in the past for most of 
the Gerrit jobs that I have commented on.  Presumably, therefore, 
there is a default email notification behaviour that doesn't require 
anything under "Watched Projects".  I wonder why that would mostly 
work, but sometimes (apparently) not.


Regards,
Neil


__ 


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] [heat] status of instance_user/admin_user in heat

[Thomas Herve]

> Heat devs,
> 
> What is the status of the instance_user config option and the corollary
> OS::Nova::Server::admin_user field? Our users find it very confusing when
> Heat creates a VM with a user called ec2-user. While I've told them to
> explicitly set admin_user, the documentation claims its deprecated since
> Icehouse. Will it be removed? Along the same lines, instance_user in the
> config also claims to be deprecated and slated for removal in Kilo, it is
> also still there in master. So what's the right behavior here? Should I
> tell heat users that it's safe/recommended to set admin_user or not?

Hi,

It's been deprecated for a while, and will be hidden in the next release (see 
https://review.openstack.org/#/c/103928/) if everything goes well.

As an operator, you shoud set the instance_user configuration value to the 
empty string, so that your users get the default user from the image. That's 
the recommanded mode of operation.

Cheers,

-- 
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

[openstack-dev] [heat] status of instance_user/admin_user in heat

[Matt Fischer]

Heat devs,

What is the status of the instance_user config option and the corollary
OS::Nova::Server::admin_user field? Our users find it very confusing when
Heat creates a VM with a user called ec2-user. While I've told them to
explicitly set admin_user, the documentation claims its deprecated since
Icehouse. Will it be removed? Along the same lines, instance_user in the
config also claims to be deprecated and slated for removal in Kilo, it is
also still there in master. So what's the right behavior here? Should I
tell heat users that it's safe/recommended to set admin_user or not?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Network issue with libvirt-xen driver, iptables race

[Anthony PERARD]

Hi all,

We have an issue with the driver libvirt-xen. When a guest is started by
Nova, nova-network is going to do some network setup and call
iptables-{save,restore}, and the Xen toolstack is going to setup the
vif of the guest, via a script, which also update the iptables.

The Xen script is simply calling those commands:
  ip link set dev ${dev} down
  ip link set dev ${dev} address fe:ff:ff:ff:ff:ff
  ip address flush dev ${dev}
  brctl addif ${bridge} ${dev}
  ip link set dev ${dev} up
  iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in "$dev" -j 
ACCEPT
  iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out "$dev" -j 
ACCEPT

$dev been by default vif$domid.$devid.

Only the call to iptables is an issue and fail fairly often when it looses
the race against iptables-{save,restore}.

It is possible to have Nova asking to run a different script that would not
call iptables. But that script would need to be store somewhere, in the
nova repo would be best.

Any though on that?

Is `iptables` call necessary for the vif with OpenStack?
If so, can nova-network do the update? Or the script called by the Xen
toolstack could take an OpenStack lock before calling iptables?

Bug report: https://bugs.launchpad.net/nova/+bug/1461642

Thanks,

-- 
Anthony PERARD

__
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] Why doesn't Gerrit email me?

[Louis Taylor]

On Tue, Jun 30, 2015 at 02:08:45PM +0100, Neil Jerram wrote:
> Apologies if this is an FAQ - I tried a quick search, but that didn't find
> anything that looked both up to date and authoritative.
> 
> I keep going back to Gerrit jobs that I've reviewed or commented on, and
> finding that there have been other comments since mine, but that Gerrit
> didn't email me about.
> 
> Does anyone know why that happens?  It's really important to my workflow,
> and to continuing review conversations effectively, that Gerrit emails new
> comments reliably and in good time.  Could I be doing something wrong that
> is causing this not to happen?

This is probably a silly question, but have you enabled email notifications for
all comments in your watched projects? You can create a watch item for a
particular project with 'owner:me' in the 'Only If' field to prevent a deluge
of comment notifications.

Cheers,
Louis


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

Re: [openstack-dev] Why doesn't Gerrit email me?

[Neil Jerram]

On 30/06/15 14:33, Julien Danjou wrote:

On Tue, Jun 30 2015, Neil Jerram wrote:


Apologies if this is an FAQ - I tried a quick search, but that didn't find
anything that looked both up to date and authoritative.

I keep going back to Gerrit jobs that I've reviewed or commented on, and
finding that there have been other comments since mine, but that Gerrit didn't
email me about.

Does anyone know why that happens?  It's really important to my workflow, and
to continuing review conversations effectively, that Gerrit emails new comments
reliably and in good time.  Could I be doing something wrong that is causing
this not to happen?


Maybe you need to add the projects you care about in "Watched Projects"
at https://review.openstack.org/#/settings/projects


Thanks for the suggestion.  I didn't know about that.

At the moment, however, I have nothing configured here - and AFAIK I 
never have had - and I _have_ received emails in the past for most of 
the Gerrit jobs that I have commented on.  Presumably, therefore, there 
is a default email notification behaviour that doesn't require anything 
under "Watched Projects".  I wonder why that would mostly work, but 
sometimes (apparently) not.


Regards,
Neil


__
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] Why doesn't Gerrit email me?

[Julien Danjou]

On Tue, Jun 30 2015, Neil Jerram wrote:

> Apologies if this is an FAQ - I tried a quick search, but that didn't find
> anything that looked both up to date and authoritative.
>
> I keep going back to Gerrit jobs that I've reviewed or commented on, and
> finding that there have been other comments since mine, but that Gerrit didn't
> email me about.
>
> Does anyone know why that happens?  It's really important to my workflow, and
> to continuing review conversations effectively, that Gerrit emails new 
> comments
> reliably and in good time.  Could I be doing something wrong that is causing
> this not to happen?

Maybe you need to add the projects you care about in "Watched Projects"
at https://review.openstack.org/#/settings/projects

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


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

Re: [openstack-dev] [oslo] Ideas to detect Oslo regressions earlier

[Doug Hellmann]

Excerpts from Victor Stinner's message of 2015-06-30 14:13:21 +0200:
> Hi,
> 
> Unfortunately, it looks like each regressions introduced by releases of 
> Oslo libraries are still common :-( We already have tools to detect 
> regressions, but they are run manually. It would be nice to automate 
> these tests and run them more frequently (at least one per week, or even 
> daily?).
> 
> There are tools to run unit tests of projects like neutronclient or nova 
> on the development version of oslo.* libraries. They take up to 12 hours 
> to run all tests. Example of tools:

12 hours was a guess -- I usually run the tests overnight because some
of them do tend to run several hours.

> 
> - "tox -e venv -- oslo_run_pre_release_tests" in each Oslo project
> - tools/oslo_run_cross_tests in oslotest
> 
> To prepare the latest bunch of releases, dims wrote two patches to run 
> nova unit tests and tempest:

tempest does run for every patch submitted, so we have the integration
test space covered. We don't have the unit test jobs and pep8 jobs
automated right now because of the test matrix. Today 73 projects in the
openstack/* namespace use oslo.config. Testing all of those for unit
test and pep8 regressions (yes, those happen) for one patch to
oslo.config would take 146 test nodes.

It's possible to run all of the unit tests serially on the same
server, using the tools you mention, but that takes longer than our
current timeout. We might be able to set up an experimental or periodic
job to run those tests, but given the length of time they take we
wouldn't want to run them automatically for each patch.

> 
> * https://review.openstack.org/#/c/186413/
> * https://review.openstack.org/#/c/186418/
> 
> Unfortunately, the stable version of some oslo.* projects were used 
> instead of the development version, and 2 regressions were missed :-/

Was that related to the --force-reinstall option in the tox.ini file?
Why is that there?

> It would nice to automate a job running cinder, nova and neutron unit 
> tests and tempest on the development versions (git master branch) of all 
> oslo.* projects. We can start with something simple: run 

I'm not sure what scenario that tests, though. We switched to
integration tests of released libraries because we don't want
applications to rely on unreleased features. We already run tempest
for patches to the libraries as part of the individual gate queues
for each library. Why do we need to run tempest with the master
branch of all of the libraries at once?

> tools/oslo_run_cross_tests and send the result by email every day to 
> some people interested by the result (ex: Oslo liaisons, or just me if 
> nobody cares). It would be nice to have a dedicated resource in the 
> OpenStack infra for such job.

We have a separate list for the stable-maint job reports. We could
create one for these reports, too.

> 
> I proposed to run "all" tests using Gerrit for each patch send to an 
> Oslo project, but it would use too much resources of the OpenStack infra.
> 
> Another idea would be to write a check job dedicated to Oslo releases 
> and use Gerrit to prepare a release (at least to tag a version in Git).

I'm working with Thierry and the infra team to design some tools for
reviewing release requests: https://review.openstack.org/191193

Doug

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

Re: [openstack-dev] [puppet] oslo.messaging version and RabbitMQ heartbeat support

[Emilien Macchi]

On 06/23/2015 06:07 PM, Mike Dorman wrote:
> As a follow up to https://review.openstack.org/#/c/194399/ and the
> meeting discussion earlier today, I’ve determined that everybody (RDU,
> Ubuntu, Debian) is packaging oslo.messaging 1.8.2 or 1.8.3 with the Kilo
> build.  (This is also the version we get on our internal Anvil-based
> build.)  This is considerably lower than 1.11.0 where the default
> rabbit_heartbeat_timeout_threshold changes (from 60 to 0.)
> 
> If we go forward using the default rabbit_heartbeat_timeout_threshold
> value of 60, that will be the correct default behavior up through
> oslo.messaging 1.10.x.
> 
> When people upgrade to 1.11.0 or higher, we’ll no longer match the
> upstream default behavior.  But, it should maintain the _actual_
> behavior (heartbeating enabled) for people doing an upgrade.  Once
> Liberty is cut, we should reevaluate to make sure we’re matching
> whatever the default is at that time.
> 
> However, the larger problem I see is that oslo.messaging
> requirements.txt in <=1.10.x does not enforce the needed versions of
> kombu and amqp for heartbeat to work:
> https://github.com/openstack/oslo.messaging/blob/1.8.2/requirements.txt#L25-L26
>  
> This is confusing as heartbeat is enabled by default!
> 
> I am not sure what the behavior is when heartbeat is enabled with older
> kombu or amqp.  Does anyone know?  If it silently fails, maybe we
> don’t care.  But if enabling heartbeat (by default,
> rabbit_heartbeat_timeout_threshold=60) actively breaks, that would be bad.
> 
> I see two options here:
> 
> 1)  Make default rabbit_heartbeat_timeout_threshold=60 in the Puppet
> modules, to strictly follow the upstream default in Kilo.  Reevaluate
> this default value for Liberty.  Ignore the kombu/amqp library stuff and
> hope “it just works itself out naturally.�

+1
We should follow:
* what popular distros ship
* what we test in our CI (trusty UCA & centos7 RDO)

> 2)  Add a rabbit_enable_heartbeat parameter to explicitly enable/disable
> the feature, and default to disable.  This goes against the current
> default behavior, but will match it for oslo.messaging >=1.11.0.  I
> think this is the safest path, as we won’t be automatically enabling
> heartbeat for people who don’t have a new enough kombu or amqp.
> 
> Personally, I like #1, because I am going to enable this feature,
> anyway.  And I can’t really imagine why one would _not_ want to enable
> it.  But I am fine implementing it either way, I just want to get it
> done so I can get off my local forks. :)
> 
> Thoughts?
> 
> Mike
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



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] Why doesn't Gerrit email me?

[Neil Jerram]

Apologies if this is an FAQ - I tried a quick search, but that didn't 
find anything that looked both up to date and authoritative.


I keep going back to Gerrit jobs that I've reviewed or commented on, and 
finding that there have been other comments since mine, but that Gerrit 
didn't email me about.


Does anyone know why that happens?  It's really important to my 
workflow, and to continuing review conversations effectively, that 
Gerrit emails new comments reliably and in good time.  Could I be doing 
something wrong that is causing this not to happen?


Many thanks,
Neil

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

Re: [openstack-dev] [puppet][ceph] puppet-ceph CI status

[Emilien Macchi]

On 06/29/2015 11:16 PM, Matt Fischer wrote:
> Ah, I don't have +2 on that repo, but the lgtm so your original plan is
> fine.
> 
> On Mon, Jun 29, 2015 at 5:59 PM, Matt Fischer  > wrote:
> 
> I can take a look at these tonight. Maybe also Clayton can review
> them? Neither of us were involved in the patches to my knowledge.
> 
> On Jun 29, 2015 5:09 PM, "Andrew Woodward"  > wrote:
> 
> Hi
> 
> Recent changes in the puppet modules infra left
> stackforge/puppet-ceph CI broken. We've resolved the issues in
> [1][2] However we are short on non-involved core-reviewers. 

You'll have to sqash the commits because our CI is voting for puppet4 &
beaker.

If this module does not fit for you, you can still patch project-config,
otherwise you'll need to fix everything in one single commit.

> I propose that we leave the patchs open through Wednesday and
> use lazy consensus and merge it if we don't receive any negative
> feedback.
> 
> [1] https://review.openstack.org/#/c/179645/
> [2] https://review.openstack.org/#/c/195959/
> -- 
> 
> --
> 
> Andrew Woodward
> 
> Mirantis
> 
> Fuel Community Ambassador
> 
> Ceph Community
> 
> 
> 
> __
> 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
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] [oslo] Ideas to detect Oslo regressions earlier

[Davanum Srinivas]

Victor,

Thanks for bringing this up. All good ideas, i'd recommend any
liaisons interested to test what they can towards the end of the week
and bring it up on the Monday Oslo meeting and/or log bugs as they
find stuff. Since we talk about releases for the week at that meeting,
we can do a go or no-go decision for specific libraries and then cut
the libraries.

For the record, the oslo.db issue was debated before the release and a
few reviews were filed. The oslo.versionedobjects definitely something
i missed. apologies.

Thanks,
dims

On Tue, Jun 30, 2015 at 8:13 AM, Victor Stinner  wrote:
> Hi,
>
> Unfortunately, it looks like each regressions introduced by releases of Oslo
> libraries are still common :-( We already have tools to detect regressions,
> but they are run manually. It would be nice to automate these tests and run
> them more frequently (at least one per week, or even daily?).
>
> There are tools to run unit tests of projects like neutronclient or nova on
> the development version of oslo.* libraries. They take up to 12 hours to run
> all tests. Example of tools:
>
> - "tox -e venv -- oslo_run_pre_release_tests" in each Oslo project
> - tools/oslo_run_cross_tests in oslotest
>
> To prepare the latest bunch of releases, dims wrote two patches to run nova
> unit tests and tempest:
>
> * https://review.openstack.org/#/c/186413/
> * https://review.openstack.org/#/c/186418/
>
> Unfortunately, the stable version of some oslo.* projects were used instead
> of the development version, and 2 regressions were missed :-/
>
> It would nice to automate a job running cinder, nova and neutron unit tests
> and tempest on the development versions (git master branch) of all oslo.*
> projects. We can start with something simple: run tools/oslo_run_cross_tests
> and send the result by email every day to some people interested by the
> result (ex: Oslo liaisons, or just me if nobody cares). It would be nice to
> have a dedicated resource in the OpenStack infra for such job.
>
> I proposed to run "all" tests using Gerrit for each patch send to an Oslo
> project, but it would use too much resources of the OpenStack infra.
>
> Another idea would be to write a check job dedicated to Oslo releases and
> use Gerrit to prepare a release (at least to tag a version in Git).
>
> Victor
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [api][nova][ironic] Microversion API HTTP header

[Dean Troyer]

On Mon, Jun 29, 2015 at 7:41 PM, Ken'ichi Ohmichi 
wrote:

> Yeah, I had the same thinking.
> Based on it, we can remove generic name(compute, identity, etc) from
> API microversions header.
>

I'm not certain we want to remove the name, but to use the type field as
the value of the name in the header.


> I tend to prefer generic name(compute, identity, etc) because the name
> seems stable.
>

+1

dt

-- 

Dean Troyer
dtro...@gmail.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

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Julien Danjou]

On Tue, Jun 30 2015, Ildikó Váncsa wrote:

> Will this be accessible in the same way as currently or it needs
> changes on client side?

You may just need to pass more options to the client to force another
endpoint to be used when talking to the alarming part.
We could make this change in the client by default though.

-- 
Julien Danjou
# Free Software hacker
# http://julien.danjou.info


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

[openstack-dev] [oslo] Ideas to detect Oslo regressions earlier

[Victor Stinner]

Hi,

Unfortunately, it looks like each regressions introduced by releases of 
Oslo libraries are still common :-( We already have tools to detect 
regressions, but they are run manually. It would be nice to automate 
these tests and run them more frequently (at least one per week, or even 
daily?).


There are tools to run unit tests of projects like neutronclient or nova 
on the development version of oslo.* libraries. They take up to 12 hours 
to run all tests. Example of tools:


- "tox -e venv -- oslo_run_pre_release_tests" in each Oslo project
- tools/oslo_run_cross_tests in oslotest

To prepare the latest bunch of releases, dims wrote two patches to run 
nova unit tests and tempest:


* https://review.openstack.org/#/c/186413/
* https://review.openstack.org/#/c/186418/

Unfortunately, the stable version of some oslo.* projects were used 
instead of the development version, and 2 regressions were missed :-/


It would nice to automate a job running cinder, nova and neutron unit 
tests and tempest on the development versions (git master branch) of all 
oslo.* projects. We can start with something simple: run 
tools/oslo_run_cross_tests and send the result by email every day to 
some people interested by the result (ex: Oslo liaisons, or just me if 
nobody cares). It would be nice to have a dedicated resource in the 
OpenStack infra for such job.


I proposed to run "all" tests using Gerrit for each patch send to an 
Oslo project, but it would use too much resources of the OpenStack infra.


Another idea would be to write a check job dedicated to Oslo releases 
and use Gerrit to prepare a release (at least to tag a version in Git).


Victor

__
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] [devstack] Use devstack/master to install older releases

[Emmanuel Cazenave]

Hi,

I'm trying to use devstack/master to install older releases of swift and
keystone; the installation fails with a version conflict on pbr.

A little bit of background : I work on a CI that needs to run the swift
functional test suite and the swift part of tempest against swift/icehouse,
swift/ijuno swift/kilo swift/master.

My first approach was to use devstack/icehouse to install swift/icehouse,
devstack/juno for swift/juno, etc

I am now trying to use devstack/master in every cases because I need this :
https://review.openstack.org/#/c/115307/ which allow not to install
nova+glance which I don't need at all, and whose installation takes a
really long time.

So I use devstack/master, and set SWIFT_BRANCH and KEYSTONE_BRANCH to
stable/icehouse for example. The installation  fails because of a version
conflict :
This
https://review.openstack.org/gitweb?p=openstack-dev/devstack.git;a=blob;f=lib/infra;h=3d68e45bd9954a7ce0003d809428c979663d2ede;hb=HEAD#l51
install  the last pbr version, whereas keystone requires pdb<1.0 :
https://github.com/openstack/keystone/blob/stable/icehouse/requirements.txt#L2

I don't now anything about this lib/infra : does it really need to install
unconditionally the last pbr ?
Is my use case of installing older releases with devstack/master not
supported ?

Thanks.

Emmanuel Cazenave
__
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] Security Group API differences between Neutron and Amazon AWS

[Sean M. Collins]

Good morning,

In last week's meeting I had an action item[0] to take a look at the Amazon
EC2/VPC API and determine what differences there are between Neutron's
and theirs.

In some spec reviews, I have been commenting about trying to keep the
Neutron security group API from "drifting" too far from the Amazon EC2
API, since the concept of the "security group" came from Amazon and I
believe that we should not be bolting on more functionality to an Amazon
concept. Rather, I would like to see Neutron create new APIs to further
differentiate OpenStack from Amazon AWS, since that gives us elbow room
to innovate without having to worry about compatibility, and possibly
gives us cover on the legal front since there are a lot of court cases
flying around about patents on APIs[1].

In many instances, I believe that much of the new functionality that
people are seeking to create should be put into the
Firewall-As-A-Service API, but that's a discussion for another e-mail.

Anyway, over a cup of coffee today I went and did some reading about the
differences between the Neutron security group API and Amazon's. Here
are my preliminary findings.

Amazon's Security Group API comes in two types:

* EC2-Classic

* EC2-VPC

Security groups in the VPC API are documented at:

http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html

There is a useful section on the differences between the EC2-Classic and
EC2-VPC.

A more in depth documentation for the AWS Security Group API is located
here: 

Data Types:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_SecurityGroup.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_IpPermission.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_PrefixListId.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_UserIdGroupPair.html

API methods:

http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupEgress.html

I used the following for the Security Group API on the Neutron side:

http://developer.openstack.org/api-ref-networking-v2-ext.html

Overall, the attributes are *named differently* but contain similar
concepts. Both Security Group APIs contain:

* IP Prefix/CIDR

* From port

* To port 

* Protocol

One difference is that the AWS API distinguishes between
Ingress and Egress at the API endpoint, rather than being an attribute.

https://ec2.amazonaws.com/?Action=AuthorizeSecurityGroupEgress

https://ec2.amazonaws.com/?Action=AuthorizeSecurityGroupIngress

Another difference is that the Neutron Security Group API does have an
interesting attribute named remote_group_id that doesn't have any real
documentation, but I am making a guess that it possibly matches up to
the UserIdGroupPair type in AWS. Perhaps someone could shed some
light on that, and then document it (not sure where yet).

The AWS API and Neutron also share an attribute that can list an IP
prefix to match - remote_prefix_id in Neutron, and PrefixListIds in EC2.
However it appears that the PrefixListIds type can contain multiple
prefixes.

Neutron has an ethertype for selecting IPv4 or IPv6, while Amazon does
not, since Amazon does not have IPv6 in EC2 (they do have IPv6 in the
elastic loadbalancer product[2]).

This is at least my preliminary findings. Do feel free to double check
my work and see if there is anything that I have overlooked or made a
mistake on.


[0]: 
http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-06-22-21.00.html
[1]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.
[2]: 
https://aws.amazon.com/about-aws/whats-new/2011/05/24/elb-ipv6-zoneapex-securitygroups/

-- 
Sean M. Collins

__
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] [Tricircle]Weekly Meeting 2015.07.01

[Zhipeng Huang]

Hi Team,

We will have weekly meeting on Wednesday from UTC1300 to UTC1400 as usual.
The main topic would be to discuss https://review.openstack.org/#/c/196564/,
and any other business that people are interested :)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
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] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Sebastian Kalinowski]

+1

2015-06-30 10:38 GMT+02:00 Evgeniy L :

> +1
>
> On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky 
> wrote:
>
>> +1. Alex's doing a great job!
>>
>> On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
>>  wrote:
>> > +1
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Ildikó Váncsa]

> -Original Message-
> From: Julien Danjou [mailto:jul...@danjou.info]
> Sent: June 30, 2015 10:10
> To: Ildikó Váncsa
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
> 
> On Mon, Jun 29 2015, Ildikó Váncsa wrote:
> 
> > I think removing options from the API requires version bump. So if we
> > plan to do this, that should be introduced in v3 as opposed to v2,
> > which should remain the same and maintained for two cycles (assuming
> > that we still have this policy in OpenStack). It this is achievable by
> > removing the old code and relying on the new repo that would be the
> > best, if not then we need to figure out how to freeze the old code.
> 
> This is not an API change as we're not modifying anything in the API.
> It's just the endpoint *potentially* split in two. But you can also merge 
> them as they are 2 separate entities (/v2/alarms and /v2/*).
> So there's no need for a v3 here.

Will this be accessible in the same way as currently or it needs changes on 
client side?

Best Regards,
Ildikó

> As the consensus goes toward removal, I'll work on a patch for that.
> 
> --
> Julien Danjou
> /* Free Software hacker
>http://julien.danjou.info */
__
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] [nova] schedule instance based on CPU frequency ?

[ChangBo Guo]

2015-06-30 16:38 GMT+08:00 Nikola Đipanov :

> On 06/30/2015 07:42 AM, ChangBo Guo wrote:
> > CPU frequency  is an import performance parameter,  currently  nova
> > drivers just  report cpu_info without frequency.   we stored the compute
> > node cpu_info in database with colum compute_nodes.cpu_info,  we can add
> > the frequency  easily.
> >
> > The usage of  cpu frequency  I  can think is used to schedule to meet
> > applications which need high frequency.  add a frequency based filter ?
> > if we need this , I would like to propose  a spec for this .
> >
>
> Would it be possible to give more details on the type of app that will
> have this _specific_ requirement.
>
> I don't think I have all the details in my head, but it seems to me that
> the frequency of the hypervisor CPU is just not something that carries
> enough information for users about how most applications will perform. I
> would imagine they would either want "the fastest" or some specialized
> HW for specific applications.
>
> >
> > There are two steps to leverage cpu frequency:
> > 1.  report cpu frequency  and record the value,  nova hypervisor-show
> > will include the value .
> >
> > 2.  filter compute nodes based  cpu frequency.
> > add a new scheduler filter to do that
> >
> > before I start to do these stuff.  I would like to your  input .
> >
> > Do we need leverage CPU frequency  in Nova ?
> > if yes, do we need a new filter  or  leverage existing filter to use
> > frequency ?
> >
>
> I don't think we do personally - but I may not understand what problem
> this is trying to solve.
>
> But even if we do - the most important thing IMHO would be _how_ to
> expose it to users (do we allow them to request a minimum frequency, or
> a specific one or something else). API contract is extremely important
> here because we want to make sure that we are exposing the right
> semantics for users - as we would want this to be usable to as big a
> group of people as possible.
>

 The use case:  user want to integrate hardware management  with api
/os-hypervisors,
  they want to know more details about hardware, so cpu frequency is good
to have.
  so I think if we can provide it to user, we don't change database schema,
just change colume
   compute_nodes.cpu_info, is it that ok ?


> If it's just about having a high performance tier - can we do this with
> host aggregates and flavors? These are the questions we want to answer
> first IMHO.
>

  yes we can host aggregates to solve the schedule.

>
> N.
>
> > --
> > ChangBo Guo(gcb)
> >
> >
> >
> __
> > 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
>



-- 
ChangBo Guo(gcb)
__
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] [Mistral] Proposing to remove mistral.utils.wf_trace module

[Lingxian Kong]

Hi, guys,

TL;DR
After implementation of the blueprint[1], now we use olso.log module in
Mistral, just as the same with other projects. However, we still use
mistral.utils.wf_trace module to make some info insertion into log
messages(we want to log execution id or task id during workflow running),
which is a little bit ugly, considering it could be replaced using oslo.log
features itself.

​So, I ​submit the proposal here to bring more people to have an open
discussion, to make sure wo make consensus about that before I start to do
code work.


Below is the long version in rst format:

Problem Description
===
Currently, we have mistral.utils.wf_trace module to get execution-id and
task-id during mistral workflow execution, then insert them to the log, so
there are plenty of wf_trace.info invokings all around our code repo, which
is much more likely a hacking to log module funtionality, and it's not
consistent with most of the log behavior in code writing.

Proposed Change
===
Instead of adding an extra wf_trace module, we make use of the capability
provided by oslo.log. Take an example, we have code as below::

wf_ex = task_ex.workflow_execution
wf_trace.info(task_ex, "Task '%s' [%s -> %s]" % (task_ex.name,
task_ex.state, state))

then, you will see from the log with content below:

``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO Task
'my_task' [WAITING -> RUNNING]
(execution_id=c79b656f-f57f-4761-a270-138ee2417e54
task_id=a8935974-5468-de89-b785-138ee241qefd)``

the execution_id and task_i
​​
d are automatically inserted in wf_trace module. With oslo.log, we could
change the log behavior::

wf_ex = task_ex.workflow_execution
LOG.info("Task '%s' [%s -> %s]" % (task_ex.name, task_ex.state, state),
resource={'type': 'workflow', 'id': wf_ex.id})

and don't forget config *logging_default_format_string* value in
*mistral.conf* to:

``%(asctime)s.%(msecs)03d %(process)d %(levelname)s %(name)s [-]
%(resource)s%(message)s``
​​


so, the log content would be like this:

``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task 'my_task' [WAITING ->
RUNNING]``

As you could noticed, the task_id is lost, yes, actually, for the time
being, oslo.log don't provide the capability such as recording various
resources at the same time in one line, which I have send an email to
openstack-dev mailing list to ask what oslo team suggest for this issue.

However, IMO, we have enough information for the operators to debug, we
have execution-id, task name, etc, and most importnantly it's a more
general way for logging.

But, if you really don't tolerate this change, we have workaround here
before the oslo.log has a final solution(maybe that will never happen). We
change the code as below::

wf_ex = task_ex.workflow_execution
LOG.info("Task '%s'(%s) [%s -> %s]" % (task_ex.name, task_ex.id,
task_ex.state, state), resource={'type': 'workflow', 'id': wf_ex.id})

so, the log content would be like this:

``2015-06-26 04:09:50.326 19492 mistral.engine.default_engine INFO
[workflow-c79b656f-f57f-4761-a270-138ee2417e54] Task
'my_task'(a8935974-5468-de89-b785-138ee241qefd) [WAITING -> RUNNING]``

Finally, we get rid of the redundant wf_trace module from Mistral, which is
really important for an engineer with OCD :-)

REST API Impact
---
No, it's just an improvement internally

Security Impact
---
No

Other End User Impact
-
No

Performance Impact
--
Absolutely no.

Other Deployer Impact
-
No

Developer Impact

Yes, it will change how the developers want to log something related to
executions or tasks.

Alternatives

Anyway, we could keep the wf_trace module as it is, but it's a very ugly
way.

References
==
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters

[1]: https://blueprints.launchpad.net/mistral/+spec/mistral-log-enhancement
-- 
Regards!
---
Lingxian Kong
__
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] [Mistral][Murano] What's the latest/greatest on YAQL?

[Serg Melikyan]

Hi Dmitri,

We share your concerns and migration to the new YAQL is our priority too.
Regarding estimates, I would say month in a worst case.

On Tue, Jun 30, 2015 at 8:09 AM, Dmitri Zimine 
wrote:

> Thanks Stan,
>
> This release is few more months. How soon?  Are you planning to support
> 0.2 in the meantime?
>
> We are really pressed on this transition to 1.0.
> For instance. Number 1 user error while dealing with YAQL is using ==
> instead of =.
> We had this discussion and you and Alex and you suggested it’s easy to
> redefine.
>
> But… … The short is we need to move to 1.0 to do it. Because from what I
> figured so far, in 0.2 I can’t naively extend the an operator, as it won’t
> parse. I did make it work on 0.2 but this required a hack in the YAQL
> library itself, need to add ‘==‘ to both lexer.py and parser.py. At least
> what I figured.
>
> I see the tokens are already generalized in 1.0. It doesn’t seem to worth
> backporting it to 0.2, but if this is a way, let us know.
>
> Mistral is betting on YAQL, please help.
>
> DZ.
>
> On Jun 26, 2015, at 2:20 AM, Stan Lagun  wrote:
>
> The plan is to move to yaql 1.0 this release.  Please do not merge yaql
> 1.0 into Mistral yet. Migration is going to happen really soon
>
> Sincerely yours,
> Stan Lagun
> Principal Software Engineer @ Mirantis
>
> 
>
> On Fri, Jun 26, 2015 at 8:17 AM, Renat Akhmerov 
> wrote:
>
>> Yes, it’s a pretty important thing that we’d like to clarify as soon as
>> possible.
>>
>> Any input from Murano team?
>>
>> Renat Akhmerov
>> @ Mirantis Inc.
>>
>>
>>
>> > On 26 Jun 2015, at 06:01, Dmitri Zimine  wrote:
>> >
>> > Folks,
>> >
>> > it’s been some time,what’s the news:
>> >
>> > * Is Murano moving YAQL 1.0 in this cycle?
>> > * What’s your recommendation for this cycle - stay on 0.2.6 or move on?
>> > * Any progress on documentation?
>> >
>> > Thanks, DZ>
>> >
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
__
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] [nova] gate is wedged

[Andreas Jaeger]

On 06/30/2015 10:39 AM, Sylvain Bauza wrote:



Le 30/06/2015 10:32, Victor Stinner a écrit :

Hi,

Le 30/06/2015 05:49, Matt Riedemann a écrit :

Alternatively, oslo.versionedobjects 0.5.1 is cut after
https://review.openstack.org/#/c/196926/ is merged and then we just need
haypo's test_db_api fix for the oslo.db 2.0.0 change:

https://review.openstack.org/#/c/196719/


I updated my patch "Update test_db_api for oslo.db 2.0" (1) to not
depend on my "Fix Python 3 issues in nova.db.sqlalchemy" patch. I
should now be easier to fix gates.

(1) https://review.openstack.org/#/c/196719/
(2) https://review.openstack.org/#/c/195191/

I suggest to block my Python 3 patch (2) until gates are fixed.



Jenkins seems in a pretty bad shape too, by giving UNSTABLE statuses for
most of the jobs.

http://logs.openstack.org/91/195191/6/check/gate-nova-python27/4a1fdae/console.html#_2015-06-30_05_44_39_393


Yes, we have a harddisk failure ;(

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


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

[openstack-dev] [all] OpenStack CI harddisk failure - jobs are UNSTABLE

[Andreas Jaeger]

static.openstack.org has a harddisk failure for the log volume
which causes jobs to fail with "UNSTABLE" when uploading log files.

Do not recheck those jobs until you get the green light and and 
everything is working again,


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] [nova] gate is wedged

[Victor Stinner]

Le 30/06/2015 10:32, Victor Stinner a écrit :

I updated my patch "Update test_db_api for oslo.db 2.0" (1) ...

(1) https://review.openstack.org/#/c/196719/


I updated my patch again to also block oslo.versionedobjects 0.5.0 in 
requirements. So we can have two patches to fix the bug ;) The patch (1) 
only fixes the bug, whereas the Python 3 patch fixes many other things 
(Python 3 support, remove test-requirements-py3.txt, etc.).


At the same time, we have issues on the OpenStack infra :-/

10:48 -!- ChanServ changed the topic of #openstack-infra to: OpenStack 
CI is down due to hard drive failures


Victor

__
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] [nova] schedule instance based on CPU frequency ?

[Daniel P. Berrange]

On Tue, Jun 30, 2015 at 02:42:01PM +0800, ChangBo Guo wrote:
> CPU frequency  is an import performance parameter,  currently  nova drivers
> just  report cpu_info without frequency.   we stored the compute node
> cpu_info in database with colum compute_nodes.cpu_info,  we can add the
> frequency  easily.

Is CPU frequency really an accurate metric for determining relative
performance of different hardware ? It seems maximum CPU frequency of
CPUs has rather plateaued, and chip vendors have been following
different avenues to improve performance of their chips such as multicore,
multhreads, and various other architectural changes. So I'm not sure that
just having a filter that compares CPU frequency is neccessarily going to
give useful results. ie faster frequency no longer neccessarily implies
faster performance.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

__
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] [nova] schedule instance based on CPU frequency ?

[Nikola Đipanov]

On 06/30/2015 07:42 AM, ChangBo Guo wrote:
> CPU frequency  is an import performance parameter,  currently  nova
> drivers just  report cpu_info without frequency.   we stored the compute
> node cpu_info in database with colum compute_nodes.cpu_info,  we can add
> the frequency  easily.
> 
> The usage of  cpu frequency  I  can think is used to schedule to meet
> applications which need high frequency.  add a frequency based filter ?
> if we need this , I would like to propose  a spec for this .
> 

Would it be possible to give more details on the type of app that will
have this _specific_ requirement.

I don't think I have all the details in my head, but it seems to me that
the frequency of the hypervisor CPU is just not something that carries
enough information for users about how most applications will perform. I
would imagine they would either want "the fastest" or some specialized
HW for specific applications.

> 
> There are two steps to leverage cpu frequency:
> 1.  report cpu frequency  and record the value,  nova hypervisor-show
> will include the value .
> 
> 2.  filter compute nodes based  cpu frequency.
> add a new scheduler filter to do that
> 
> before I start to do these stuff.  I would like to your  input .
> 
> Do we need leverage CPU frequency  in Nova ?
> if yes, do we need a new filter  or  leverage existing filter to use
> frequency ?
> 

I don't think we do personally - but I may not understand what problem
this is trying to solve.

But even if we do - the most important thing IMHO would be _how_ to
expose it to users (do we allow them to request a minimum frequency, or
a specific one or something else). API contract is extremely important
here because we want to make sure that we are exposing the right
semantics for users - as we would want this to be usable to as big a
group of people as possible.

If it's just about having a high performance tier - can we do this with
host aggregates and flavors? These are the questions we want to answer
first IMHO.

N.

> -- 
> ChangBo Guo(gcb)
> 
> 
> __
> 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] [nova] gate is wedged

[Sylvain Bauza]

Le 30/06/2015 10:32, Victor Stinner a écrit :

Hi,

Le 30/06/2015 05:49, Matt Riedemann a écrit :

Alternatively, oslo.versionedobjects 0.5.1 is cut after
https://review.openstack.org/#/c/196926/ is merged and then we just need
haypo's test_db_api fix for the oslo.db 2.0.0 change:

https://review.openstack.org/#/c/196719/


I updated my patch "Update test_db_api for oslo.db 2.0" (1) to not 
depend on my "Fix Python 3 issues in nova.db.sqlalchemy" patch. I 
should now be easier to fix gates.


(1) https://review.openstack.org/#/c/196719/
(2) https://review.openstack.org/#/c/195191/

I suggest to block my Python 3 patch (2) until gates are fixed.



Jenkins seems in a pretty bad shape too, by giving UNSTABLE statuses for 
most of the jobs.


http://logs.openstack.org/91/195191/6/check/gate-nova-python27/4a1fdae/console.html#_2015-06-30_05_44_39_393

-Sylvain


Victor

__ 


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] [Fuel][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core

[Evgeniy L]

+1

On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky 
wrote:

> +1. Alex's doing a great job!
>
> On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
>  wrote:
> > +1
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] gate is wedged

[Victor Stinner]

Hi,

Le 30/06/2015 05:49, Matt Riedemann a écrit :

Alternatively, oslo.versionedobjects 0.5.1 is cut after
https://review.openstack.org/#/c/196926/ is merged and then we just need
haypo's test_db_api fix for the oslo.db 2.0.0 change:

https://review.openstack.org/#/c/196719/


I updated my patch "Update test_db_api for oslo.db 2.0" (1) to not 
depend on my "Fix Python 3 issues in nova.db.sqlalchemy" patch. I should 
now be easier to fix gates.


(1) https://review.openstack.org/#/c/196719/
(2) https://review.openstack.org/#/c/195191/

I suggest to block my Python 3 patch (2) until gates are fixed.

Victor

__
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] Aodh has been imported, next steps

[Julien Danjou]

On Mon, Jun 29 2015, Julien Danjou wrote:

FTR today I've copied the members of ceilometer-core to aodh-core.

We'll be able to manage to the team independently like we do with
Gnocchi, based on who is doing what in the different repositories.

> Hi team,
>
> Aodh has been imported and is now available at:
>
>   https://git.openstack.org/cgit/openstack/aodh/
>
> You should add it to your review list on Gerrit I guess.
>
> I'm pretty clear about the next steps for Aodh and what we need to
> build, but something is still not clear to me. Do we go ahead and bite
> the bullet and remove ceilometer-alarming from ceilometer in Liberty?

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


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

Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps

[Julien Danjou]

On Mon, Jun 29 2015, Ildikó Váncsa wrote:

> I think removing options from the API requires version bump. So if we plan to
> do this, that should be introduced in v3 as opposed to v2, which should remain
> the same and maintained for two cycles (assuming that we still have this 
> policy
> in OpenStack). It this is achievable by removing the old code and relying on
> the new repo that would be the best, if not then we need to figure out how to
> freeze the old code.

This is not an API change as we're not modifying anything in the API.
It's just the endpoint *potentially* split in two. But you can also
merge them as they are 2 separate entities (/v2/alarms and /v2/*).
So there's no need for a v3 here.

As the consensus goes toward removal, I'll work on a patch for that.

-- 
Julien Danjou
/* Free Software hacker
   http://julien.danjou.info */


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

[openstack-dev] [Nova] Libvirt - updates backing file permission of qcow2 image on launching instance

[Agrawal, Ankit]

Hi All,

I am trying to fix a race condition between imagebackend and imagecache in nova 
(openstack) while creating an instance using qcow2 image backend. On creating a 
qcow2 image libvirt stores the base/backing file path reference while copying 
the image at instance disk info. While spawning the instance nova usage this 
base file reference as a backing file to launch instance.

When base file is created in nova image cache directory its owner is set to 
openstack (a nova user) but on launching the instance from guest.launch, 
libvirt updates the base/backing file owner from openstack to libvirt-qemu 
which causes permission error if we try to use that base file later.

Can someone please help me to understand why libvirt is updating the owner of 
base file stored in image cache directory, is it a bug in libvirt or the 
expected behaviour?

Thanks & Regards,
Ankit Agrawal


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.__
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