date:20140331

Thomas Goirand wrote:
 Anyway, since it seems there's a consensus on this:
 
 happybase=0.5,!=0.7
 
 that's what I did here:
 https://review.openstack.org/#/c/82438/
 
 Please approve it.

The currently-proposed patch has happybase=0.5,!=0.6,!=0.7, so now
I'm confused. Since I think you updated the commit title and failed to
update the requirements file, I'll wait a bit before approving.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

Mark Atwood wrote:
 Are there plans for a PGP keysigning party at the Juno Summit in
 Atlanta, similar to the one at the Icehouse summit in Hong Kong?
 
 Inspired by the URL at
 https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Icehouse_Summit
 I looked for 
 https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit
 to discover that that wiki page does not yet exist and I do not have
 permission to create it.

Err... anyone can create anything on the wiki. Maybe you weren't logged in ?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

Jeremy Stanley wrote:
 On 2014-03-29 19:00:33 -0700 (-0700), Mark Atwood wrote:
 Are there plans for a PGP keysigning party at the Juno Summit in
 Atlanta, similar to the one at the Icehouse summit in Hong Kong?
 [...]
 
 Absolutely!
 
 Thierry, any ideas on how to best fit it into the schedule?
 ...hopefully not wedged into a restroom break like I ended up doing
 last time. ;)

No miracle here... All slots are pretty full as expected. I think our
best bet is still the 30-min morning break on Wednesday or Thursday at
10:30am.

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Disaster Recovery for OpenStack - plan for Juno design summit - discussion reminder

2014-03-31 Thread Ronen Kat

For those who are interested we will discuss the disaster recovery 
use-cases and how to proceed toward the Juno summit on April 2 at 17:00 
UTC (1PM ET) - invitation below.
Agenda and previous discussion history in the Etherpad link below.


Call-in: 
https://www.teleconference.att.com/servlet/glbAccess?process=1accessCode=6406941accessNumber=1809417783#C2
 

Passcode: 6406941 

Etherpad: 
https://etherpad.openstack.org/p/juno-disaster-recovery-call-for-stakeholders 

Wiki: https://wiki.openstack.org/wiki/DisasterRecovery


Regards,
__
Ronen I. Kat, PhD
Storage Research
IBM Research - Haifa
Phone: +972.3.7689493
Email: ronen...@il.ibm.com


invite-201404021700UTC.ics
Description: Binary data
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

2014-03-31 Thread Timur Sufiev

Hello, Akihiro

Thanks for the advice (and sorry for not very timely response)! I've
added last stable/havana release to the test-requirements, and
received some new error from the Jenknins' side: [1]. At first I
thought that the problem is caused by the reverse order of settings
modules inclusion (and almost renounced the idea of change [2]), but
today read the code and traceback again and realized that this error
happens even before muranodashboard settings come into play! So now it
seems to me that there are some inherent problems with horizon package
installation with pip even if the source different from the PyPi is
used. Is that a known issue or am I doing something wrong?

[1]
http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
[2] https://review.openstack.org/#/c/68125/

On Thu, Mar 20, 2014 at 9:50 PM, Akihiro Motoki amot...@gmail.com wrote:
As a workaround you can use tarball in requirements.txt (or
test-requirements.txt).
Each versions of Horizon/openstack_dashboard is available at
http://tarballs.openstack.org/horizon/.
Each tarball is generated every time corresponding branch or tag is updated.
If you would like to use horizon I-3 as a requirement, please add the
following line to your requirements.txt:

http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz

Thanks,
Akihiro

On Fri, Mar 21, 2014 at 2:22 AM, Paul Belanger
paul.belan...@polybeacon.com wrote:
On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev tsuf...@mirantis.com wrote:
It depends on openstack_dashboard, namely on
openstack_dashboard.settings. So it is fine from Murano's point of
view to have openstack_dashboard published on PyPi. Many thanks for
considering my request :).

We are having this issue too, for now we have worked around it with
pip switches allowing to download from an external source, but
hopefully we'll get horizon and openstack_dashboard split out in the
near future.

Like you, we've built a dashboard atop of horizon, mostly because of
the existing keystone integration. Everything else we do is external
to OpenStack.

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger

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

--
Timur Sufiev

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

Re: [openstack-dev] [nova] SR-IOV and IOMMU check

2014-03-31 Thread Daniel P. Berrange

On Fri, Mar 28, 2014 at 11:14:49PM -0400, Steve Gordon wrote:
 - Original Message -
  This is the approach mentioned by linux-kvm.org
  
  http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM
  
  3. reboot and verify that your system has IOMMU support
  
  AMD Machine
  dmesg | grep AMD-Vi
   ...
   AMD-Vi: Enabling IOMMU at :00:00.2 cap 0x40
   AMD-Vi: Lazy IO/TLB flushing enabled
   AMD-Vi: Initialized for Passthrough Mode
   ...
  Intel Machine
  dmesg | grep -e DMAR -e IOMMU
   ...
   DMAR:DRHD base: 0x00feb03000 flags: 0x0
   IOMMU feb03000: ver 1:0 cap c9008020e30260 ecap 1000
   ...
 
 Right, but the question is whether grepping dmesg is an acceptable/stable
 API to be relying on from the Nova level. Basically what I'm saying is
 the reason there isn't a robust way to check this from OpenStack is that
 there doesn't appear to be a robust way to check this from the kernel?

Historically there was no good way to determine this from the kernel.
Dmesg logs were the best there is.  With new style VFIO, however, we
can now reliably determine the level of support and even more importantly
what PCI devices must be handled together as a group.


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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

2014-03-31 Thread Jay Lau

Hi,

Currently with VMWare VCDriver, one nova compute can manage multiple
clusters/RPs, this caused cluster admin cannot do live migration between
clusters/PRs if those clusters/PRs managed by one nova compute as the
current live migration logic request at least two nova computes.

A bug [1] was also filed to trace VMWare live migration issue.

I'm now trying the following solution to see if it is acceptable for a fix,
the fix wants enable live migration with one nova compute:
1) When live migration check if host are same, check both host and node for
the VM instance.
2) When nova scheduler select destination for live migration, the live
migration task should put (host, node) to attempted hosts.
3) Nova scheduler needs to be enhanced to support ignored_nodes.
4) nova compute need to be enhanced to check host and node when doing live
migration.

I also uploaded a WIP patch [2] for you to review the idea of the fix and
hope can get some comments from you.

[1] https://bugs.launchpad.net/nova/+bug/1192192
[2] https://review.openstack.org/#/c/84085

-- 
Thanks,

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

2014-03-31 Thread Timur Sufiev

Hello, Paul

Thank you for the reply (and sorry for not timely response from my
side)! Are you passing external sources to pip the way Akihiro
described in this thread? Or are you using some custom install script
that installs package dependencies in its own way? I'm asking because
I've tried the solution suggested by Akihiro and it didn't go
smoothly.

On Thu, Mar 20, 2014 at 9:22 PM, Paul Belanger
paul.belan...@polybeacon.com wrote:
 On Mon, Mar 17, 2014 at 5:22 AM, Timur Sufiev tsuf...@mirantis.com wrote:
 It depends on openstack_dashboard, namely on
 openstack_dashboard.settings. So it is fine from Murano's point of
 view to have openstack_dashboard published on PyPi. Many thanks for
 considering my request :).

 We are having this issue too, for now we have worked around it with
 pip switches allowing to download from an external source, but
 hopefully we'll get horizon and openstack_dashboard split out in the
 near future.

 Like you, we've built a dashboard atop of horizon, mostly because of
 the existing keystone integration.  Everything else we do is external
 to OpenStack.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter: 
 https://twitter.com/pabelanger

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



-- 
Timur Sufiev

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

Re: [openstack-dev] [Swift] Request's Round trip time

2014-03-31 Thread Hua ZZ Zhang

Sumit,

I'm working on profiling middleware and tools for Swift debugging on
performance issue.
This tool is powerful to get understanding how is code running at the
function level by collecting
metrics in statistical way. I think you maybe try this tool and see if you
can get RTT at proxy server side.
Remember to get the RTT information via query on the function __call__
of ./swift/proxy/server.py.
Here's the patch.
https://review.openstack.org/#/c/53270/24

I'm also thinking of proposing another tool to trace the request process
path and tie the timing
information together in order to give you a full picture in hierarchical
way so that you can understand
how well each Swift server component behaves for a specific request.

Any feedback is welcomed.

-Edward Zhang




   
 Sumit Gaur
 sumitkgaur@gmail 
 .com  To 
   OpenStack Development Mailing List 
 2014-03-31 下午   (not for usage questions)  
 01:52 openstack-dev@lists.openstack.org 
cc 
   
 Please respond to Subject 
OpenStack [openstack-dev]  [Swift] Request's  
DevelopmentRound trip time 
   Mailing List
  \(not for usage  
   questions\)
 openstack-dev@li 
 sts.openstack.org 
  
   
   




Hi
I want to see the Round Trip Time for swift request in proxy log. I am able
to see RTT for failures and timeouts and no RTT for normal requests. Do I
need to set and config param.
Thanks
sumit___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
inline: graycol.gifinline: pic13949.gifinline: ecblank.gif___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [RelMgt] PTL candidacy

Hi everyone,

I'm writing to announce my candidacy for the Release management Program
Technical Lead position.

The Release management program is composed of 3 subteams.

On the release cycle management front, during the Icehouse cycle we
successfully handled the additional load by switching to a new weekly
release meeting format and having 1:1s PTL sync points before the actual
meeting, to concentrate meeting time on cross-project issues. I think it
worked well and I would like to continue under the same format for Juno.

On the stable branch team front, moving from 13-month to 11-month
support period helped in keeping stable branches sane, and Alan and Adam
kept issuing point releases on schedule.

On the vulnerability management front, we expanded the team with two new
OSSA coordinators and managed to keep on top of incoming issues. We also
started work to clarify which repositories were covered by security
support and have clear contact points in each program for security response.

If elected at this position for the Juno cycle I intend to continue
these efforts. On the release cycle management side we'll have a new
integrated project (Sahara) and I'll work on spreading the load of the
release management role a bit further (a goal internally codenamed
Project Vacation). We'll try to maintain stable branch support
timeframes at their current levels. We'll work on Vulnerability
Management Team tooling, so that security patches are easier to produce
and test, and OSSAs are easier to review and publish.

Thanks for your consideration !

-- 
Thierry Carrez (ttx)

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

[openstack-dev] [Mistral] Engine overview and proposal

2014-03-31 Thread Kirill Izotov

I have an idea regarding engine design i want to share with you. But first, it 
seems like we need a small overview of the current implementations.

I'm not sure how ML will react on a bunch of ASCII graphs, so here is an 
etherpad: https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal

What do you think, guys, is this the way to go? 

-- 
Kirill Izotov

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

[openstack-dev] [depfreeze] Updating Pbr dependency to version 0.8

2014-03-31 Thread Alessandro Pilotti

Due to an issue in Pbr 0.7 that prevents the installation of any Pbr based 
package on Windows and due to the recent availability
of Pbr 0.8 [1] which includes the fix for this issue, I suggest that we should 
upgrade the Pbr dependency in the global requirements [2]
or at least exclude version 0.7, since 0.6 works fine.

The patch with this change is available for review at [3].

Thanks,

Alessandro

[1] http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg20565.html
[2] 
https://github.com/openstack/requirements/blob/65a913ef036de59ad84a7fb369a5e6df93bb5ac0/global-requirements.txt#L61
[3] https://review.openstack.org/#/c/84030/





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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

On Mar 29, 2014, at 2:02 PM, Gary Duan 
garyd...@gmail.commailto:garyd...@gmail.com wrote:

I guess you need bind the port you just create.

PCM: Can you elaborate on what is needed for the binding?

In the call to create the port in Neutron, the script passes in an additional 
dict item for binding (n bold):

p_spec = {'port': {'admin_state_up': True,
   'name': port_name,
   'network_id': nw_id,
   'mac_address': mac_addr,
   'binding:host_id': hostname,
   'device_id': vm_uuid,
   'device_owner': 'compute:None'}}


Is there more action that is needed?


Also, the port need to be plugged into the VM, right? I don't see that in the 
code. Maybe you are doing it outside of OpenStack.

PCM: Not sure I understand how this all hooks up, as I’m still trying to figure 
out these scripts I acquired.  Essentially, the VM is started by KVM and 
scripts are associated with each of the interfaces. The scripts handle I/F up 
and make calls to Neutron (or Neutron/Nova) for hooking into Neutron. I guess 
it is hooked to the VM by the I/F up handling?

With the original setup, there were three scripts to hook up the three 
interfaces in the VM…

One uses br-ex and all Neutron calls. It connects the interface, I can ping on 
it and it shows up with an IP in Neutron port list (though port-show says it is 
down). The port is used by the VM to access the “public” network that devstack 
creates (e.g. 172.24.4.13, with Neutron router at 1712.24.4.11).

Another uses br-int and all Neutron calls too, for a management port of the VM. 
It too pings fine, and is used by a Neutron agent to send REST messages to the 
VM (e.g. 192.168.200.2). We also can telnet to that I/F from the host.

The third, uses br-int and originally used Neutron to create the port and Nova 
to plug the VIF. It would connect to the “private” network that devstack had 
created and gives the VM access to that private network. Neutron’s port-show 
would indicate the port is active, had an IP (10.1.0.6), and pinging worked 
fine.

It looks like, since two weeks ago, Nova changed to use an object for the VIF, 
instead of a dict and this code no longer works for this third script. I 
*thought* maybe I could use the same “all neutron” code for this interface too. 
I took the original script and replaced the plugging part with the same logic 
that the br-ex script used for plugging the VIF. IT doesn’t show an error, but 
the interface is reporting as down and (obviously) pings are not working.

I’m not sure if I’m missing some step on this third script or if I have to use 
Nova for this interface (not sure why the original scripts use Nova on this 
one).
Anyone have any thoughts on why Nova may be needed in this case ore what I’m 
missing?

Here is the full original script for the br-ex interface (works) (the 
management interface is the same with br-int vs be-ex set as the br_name) :

#!/usr/bin/python

import sys

from oslo.config import cfg
import neutron.openstack.common.gettextutils as gtutil
gtutil.install('')
import neutron.agent.linux.interface as vif_driver
from neutronclient.neutron import client as qclient
import neutronclient.common.exceptions as qcexp
from neutron.agent.common import config

# Arg 1: controller host
# Arg 2: name of admin user
# Arg 3: admin user password
# Arg 4: tenant name
# Arg 5: uuid of VM
# Arg 6: MAC address of tap interface
# Arg 7: name of tap interface

host = sys.argv[1]
user = sys.argv[2]
pw = sys.argv[3]
tenant = sys.argv[4]
vm_uuid = sys.argv[5]
mac_addr = sys.argv[6]
interface = sys.argv[7]

KEYSTONE_URL='http://' + host + ':5000/v2.0'

qc = qclient.Client('2.0', auth_url=KEYSTONE_URL, username=user,
tenant_name=tenant, password=pw)

prefix, net_name = interface.split('__')
port_name = net_name + '_p'
try:
nw_id = qc.list_networks(name=net_name)['networks'][0]['id']
except qcexp.NeutronClientException as e:
print  sys.stderr, e
print  sys.stderr, 'Number of arguments:', len(sys.argv), 'arguments.'
print  sys.stderr, 'Argument List:', str(sys.argv)
exit(1)

p_spec = {'port': {'admin_state_up': True,
   'name': port_name,
   'network_id': nw_id,
   'mac_address': mac_addr,
   'device_id': vm_uuid,
   'device_owner': 'compute:None'}}

try:
port = qc.create_port(p_spec)
except qcexp.NeutronClientException as e:
print  sys.stderr, e
exit(1)

port_id = port['port']['id']
br_name = 'br-ex'

conf = cfg.CONF
config.register_root_helper(conf)
conf.register_opts(vif_driver.OPTS)

driver = vif_driver.OVSInterfaceDriver(cfg.CONF)
driver.plug(nw_id, port_id, interface, mac_addr, br_name)

print br_name, port_name, port_id, net_name, nw_id


Here is the full original script for the br-int interface (no longer works):

#!/usr/bin/python

import socket
import sys

import nova.openstack.common.gettextutils as gtutil

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

Yeah I had noticed that change too… I’m guessing that, if I want to try to use 
the Nova call, that I’d want to set both the hybrid plug and port filter flags 
to false?

For my devstack setup, I have Neutron security groups disabled 
(Q_USE_SECGROUP=False), and I setup Nova to allow ICMP and SSH.

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Mar 30, 2014, at 5:01 AM, Irena Berezovsky 
ire...@mellanox.commailto:ire...@mellanox.com wrote:

Hi Paul,
Please be aware that there was also change in nova to support ovs_hybrid_plug:
https://review.openstack.org/#/c/83190/
I am not sure, but maybe worth to check nova code and nova.conf  you are using 
to be aligned with neutron code.

Hope it helps,
Irena


From: Paul Michali (pcm) [mailto:p...@cisco.com]
Sent: Saturday, March 29, 2014 1:17 AM
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

Hi,

I have a VM that I start up outside of OpenStack (as a short term solution, 
until we get it working inside a Nova VM), using KVM. It has scrips associated 
with the three interfaces that are created, to hook this VM into Neutron. One 
I/F is on br-ex (connected to the “public network for DevStack), another to 
br-int (connected to a management network that is created), and a third is 
connected to br-int (connected to the “private” network for DevStack). It’s 
understood these are hacks to get things going and can be brittle.  With 
DevStack, I have a vanilla localrc, so using ML2, without any ML2 settings 
specified.

Now, the first two scripts use internal Neutron client calls to create the 
port, and then plug the VIF. The third, uses Neutron to create the port, and 
then Nova to plug the VIF. I don’t know why - I inherited the scripts.

On one system, where Nova is based on commit b3e2e05 (10 days ago), this all 
works just peachy. Interfaces are hooked in and I can ping to my hearts 
content. On another system, that I just reimaged today, using the latest and 
greatest OpenStack projects, the third script fails.

I talked to Nova folks, and the vic is now an object, instead of a plain dict, 
and therefore calls on the object fail (as the script just provides a dict). I 
started trying to convert the vif to an object, but in discussing with a 
co-worker, we thought that we could too use Neutron calls for all of the setup 
of this third interface.

Well, I tried, and the port is created, but unlike the other system, the port 
is DOWN, and I cannot ping to or from it (the other ports still work fine, with 
this newer OpenStack repo). One difference is that the port is showing  
{port_filter: true, ovs_hybrid_plug: true} for binding:vif_details, in the 
neutron port-show output. On the older system this is empty (so must be new 
changes in Neutron?)


Here is the Neutron based code (trimmed) to do the create and plugging:

import neutron.agent.linux.interface as vif_driver
from neutronclient.neutron import client as qclient

qc = qclient.Client('2.0', auth_url=KEYSTONE_URL, username=user, 
tenant_name=tenant, password=pw)

prefix, net_name = interface.split('__')
port_name = net_name + '_p'
try:
nw_id = qc.list_networks(name=net_name)['networks'][0]['id']
except qcexp.NeutronClientException as e:
…

p_spec = {'port': {'admin_state_up': True,
   'name': port_name,
   'network_id': nw_id,
   'mac_address': mac_addr,
   'binding:host_id': hostname,
   'device_id': vm_uuid,
   'device_owner': 'compute:None'}}

try:
port = qc.create_port(p_spec)
except qcexp.NeutronClientException as e:
...

port_id = port['port']['id']
br_name = 'br-int'

conf = cfg.CONF
config.register_root_helper(conf)
conf.register_opts(vif_driver.OPTS)

driver = vif_driver.OVSInterfaceDriver(cfg.CONF)
driver.plug(nw_id, port_id, interface, mac_addr, br_name)

Finally, here are the questions (hope you stuck with the long message)…

Any idea why the neutron version is not working? I know there were a bunch of 
recent changes.
Is there a way for me to turn off the ova_hybrid_plug and port_filter flags? 
Should I?
Should I go back to using Nova and build a VIF object?
If so, any reason why the Neutron version would not work?
Is there a way to do a similar thing, but via using Northbound APIs (so it 
isn’t as brittle)?

Thanks in advance!

PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com/)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



___
OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

Hi Darragh,

Can you elaborate on what the “set interface” arguments do in OVS? Just trying 
to understand why it is not desired, when plugging into this interface (note I 
have a management interface on the br-int and it works fine…this one, which is 
also on br-int, but needs to tie to the existing “private” network that 
devstack sets up, does not work.

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Mar 31, 2014, at 4:20 AM, Darragh O'Reilly 
dara2002-openst...@yahoo.commailto:dara2002-openst...@yahoo.com wrote:

Hi Paul,

the OVSInterfaceDriver creates interfaces with type internal so agents like 
DHCP/L3 etc can put IP addresses on them. But I don't think type internal will 
work for instances. You could try subclassing and overriding so it does not do 
this:

 
https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150

Regards,
Darragh.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

2014-03-31 Thread Akihiro Motoki

According to the failure log, you seem to try to install 2012.2.4 (== Folsom).
I don't think this is the intended version you want to use. Please check it.

http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_917
2014-03-24 11:08:50.917 | Running setup.py install for horizon-2012.2.4

Thanks,
Akihiro

On Mon, Mar 31, 2014 at 6:05 PM, Timur Sufiev tsuf...@mirantis.com wrote:
Hello, Akihiro

[1]
http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
[2] https://review.openstack.org/#/c/68125/

http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz

Thanks,
Akihiro

Like you, we've built a dashboard atop of horizon, mostly because of
the existing keystone integration. Everything else we do is external
to OpenStack.

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger

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

--
Timur Sufiev

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

Re: [openstack-dev] Session suggestions for the Juno Design Summit now open

Thierry Carrez wrote:
 We have two *new* categories this time around:
 
 Cross-project workshops
 Those will be used to discuss topics which affect all OpenStack
 projects, and therefore increase convergence and collaboration across
 program barriers.
 
 Other projects
 Those will let unofficial, OpenStack-related, open source projects to
 have a design discussion within the Design Summit area. We'll limit this
 to one session per project to give room to as many projects as possible.
 
 You have until *April 20* to suggest sessions. Proposed session topics
 will be reviewed by PTLs afterwards, potentially merged with other
 suggestions before being scheduled.

In order to facilitate travel organization, we've been asked to confirm
which projects are accepted in the Other projects track ASAP. We'll
therefore have a slightly shorter deadline for that track to give
proposals a final answer before mid-April.

It's also useful for us to know which topics are covered in the
Cross-project workshops before we go and schedule the program-specific
categories, so we'll also have a shorter deadline for proposals on
cross-project workshops as well.

For both categories, please submit suggestions before *April 10* if you
want to be considered fairly. After that date, proposals may still be
considered if any slots are left, but most likely all the slots will
have been allocated.

Thanks,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [TripleO] [Horizon] Searching for a new name for Tuskar UI

2014-03-31 Thread Jaromir Coufal


On 2014/27/03 19:04, Jiří Stránský wrote:

On 27.3.2014 18:21, Dougal Matthews wrote:


[snip]


As a side, but related note, I think we should rename the Tuskar client
to whatever name the Tuskar UI gets called. The client will eventually
have feature parity with the UI and thus will have the same naming
issues if it is to remain the tuskarclient

Dougal


It might be good to do a similar thing as Keystone does. We could keep
python-tuskarclient focused only on Python bindings for Tuskar (but keep
whatever CLI we already implemented there, for backwards compatibility),
and implement CLI as a plugin to OpenStackClient. E.g. when you want to
access Keystone v3 API features (e.g. domains resource), then
python-keystoneclient provides only Python bindings, it no longer
provides CLI.

I think this is a nice approach because it allows the python-*client to
stay thin for including within Python apps, and there's a common
pluggable CLI for all projects (one top level command for the user). At
the same time it would solve our naming problems (tuskarclient would
stay, because it would be focused on Tuskar only) and we could reuse the
already implemented other OpenStackClient plugins for anything on
undercloud.

We previously raised that OpenStackClient has more plugins (subcommands)
that we need on undercloud and that could confuse users, but i'd say it
might not be as troublesome to justify avoiding the OpenStackClient way.
(Even if we decide that this is a big problem after all and OSC plugin
is not enough, we should still probably aim for separating TripleO CLI
and Tuskarclient in the future.)

Jirka


+1

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

Re: [openstack-dev] [Ceilometer] PTL Candidacy

2014-03-31 Thread Julien Danjou

On Sat, Mar 29 2014, Eoghan Glynn wrote:

 I would like to throw my hat into the ring for the upcoming ceilometer
 PTL election.

[…]

Thanks for your candidacy Eoghan, I really think you would be a great
PTL as you have been a really good, dare I say, deputy these last
months. :-) I'm sure you'll be up to the challenges of this next cycle!

As far as I'm concerned, I will not run for PTL this cycle. I've been in
charge of Ceilometer for a year now, and while I definitely plan to
continue working on it, I need more time behind the scene. :)

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


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo]: some functional tests for the olso.messaging API

I have recently been trying to get some API level functional tests for 
the olso.messaging library. The idea is that these tests could be run 
with any driver and configured 'backend' and would test the basic 
functional guarantees that the API makes.


I have an initial set of such tests now. The url use is set via an 
environment variable, so e.g.


TRANSPORT_URL=rabbit://127.0.0.1 python -m testtools.run 
functional_tests.test_functional.NotifyTests


would run the notify tests against a local rabbit broker on the standard 
port. If attached the tests here, but if there is interest in including 
these in the repo, I'll create a proper changeset for review and comments.


I've run these tests against the qpid and rabbit drivers as well as the 
new AMQP 1.0 based driver available for initial review[1]. For rabbit 
and qpid there is one failure, where the exchange specified in the 
target is ignored. I'll be running them against the 0mq driver also.


At present, against rabbit and qpid, the tests work only if each test is 
run in isolation. This is because there appears to be no way through the 
API to have subscriptions created by the driver to be dropped, short of 
killing the process[2].


There may be some step my tests aren't doing that would trigger proper 
cleanup. This may also not be that important to real world uses of the 
library(?) and is only a minor irritation from the testing pov. However 
if there is interest, and assuming it is indeed an issue and not just a 
misunderstanding on my part,I can try and get a patch up for review to 
address it.


Another slight annoyance from the testing pov is that the API provides 
no way of determining when a server is 'ready' i.e. when its 
subscriptions are in place. I had to work around this for qpid and 
rabbit with a short sleep, which is always a bit nasty.


The last issue to mention here is that stop() implementation doesn't 
signal the driver in any way. So to actually get it to stop, at least 
for the blocking executor, you have to send a dummy message after 
calling stop() in order to have the poll() on the listener return and 
allow the detection of the stop flag. This is easy enough to work around 
in the tests and is a lot less nasty than the sleep.


--Gordon.

[1] https://review.openstack.org/#/c/75815/

[2] The cleanup() impl for both drivers simply closes any free 
connections in the pool
#
#Licensed under the Apache License, Version 2.0 (the License); you may
#not use this file except in compliance with the License. You may obtain
#a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an AS IS BASIS, WITHOUT
#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#License for the specific language governing permissions and limitations
#under the License.

import fixtures
import os
import random
import threading
import time

from oslo.config import cfg
from oslo import messaging
from oslo.messaging.notify import notifier
from six import moves
from tests import utils as test_utils
from testtools import matchers


class TestServer(object):
def __init__(self):
self.ival = 0
self.sval = ''

def add(self, ctxt, increment):
self.ival += increment
return self.ival

def subtract(self, ctxt, increment):
if self.ival  increment:
raise ValueError(ival can't go negative!)
self.ival -= increment
return self.ival

def append(self, ctxt, text):
self.sval += text
return self.sval


class TransportFixture(fixtures.Fixture):
def __init__(self, url):
self.url = url

def setUp(self):
super(TransportFixture, self).setUp()
self.transport = messaging.get_transport(cfg.CONF, url=self.url)

def cleanUp(self):
self.transport.cleanup()
super(TransportFixture, self).cleanUp()

def wait(self):
if self.url.startswith(rabbit)or self.url.startswith(qpid):
time.sleep(0.5)


class RpcServerFixture(fixtures.Fixture):
def __init__(self, transport, target, obj=None, ctrl_target=None):
super(RpcServerFixture, self).__init__()
self.transport = transport
self.target = target
self.instance = obj or TestServer()
self.syncq = moves.queue.Queue()
self.ctrl_target = ctrl_target or self.target

def setUp(self):
super(RpcServerFixture, self).setUp()
instances = [self.instance, self]
self.server = messaging.get_rpc_server(self.transport,
   self.target,
   instances)
self._ctrl = messaging.RPCClient(self.transport, self.ctrl_target)
self._start()

def cleanUp(self):
self._stop()
super(RpcServerFixture, self).cleanUp()

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

2014-03-31 Thread John Garbutt

On 31 March 2014 10:11, Jay Lau jay.lau@gmail.com wrote:
 Hi,

 Currently with VMWare VCDriver, one nova compute can manage multiple
 clusters/RPs, this caused cluster admin cannot do live migration between
 clusters/PRs if those clusters/PRs managed by one nova compute as the
 current live migration logic request at least two nova computes.

 A bug [1] was also filed to trace VMWare live migration issue.

 I'm now trying the following solution to see if it is acceptable for a fix,
 the fix wants enable live migration with one nova compute:
 1) When live migration check if host are same, check both host and node for
 the VM instance.
 2) When nova scheduler select destination for live migration, the live
 migration task should put (host, node) to attempted hosts.
 3) Nova scheduler needs to be enhanced to support ignored_nodes.
 4) nova compute need to be enhanced to check host and node when doing live
 migration.

 I also uploaded a WIP patch [2] for you to review the idea of the fix and
 hope can get some comments from you.

 [1] https://bugs.launchpad.net/nova/+bug/1192192
 [2] https://review.openstack.org/#/c/84085

Long term, finding a way to unify how cells and the VMware driver
manages multiple hosts, seems like the best way forward. It would be a
shame for this API to be different between cells and VMware, although
right now, that might not work too well :(

A better short term fix, might be to allow you to specify the same
host as the instance, and the scheduling of the node could be
delegated to the VMware driver, which might just delegate that to
vCenter. I assume we still need some way to specify the node, and I
can't immediately think of a good way forward.

I feel this should really be treated as a blueprint, and go through
the new blueprint review process. That should help decide the right
approach to take.

John

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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly

Hi Paul,

tbh I'm not exactly sure what you are trying to do overall. But from your
script it seems to me that you are trying to create an OVS port so a libvirt
instance outside of Nova control can use it. And you don't need the linux
bridge for security group iptables.

AFAIK the tap must be created first using the ip command. Then when 'ovs-vsctl
add-port' is called with the same name as the tap device for the port name, the
tap device will be enslaved properly in the OVS bridge.

https://github.com/openstack/nova/blob/304df046eaaad6d64ee16898b1eaa76918e98878/nova/virt/libvirt/vif.py#L420-L423

Regards, Darragh.

On Monday, 31 March 2014, 12:36, Paul Michali (pcm) p...@cisco.com wrote:

Hi Darragh,

Can you elaborate on what the “set interface” arguments do in OVS? Just trying
to understand why it is not desired, when plugging into this interface (note I
have a management interface on the br-int and it works fine…this one, which is
also on br-int, but needs to tie to the existing “private” network that
devstack sets up, does not work.

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83

On Mar 31, 2014, at 4:20 AM, Darragh O'Reilly dara2002-openst...@yahoo.com
wrote:

Hi Paul,

the OVSInterfaceDriver creates interfaces with type internal so agents like
DHCP/L3 etc can put IP addresses on them. But I don't think type internal
will work for instances. You could try subclassing and overriding so it does
not do this:

https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150

Regards,
Darragh.

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

[openstack-dev] [oslo] ordering of notification 'events' in oslo.messaging

I believe that ordering of notifications at different levels is not 
guaranteed when receiving those notifications using a notification 
listener in olso.messaging.


I.e. with something like:

notifier = notifier.Notifier(get_transport(CONF), 'compute')
notifier.info(ctxt, event_type, payload_1)
notifier.warn(ctxt, event_type, payload_2)

its possible that payload_1 is received after payload_2. The root cause 
is that a different queue is used for events of each level.


In practice this is easier to observe with rabbit than qpid, as the qpid 
driver send every message synchronously which reduces the likelihood of 
there being more than one message on the listeners queues from the same 
notifier. Even for rabbit it takes a couple of thousand events before it 
usually occurs. Load on either the receiving client or the broker could 
increase the likelihood of out of order deliveries.


Not sure if this is intended, but as it isn't immediately obvious, I 
thought it would be worth a note to the list.


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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

Hi Darragh,

Yes (I should included more background), I have a VM started in KVM, and it has 
I/Fs associated with scripts for I/F up and down:

IFNAME_ETH0=$NAME__mgmt
IFNAME_ETH1=$NAME__public
IFNAME_ETH2=$NAME__private

kvm -m 8192 -name $NAME \
-smp 4 \
-serial telnet:$TELNET_ACCESS,server,nowait \
-net nic,macaddr=$MACADDR_ETH0,model=e1000,vlan=0 \
-net 
tap,ifname=$IFNAME_ETH0,vlan=0,script=osn-ifup-mgmt,downscript=osn-ifdown-mgmt \
-net nic,macaddr=$MACADDR_ETH1,model=e1000,vlan=1 \
-net 
tap,ifname=$IFNAME_ETH1,vlan=1,script=osn-ifup-br-ex,downscript=osn-ifdown-br-ex
 \
-net nic,macaddr=$MACADDR_ETH2,model=e1000,vlan=2 \
-net 
tap,ifname=$IFNAME_ETH2,vlan=2,script=osn-ifup-br-int,downscript=osn-ifdown-br-int
 \
-drive file=$IMAGE \
-boot c \
-vga cirrus \
-vnc $VNC_ACCESS

ETH2, using osn-ifup-br-int, does this:

#!/bin/bash

source config.ini

/sbin/ifconfig $1 0.0.0.0 up
if_mac=`ifconfig $1 | awk '{ if ($4 == HWaddr) print $5 }'`
info_str=`./plug_vif.py ${HOST} ${USER} ${PASSWORD} ${TENANT} ${UUID} ${if_mac} 
${HOSTNAME} $1`
if [ $info_str ==  ]; then
   echo VIF plugging failed ($1)! Exiting ... 2
   exit 1
fi

# Write for file for later clean-up by osn-ifdown
echo $1 ${if_mac} ${UUID} $info_str  .instance_info

IFS=' ' read -a info  $info_str
switch=${info[0]}
echo Plugging interface: $1 into switch: ${switch}
ovs-vsctl add-port ${switch} $1

Note: T original that used Nova for the plugging of VIF used this for the last 
line, instead of ovs-vsctl:

brctl addif ${switch} $1


Regards,


PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Mar 31, 2014, at 9:26 AM, Darragh O'Reilly 
dara2002-openst...@yahoo.commailto:dara2002-openst...@yahoo.com wrote:

Hi Paul,

tbh I'm not exactly sure what you are trying to do overall. But from your 
script it seems to me that you are trying to create an OVS port so a libvirt 
instance outside of Nova control can use it. And you don't need the linux 
bridge for security group iptables.

AFAIK the tap must be created first using the ip command. Then when 'ovs-vsctl 
add-port' is called with the same name as the tap device for the port name, the 
tap device will be enslaved properly in the OVS bridge.

https://github.com/openstack/nova/blob/304df046eaaad6d64ee16898b1eaa76918e98878/nova/virt/libvirt/vif.py#L420-L423

Regards, Darragh.
On Monday, 31 March 2014, 12:36, Paul Michali (pcm) 
p...@cisco.commailto:p...@cisco.com wrote:
Hi Darragh,

Can you elaborate on what the “set interface” arguments do in OVS? Just trying 
to understand why it is not desired, when plugging into this interface (note I 
have a management interface on the br-int and it works fine…this one, which is 
also on br-int, but needs to tie to the existing “private” network that 
devstack sets up, does not work.

Regards,

PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com/)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Mar 31, 2014, at 4:20 AM, Darragh O'Reilly 
dara2002-openst...@yahoo.commailto:dara2002-openst...@yahoo.com wrote:

Hi Paul,

the OVSInterfaceDriver creates interfaces with type internal so agents like 
DHCP/L3 etc can put IP addresses on them. But I don't think type internal will 
work for instances. You could try subclassing and overriding so it does not do 
this:

 
https://github.com/openstack/neutron/blob/2541ff7cad19941b62dace7e9951a56a16e53f3e/neutron/agent/linux/interface.py#L150

Regards,
Darragh.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

Re: [openstack-dev] [RelMgt] PTL candidacy

2014-03-31 Thread Tristan Cacqueray

confirmed

n 03/31/2014 12:19 PM, Thierry Carrez wrote:
 Hi everyone,
 
 I'm writing to announce my candidacy for the Release management Program
 Technical Lead position.
 
 The Release management program is composed of 3 subteams.
 
 On the release cycle management front, during the Icehouse cycle we
 successfully handled the additional load by switching to a new weekly
 release meeting format and having 1:1s PTL sync points before the actual
 meeting, to concentrate meeting time on cross-project issues. I think it
 worked well and I would like to continue under the same format for Juno.
 
 On the stable branch team front, moving from 13-month to 11-month
 support period helped in keeping stable branches sane, and Alan and Adam
 kept issuing point releases on schedule.
 
 On the vulnerability management front, we expanded the team with two new
 OSSA coordinators and managed to keep on top of incoming issues. We also
 started work to clarify which repositories were covered by security
 support and have clear contact points in each program for security response.
 
 If elected at this position for the Juno cycle I intend to continue
 these efforts. On the release cycle management side we'll have a new
 integrated project (Sahara) and I'll work on spreading the load of the
 release management role a bit further (a goal internally codenamed
 Project Vacation). We'll try to maintain stable branch support
 timeframes at their current levels. We'll work on Vulnerability
 Management Team tooling, so that security patches are easier to produce
 and test, and OSSAs are easier to review and publish.
 
 Thanks for your consideration !
 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel-dev] [Fuel] Issues about OSTF tests

2014-03-31 Thread Timur Nurlygayanov

Hi Fuel team,

I have a questions about the OSTF tests for next release 5.0.

In this release we plan to include Murano 0.5, which will have significant
architecture changes and it will require significant changes in OSTF tests
for Murano.
For example, we will not support all services, which Murano supports in the
last stable release (we have moved to another engine).


About the changes in OSTF tests for Murano:
1. We will remove all tests for not-supported services
2. We want to add some additional checks for OSTF tests, which will collect
information about OpenStack cluster configuration and will skip some tests,
if we have no required resources.

And now I have a question: how we can get the information about the
OpenStack cloud resources, like summary size of RAM on compute nodes? (I
know that we can use Nailgan API, but some working examples will be very
useful)

Thank you! :)

-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] ordering of notification 'events' in oslo.messaging

2014-03-31 Thread Sandy Walsh


On 03/31/2014 10:55 AM, Gordon Sim wrote:
 I believe that ordering of notifications at different levels is not
 guaranteed when receiving those notifications using a notification
 listener in olso.messaging.
 
 I.e. with something like:
 
 notifier = notifier.Notifier(get_transport(CONF), 'compute')
 notifier.info(ctxt, event_type, payload_1)
 notifier.warn(ctxt, event_type, payload_2)
 
 its possible that payload_1 is received after payload_2. The root cause
 is that a different queue is used for events of each level.
 
 In practice this is easier to observe with rabbit than qpid, as the qpid
 driver send every message synchronously which reduces the likelihood of
 there being more than one message on the listeners queues from the same
 notifier. Even for rabbit it takes a couple of thousand events before it
 usually occurs. Load on either the receiving client or the broker could
 increase the likelihood of out of order deliveries.
 
 Not sure if this is intended, but as it isn't immediately obvious, I
 thought it would be worth a note to the list.

If they're on different queues, the order they appear depends on the
consumer(s). It's not really an oslo.messaging issue.

You can do reproduce it with just two events:
warn.publish(Foo)
info.publish(Blah)
consume from info
consume from warn
info is out of order.

And, it's going to happen anyway if we get into a timeout and requeue()
scenario.

I think we have to assume that ordering cannot be guaranteed and it's
the consumers responsibility to handle it.

-S



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

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

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

I tinkered with the Nova create call and things are (sort of) working)…

I changed the plugging to do this:

port_id = port['port']['id']

instance = {'uuid': vm_uuid}
network = {'bridge': 'br-int'}

class VeryDangerousHack(network_model.VIF):
def __init__(self, port_id, mac_addr, network):
super(VeryDangerousHack, self).__init__(
id=port_id, address=mac_addr, network=network,
type=network_model.VIF_TYPE_OVS,
details={'ovs_hybrid_plug': False, 'port_filter': False},
active=True)

vif = VeryDangerousHack(port_id, mac_addr, network)

# For ML2 plugin
driver = vif_driver.LibvirtGenericVIFDriver({})
driver.plug(instance, vif)

It completed without errors, the interface is up, and I can ping over it. 
(Yay!) However, it still seems to show the hybrid plug and port filtering:

openstack@devstack-32:~/devstack$ neutron port-show private_p
+---+-+
| Field | Value 
  |
+---+-+
| admin_state_up| True  
  |
| allowed_address_pairs |   
  |
| binding:host_id   | devstack-32   
  |
| binding:profile   | {}
  |
| binding:vif_details   | {port_filter: true, ovs_hybrid_plug: true}
  |
| binding:vif_type  | ovs   
  |
| binding:vnic_type | normal
  |
| device_id | 999a76ef--2689-1234-b12a3c4d2a00  
  |
| device_owner  | compute:None  
  |
| extra_dhcp_opts   |   
  |
| fixed_ips | {subnet_id: 5255dd92-ebd6-43ea-aff8-46f97349eb99, 
ip_address: 10.1.0.6} |
| id| 267a9936-4bc2-4838-9c06-22d84309596f  
  |
| mac_address   | 42:0c:c9:cb:4e:9f 
  |
| name  | private_p 
  |
| network_id| df8305f2-9797-41ed-bd76-6f083575e0f7  
  |
| security_groups   | 365a63ea-149c-4ff9-9aa2-8bcfe9dfb7e3  
  |
| status| ACTIVE
  |
| tenant_id | 78fe6c3b72a64595aa7d3c6c25d58c51  
  |
+---++

Can anyone enlightened me on what these settings imply?

From the review Irena mentioned:
Neutron can include 'ovs_hybrid_plug' and 'port_filter' boolean keys in
the binding:vif_details port attribute. 'port_filter' indicates whether
or not neutron is handling port filtering for nova to determine if it needs
to filter for that port. 'ovs_hybrid_plug' can be set to True to indicate
that the neutron plugin still requires the bridge plugging strategy to attach
firewall rules.”


I have security groups disabled for Neutron and am using Nova (with ICMP and 
SSH allowed). Does that mean the port_filter is ignored?
Is the same true for the ovs_hybrid_plug, for the same reason?

Any idea why my settings for details are being ignored in the call?

I still have more checking, as the public_ip, although I can ping the local and 
remote Neutron routers (172.24.4.11 and 172.24.4.21), I cannot ping the far end 
VM that is running the same setup (outside of Nova, hooked into Neutron - 
though using the older versions and original scripts). May just be a setup 
issue.

Looking better though!

PCM (Paul Michali)

MAIL …..…. p...@cisco.commailto:p...@cisco.com
IRC ……..… pcm_ (irc.freenode.comhttp://irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



On Mar 31, 2014, at 9:56 AM, Paul Michali (pcm) 
p...@cisco.commailto:p...@cisco.com wrote:

Hi Darragh,

Yes (I should included more background), I have a VM started in KVM, and it has 
I/Fs associated with scripts for I/F up and down:

IFNAME_ETH0=$NAME__mgmt
IFNAME_ETH1=$NAME__public
IFNAME_ETH2=$NAME__private

kvm -m 8192 -name $NAME \
-smp 4 \
-serial telnet:$TELNET_ACCESS,server,nowait \
-net

[openstack-dev] [Designate] Atlanta Summit Design Session

2014-03-31 Thread Hayes, Graham

Hi All,

The design summit this year has allowed 'Other Projects' (ie non incubated 
projects) to book design sessions.

Is there any interest in trying to get a session in Atlanta?

If people are interested I can do an application for Designate.

Cheers,

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

Re: [openstack-dev] Operators Design Summit ideas for Atlanta

2014-03-31 Thread Jacki Bauer

Tom,
This is a great idea! Feel free to reach out to the user experience folks, as 
they’ll be interested both in attending and helping coordinate.

http://ask-openstackux.rhcloud.com/questions/
openstack-perso...@lists.openstack.orgmailto:openstack-perso...@lists.openstack.org

Best,
Jacki



On Mar 28, 2014, at 2:01 AM, Tom Fifield 
t...@openstack.orgmailto:t...@openstack.org wrote:

Thanks to those projects that responded. I've proposed sessions in swift, 
ceilometer, tripleO and horizon.

On 17/03/14 07:54, Tom Fifield wrote:
All,

Many times we've heard a desire for more feedback and interaction from
users. However, their attendance at design summit sessions is met with
varied success.

However, last summit, by happy accident, a swift session turned into a
something a lot more user driven. A competent user was able to describe
their use case, and the developers were able to stage a number of
question to them. In this way, some of the assumptions about the way
certain things were implemented, and the various priorities of future
plans became clearer. It worked really well ... perhaps this is
something we'd like to have happen for all the projects?

*Idea*: Add an ops session for each project in the design summit
https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions


Most operators running OpenStack tend to treat it more holistically than
those coding it. They are aware of, but don't necessarily think or work
in terms of project  breakdowns. To this end, I'd imagine the such
sessions would:

 * have a primary purpose for developers to ask the operators to answer
   questions, and request information

 * allow operators to tell the developers things (give feedback) as a
   secondary purpose that could potentially be covered better in a
   cross-project session

 * need good moderation, for example to push operator-to-operator
   discussion into forums with more time available (eg
   https://etherpad.openstack.org/p/ATL-ops-unconference-RFC )

 * be reinforced by having volunteer good users in potentially every
   design summit session
   (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions )


Anyway, just a strawman - please jump on the etherpad
(https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions)
or leave your replies here!


Regards,


Tom


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



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

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

[openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql

2014-03-31 Thread Chris Friesen



I mentioned this last week in another thread but I suspect it got lost.

I recently came across a situation where the code failed when running it 
under devstack but passed the unit tests.  It turns out that the unit 
tests regexp() behaves differently than the built-in one in mysql.


Down in db/sqlalchemy/api.py we end up calling

query = query.filter(column_attr.op(db_regexp_op)('None'))

When using mysql, it looks like a regexp comparison of the string 'None' 
against a NULL field fails to match.


Since sqlite doesn't have its own regexp function we provide one in 
openstack/common/db/sqlalchemy/session.py.  In the buggy case we end up 
calling it as regexp('None', None), where the types are unicode and 
NoneType.  However, we end up converting the second arg to text type 
before calling reg.search() on it, so it matches.


Having unit tests that don't behave like the real thing seems like a bad 
idea...


Chris

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

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql

2014-03-31 Thread Chris Friesen


On 03/31/2014 08:54 AM, Chris Friesen wrote:


I mentioned this last week in another thread but I suspect it got lost.


I forgot to mention...I've opened this as a bug 
(https://bugs.launchpad.net/nova/+bug/1298690) but I wanted to get some 
wider suggestions as to the proper way to deal with it.


Chris


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

[openstack-dev] [Trove] Instance Metadata

2014-03-31 Thread Daniel Salinas

I have completed the blueprint and specification for the proposed
instance metadata code that is up for review.  We can discuss the
blueprint either here or on the IRC channel.

Related links:
Blueprint: https://blueprints.launchpad.net/trove/+spec/trove-metadata
Specification: https://wiki.openstack.org/wiki/Trove-Instance-Metadata

Metadata Code Reviews:
Trove: https://review.openstack.org/#/c/82123/
TroveClient: https://review.openstack.org/#/c/82124/

Enjoy!

-DSal

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

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API

2014-03-31 Thread Doug Hellmann

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim g...@redhat.com wrote:

 I have recently been trying to get some API level functional tests for the
 olso.messaging library. The idea is that these tests could be run with any
 driver and configured 'backend' and would test the basic functional
 guarantees that the API makes.


This sounds like a good idea, thanks for tackling it!




 I have an initial set of such tests now. The url use is set via an
 environment variable, so e.g.

 TRANSPORT_URL=rabbit://127.0.0.1 python -m testtools.run
 functional_tests.test_functional.NotifyTests

 would run the notify tests against a local rabbit broker on the standard
 port. If attached the tests here, but if there is interest in including
 these in the repo, I'll create a proper changeset for review and comments.

 I've run these tests against the qpid and rabbit drivers as well as the
 new AMQP 1.0 based driver available for initial review[1]. For rabbit and
 qpid there is one failure, where the exchange specified in the target is
 ignored. I'll be running them against the 0mq driver also.

 At present, against rabbit and qpid, the tests work only if each test is
 run in isolation. This is because there appears to be no way through the
 API to have subscriptions created by the driver to be dropped, short of
 killing the process[2].


 There may be some step my tests aren't doing that would trigger proper
 cleanup. This may also not be that important to real world uses of the
 library(?) and is only a minor irritation from the testing pov. However if
 there is interest, and assuming it is indeed an issue and not just a
 misunderstanding on my part,I can try and get a patch up for review to
 address it.


I can see where that would be useful in some apps, so let's see if we can
make the API support it.

Another slight annoyance from the testing pov is that the API provides no
 way of determining when a server is 'ready' i.e. when its subscriptions are
 in place. I had to work around this for qpid and rabbit with a short sleep,
 which is always a bit nasty.


Are you saying that creating the subscription doesn't block until it is
ready?




 The last issue to mention here is that stop() implementation doesn't
 signal the driver in any way. So to actually get it to stop, at least for
 the blocking executor, you have to send a dummy message after calling
 stop() in order to have the poll() on the listener return and allow the
 detection of the stop flag. This is easy enough to work around in the tests
 and is a lot less nasty than the sleep.


That sounds like it would be useful, too, so apps can cleanly disconnect
from the broker.

Doug




 --Gordon.

 [1] https://review.openstack.org/#/c/75815/

 [2] The cleanup() impl for both drivers simply closes any free connections
 in the pool

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


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

[openstack-dev] [Heat] PTL Candidacy

2014-03-31 Thread Zane Bitter

Greetings, fellow Heatists. My name is not Steve and I would like to 
announce my candidacy for the position of Orchestration PTL.


Most of you, I hope, already know me. I've been working on Heat 
full-time essentially since the project started, and I've been a member 
of the core team since before that was a thing. I'm pretty familiar with 
both the Heat code and the strategic direction of the program. I've also 
regularly filled in for past PTLs in various capacities (e.g. on the 
Technical Committee, in project meetings, and chairing Heat team 
meetings), so I feel as prepared as one could for being an OpenStack PTL 
without actually having been one.


Heat has always been a project where the core team members make 
decisions by consensus, the PTL does *not* have the last word on any 
decision, and the role is rotated through the core team. I'd like to 
keep it that way. The term Program Technical Lead is a misnomer to me, 
because we expect leadership from everyone in the team, and especially 
the core team. (And, not incidentally, because the responsibilities of 
the PTL are not primarily technical.)


With the move to a directly-elected Technical Committee, I think it's 
time to revisit the role of the PTLs in OpenStack, and understanding 
that role from the inside will help me to give better input into that 
process. So the main change I want to make to the project is to make 
sure that the _next_ PTL has less work to do.


PTLs exist primarily to ensure that the program remains accountable to 
the wider OpenStack community, and I am happy to take on that 
accountability because I have complete faith in the core team.


If elected, it would be my intention to serve for only a single 
development cycle, as previous Heat PTLs have done. I think that has 
proven to be a successful model for building leadership depth, 
maintaining team culture, avoiding burnout and maintaining long-term 
productivity. I'd also like to encourage anyone thinking of running next 
time to consider bringing forward their plans and stepping up now, 
because choice is healthy :)


Finally, I'd like to take this opportunity to thank the Steves - Dake, 
Hardy and Baker - for all their hard work in this role over the past 
three release cycles. Great work guys!


cheers,
Zane.

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

Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live migration with one nova compute

Building on what John said, I'm a bit wary of introducing semantics into the 
Conductor's live migration code
that are VMWare-specific.  The conductor's live-migration code is supposed to 
be driver-agnostic.  IMHO, it
would be much better if we could handle this at a level where the code was 
already VMWare-specific.

Best Regards,
Solly Ross

- Original Message -
From: Jay Lau jay.lau@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, March 31, 2014 10:36:17 AM
Subject: Re: [openstack-dev] [OpenStack-Dev][Nova][VMWare] Enable live 
migration with one nova compute

Thanks John. Yes, I also think that this should be a bp as it is going to make 
some changes to enable live migration with only one nova compute, will file a 
blueprint later. 

For your proposal specify the same host as the instance, this can resolve the 
issue of live migration with target host, but what about the case of live 
migration without target host? If we still allow specify the same host as the 
instance, the the live migration will goes to dead loop. 

So it seems we definitely need to find a way to specify the node for live 
migration, hope someone else can show some light here. 

Of course, I will file bp and go through the new bp review process for this 
feature. 

Thanks! 


2014-03-31 21:02 GMT+08:00 John Garbutt  j...@johngarbutt.com  : 



On 31 March 2014 10:11, Jay Lau  jay.lau@gmail.com  wrote: 
 Hi, 
 
 Currently with VMWare VCDriver, one nova compute can manage multiple 
 clusters/RPs, this caused cluster admin cannot do live migration between 
 clusters/PRs if those clusters/PRs managed by one nova compute as the 
 current live migration logic request at least two nova computes. 
 
 A bug [1] was also filed to trace VMWare live migration issue. 
 
 I'm now trying the following solution to see if it is acceptable for a fix, 
 the fix wants enable live migration with one nova compute: 
 1) When live migration check if host are same, check both host and node for 
 the VM instance. 
 2) When nova scheduler select destination for live migration, the live 
 migration task should put (host, node) to attempted hosts. 
 3) Nova scheduler needs to be enhanced to support ignored_nodes. 
 4) nova compute need to be enhanced to check host and node when doing live 
 migration. 
 
 I also uploaded a WIP patch [2] for you to review the idea of the fix and 
 hope can get some comments from you. 
 
 [1] https://bugs.launchpad.net/nova/+bug/1192192 
 [2] https://review.openstack.org/#/c/84085 

Long term, finding a way to unify how cells and the VMware driver 
manages multiple hosts, seems like the best way forward. It would be a 
shame for this API to be different between cells and VMware, although 
right now, that might not work too well :( 

A better short term fix, might be to allow you to specify the same 
host as the instance, and the scheduling of the node could be 
delegated to the VMware driver, which might just delegate that to 
vCenter. I assume we still need some way to specify the node, and I 
can't immediately think of a good way forward. 

I feel this should really be treated as a blueprint, and go through 
the new blueprint review process. That should help decide the right 
approach to take. 

John 

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



-- 
Thanks, 

Jay 

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

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

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql

IMHO,Stringifying None and then expecting the *string* to match NULL is wrong.
Could we check to see if `filters[filter_name]` is None and deal with that case 
separately
(i.e `if filters[filter_name] is None:
  filter = column_is_null_check
  else:
  filter = column_attr.op(db_regexp_op)(
  str(filters[filter_name]))`)?

Best Regards,
Solly Ross

- Original Message -
From: Chris Friesen chris.frie...@windriver.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, March 31, 2014 10:57:04 AM
Subject: Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function 
doesn't behave like mysql

On 03/31/2014 08:54 AM, Chris Friesen wrote:

 I mentioned this last week in another thread but I suspect it got lost.

I forgot to mention...I've opened this as a bug 
(https://bugs.launchpad.net/nova/+bug/1298690) but I wanted to get some 
wider suggestions as to the proper way to deal with it.

Chris


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

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

[openstack-dev] [barbican] Meeting Monday March 31st at 20:00 UTC

2014-03-31 Thread Douglas Mendizabal

Hi Everyone,

The Barbican team is hosting our weekly meeting today, Monday March 24, at
20:00 UTC  in #openstack-meeting-alt

Meeting agenda is avaialbe here
https://wiki.openstack.org/wiki/Meetings/Barbican and everyone is welcomed
to add agenda items

You can check this link
http://time.is/0800PM_31_Mar_2014_in_UTC/CDT/EDT/PDT?Barbican_Weekly_Meeting
if you need to figure out what 20:00 UTC means in your time.

-Douglas Mendizabal




smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API


On 03/31/2014 04:11 PM, Doug Hellmann wrote:

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim g...@redhat.com
mailto:g...@redhat.com wrote:
Another slight annoyance from the testing pov is that the API
provides no way of determining when a server is 'ready' i.e. when
its subscriptions are in place. I had to work around this for qpid
and rabbit with a short sleep, which is always a bit nasty.


Are you saying that creating the subscription doesn't block until it is
ready?


With the blocking executor, if I call start() on the server returned by 
get_rpc_server(), then the start call blocks (until it detects stop has 
been called). It does look like this is just an issue for that executor 
though, since the eventlet executor will return after the listen has 
been issued.




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

Re: [openstack-dev] [oslo]: some functional tests for the olso.messaging API


On 03/31/2014 04:41 PM, Doug Hellmann wrote:




On Mon, Mar 31, 2014 at 11:36 AM, Gordon Sim g...@redhat.com
mailto:g...@redhat.com wrote:

On 03/31/2014 04:11 PM, Doug Hellmann wrote:

On Mon, Mar 31, 2014 at 8:54 AM, Gordon Sim g...@redhat.com
mailto:g...@redhat.com
mailto:g...@redhat.com mailto:g...@redhat.com wrote:
 Another slight annoyance from the testing pov is that the API
 provides no way of determining when a server is 'ready'
i.e. when
 its subscriptions are in place. I had to work around this
for qpid
 and rabbit with a short sleep, which is always a bit nasty.


Are you saying that creating the subscription doesn't block
until it is
ready?


With the blocking executor, if I call start() on the server returned
by get_rpc_server(), then the start call blocks (until it detects
stop has been called). It does look like this is just an issue for
that executor though, since the eventlet executor will return after
the listen has been issued.


That's how I would expect them to work. Is the eventlet executor not
ready then?


Yes, as I said (in a rather clumsy way), it is just an issue for the 
blocking executor.



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

[openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread David Kranz

I was reviewing some ironic changes that are more than a week old and do 
not have any reviews from the ironic team. Having at least one review 
from the ironic team would be very helpful.


 -David

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

Re: [openstack-dev] [nova] [bug] unit tests sqlite regexp() function doesn't behave like mysql

2014-03-31 Thread Chris Friesen


On 03/31/2014 09:24 AM, Solly Ross wrote:

IMHO,Stringifying None and then expecting the *string* to match NULL is wrong.
Could we check to see if `filters[filter_name]` is None and deal with that case 
separately
(i.e `if filters[filter_name] is None:
   filter = column_is_null_check
   else:
   filter = column_attr.op(db_regexp_op)(
   str(filters[filter_name]))`)?


I think we actually should do two separate things.

1) As you suggest, we should special-case testing for None.  I'm not 
sure that it should be in regex_filter(), it might make more sense to do 
it in instance_get_all_by_filters() and add a comment to regex_filter() 
that it doesn't match None.


2) The sqlite regexp() function should be modified to behave like mysql 
regexp() so that we don't trigger other mismatches in the future.


Chris

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

Re: [openstack-dev] Oslo PTL Candidacy

2014-03-31 Thread Tristan Cacqueray

confirmed

On 03/31/2014 05:37 PM, Doug Hellmann wrote:
 I am running for a second term as PTL for the OpenStack Common Libraries
 (Oslo) project.
 
 I have been programming in Python professionally for over 15 years, in a
 variety of application areas. I am currently a Senior Developer at
 DreamHost, on our DreamCompute OpenStack-based public cloud project.
 
 I started working on OpenStack just before the Folsom summit. I am a core
 reviewer and one of the founding members of the Ceilometer project, and a
 core reviewer for the requirements and unified command line interface
 projects. I am also on the stable release maintenance team and am part of
 the team working on the Python 3 transition. I have contributed to many of
 the OpenStack projects through code and reviews.
 
 I joined the Oslo team at the Folsom summit, and served as PTL during the
 Icehouse release cycle.
 
 Although overall I think Icehouse went well for Oslo when checked against
 our internal goals, we have heard from developers in other projects who are
 frustrated. Syncing fixes has become increasingly difficult, and some
 breaking changes were merged in the existing libraries and not caught until
 those libraries were released. The sync issue is a symptom of two
 underlying problems. Our rapid growth as a community has made it difficult
 to keep up with the number of new projects pulling changes from the
 incubator, making it harder for us to keep everyone up to date. Oslo's goal
 of providing a collaboration space has also been lost somewhat, and
 instead the program has started to be treated more as a team producing
 tools to be consumed by other projects. We have been working hard to adapt
 Oslo to the changing needs of the community, but to truly fix these issues
 we need to bring back the original collaborative intent of the program.
 
 During Icehouse we have worked with the infra team to develop the processes
 to release more of the incubated code as standalone libraries [1], and to
 set up the additional testing that will be needed to prevent the issues we
 had with libraries during Icehouse. I anticipate having a few final changes
 land soon after the Icehouse feature freeze lifts to clear the way for our
 Juno plans [2]. As we move more stable code out of the incubator and into
 libraries, it will mean fewer sync merges and better testing of Oslo code
 in devstack and unit test gate jobs. After these initial low level
 libraries are released, we will be able to release more incubated modules
 in future cycles.
 
 To return Oslo to being a collaborative project, I plan to adopt and
 formalize Joe Gordon's suggestion of having designated liaisons to
 coordinate changes from Oslo code with each project [3]. There are just too
 many other projects for the small Oslo team to be intimately familiar with,
 and contribute to, all of them directly. The liaisons will be responsible
 for helping merge changes into their project to move to the libraries being
 released. We will also need the liaisons to help us identify API
 incompatibilities between what is in the proposed library and the way
 projects are using the incubated modules now.
 
 In the days leading up to RC1, we have had several different items brought
 to our attention as critical blocking issues that had been going on for
 many weeks. None of these took what I would call a lot of time or effort to
 fix or work around, but because we were not aware of the issues or their
 impact, frustration built up in the teams affected by the issues. I hope
 that having designated liaisons will help us establish communication
 channels to identify, prioritize, and resolve these sorts of issues earlier.
 
 My commit history:
 https://review.openstack.org/#/q/owner:doug.hellmann%2540dreamhost.com,n,z
 
 My review history:
 https://review.openstack.org/#/q/reviewer:doug.hellmann%2540dreamhost.com,n,z
 
 I'm looking forward to continuing to work with everyone,
 Doug
 
 
 [1] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary
 [2] https://wiki.openstack.org/wiki/Oslo/JunoGraduationPlans
 [3] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [horizon] Cannot login to dashboard

2014-03-31 Thread Ben Nemec

Please ask usage questions on the non-development list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Thanks.

-Ben

On 03/30/2014 11:34 AM, Andrew Chul wrote:

Hello, guys, I'm new in Horizon. Can anybody tell me how can I login
to my local OpenStack dashboard?




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

[openstack-dev] [infra] Meeting Tuesday April 1st at 19:00 UTC

2014-03-31 Thread Elizabeth Krumbach Joseph

Hi everyone,

No joke, the OpenStack Infrastructure (Infra) team is hosting our
weekly meeting tomorrow, Tuesday April 1st, at 19:00 UTC in
#openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

[openstack-dev] [Ceilometer] [Horizon] Icehouse RC1 available

Hello everyone,

Ceilometer and Horizon just published their first Icehouse release
candidate. 38 bugs and bugs, respectively, were fixed in those projects
since feature freeze.

The RC1s are available for download at:
https://launchpad.net/ceilometer/icehouse/icehouse-rc1
https://launchpad.net/horizon/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, these RC1s will be formally released as the 2014.1
final version on April 17. You are therefore strongly encouraged to test
and validate these tarballs !

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/ceilometer/tree/milestone-proposed
https://github.com/openstack/horizon/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ceilometer/+filebug
https://bugs.launchpad.net/horizon/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Note that the master branches of Ceilometer and Horizon are now open
for Juno development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

[openstack-dev] PTL Candidacy

2014-03-31 Thread Michael Basnight

Howdy Trovesters and co,

I would like to announce that i will _not_ be running for the Trove PTL
this cycle. We have some smart peoples who can step up and keep the
momentum going.

Its been a wild ride going into integration, and I feel like its someone
else's turn to have the fun that I have had over the last 6mo (and before
when Trove was a wee little RedDwarf). Thanks to the other PTLs for helping
me shape my PTL role into something tangible. And of course a special shout
out to ttx for helping to keep me focused :) I will be still be working on
Trove full time.

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

[openstack-dev] Barbican PTL Candidacy

2014-03-31 Thread Jarret Raim

I'd like to throw my name in for PTL for the Key Management Program which
includes the Barbican, python-barbicanclient and Kite projects.

I've been working on Barbican since the first line of code was committed
and was responsible for building the team and desire at Rackspace to start
the project. It is a confluence of ideas from my time as a security
consultant, internal security architect and OpenStack contributor. I
believe that Barbican is key to allowing other projects in OpenStack to
expose desired features in the encryption space while meeting requirements
from security or compliance conscious customers. Additionally, the team
that we build for Barbican (both inside and outside of Rackspace) tends to
draw security minded folks that contribute their time and expertise to the
community.

My goal for the Juno cycle is to move Barbican through the incubation
process while incorporating the Kite work done in Keystone and filling out
the next set of planned features. With the requirements for integration
being clarified now, I'm not sure we'll be ready for integration in the
Juno cycle, but we will certainly be tackling as many of those as possible.

In addition to the integration work, Barbican has several community and
feature goals:

Community:
* Continue to drive wider community adoption. We've had a great start with
folks from HP, Nebula, Red Hat and others, but we want to continue to
diversify the team.
* Adopt a new blueprint system using Gerrit similar to Nova
* Discuss the future of the oslo.crypto libraries with the Oslo team
* Continue to evangelize Barbican and OpenStack in various venues through
speaking and training engagements


Features:
* Asymmetric key generation and escrow support include support for
external CAs
* Land the Dogtag support patches from Red Hat
* Auditing and logging compliance requirements
* Land the preliminary work done for the Kite project





Thanks,
Jarret


smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [dev-env] Error setting up dev environment on Mac OS X (10.9.2)

2014-03-31 Thread Robert Nettleton

Hi All,

I’m trying to setup my dev environment on Mac OS X (10.9.2) with the latest 
Sahara code, using the following instructions:

http://docs.openstack.org/developer/sahara/devref/development.environment.html

When I run the “Create database Schema” step, I see the following error:


sqlalchemy.exc.OperationalError: (OperationalError) near DROP: syntax error 
u'ALTER TABLE job_executions DROP COLUMN java_opts' ()
“

Has anyone seen this problem?  If so, is there a workaround or setup step that 
I’m missing?  

In a separate thread, Sergey mentioned that “gnu-getups” was required on Mac OS 
X for the dev env.  I’ve installed this package, but it does not resolve my 
problem. 

thanks,
Bob
-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Kurt Griffiths

Hi folks, has there been any discussion on using oslo.cache within the 
auth_token middleware to allow for using other cache backends besides 
memcached? I didn’t find a Keystone blueprint for it, and was considering 
registering one for Juno if the team thinks this feature makes sense. I’d be 
happy to put some time into the implementation.

Kurt G. | @kgriffs
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

2014-03-31 Thread Darragh O'Reilly



ok, good to hear you are making progress. From the variable names in the script 
- ifname=$IFNAME_ETH2,vlan=2 - it sounds like this is a Neutron provider 
network. If so, then it should be possible to bridge the VM to the link with 
with a simple Linux bridge, without the need for a Neutron port and OVS/br-int.


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

Re: [openstack-dev] [marconi] Performance numbers

2014-03-31 Thread Malini Kamalambal

Hello Tomasz,

We have been pulled into some other priorities the past week  haven't got a 
chance yet to run a new benchmark.
I hope to get to it later this week.

Meanwhile if you are interested in deploying Marconi/running the benchmarks 
yourself, please let me know.
We can point you to the benchmark scripts etc.

Thanks!
 Malini

From: Tomasz Janczuk tom...@janczuk.orgmailto:tom...@janczuk.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, March 25, 2014 4:06 PM
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [marconi] Performance numbers


Hello,


I wonder if any performance measurements have been done with Marconi? Are there 
results available somewhere?


I am generally trying to set my expectations in terms of latency and throughput 
as a function of the size of the deployment, number of queues, number of 
producers/consumers, type of backend, size of backend cluster, guarantees, 
message size etc. Trying to understand how Marconi would do in a large 
multi-tenant deployment.


Any and all data points would be helpful.


Thanks,

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

Re: [openstack-dev] [dev-env] Error setting up dev environment on Mac OS X (10.9.2)

2014-03-31 Thread Andrew Lazarev

Hi Bob,

The error is because of https://bugs.launchpad.net/sahara/+bug/1283133. Fix
is ready, but not merged to master because of FF (
https://review.openstack.org/#/c/75456/). As a workaround I could suggest
temporarily removing DROP queries in migration script #3. Or use other sql
db (e.g. mysql).

Thanks,
Andrew


On Mon, Mar 31, 2014 at 9:18 AM, Robert Nettleton 
rnettle...@hortonworks.com wrote:

 Hi All,

 I'm trying to setup my dev environment on Mac OS X (10.9.2) with the
 latest Sahara code, using the following instructions:


 http://docs.openstack.org/developer/sahara/devref/development.environment.html

 When I run the Create database Schema step, I see the following error:

 
 sqlalchemy.exc.OperationalError: (OperationalError) near DROP: syntax
 error u'ALTER TABLE job_executions DROP COLUMN java_opts' ()
 

 Has anyone seen this problem?  If so, is there a workaround or setup step
 that I'm missing?

 In a separate thread, Sergey mentioned that gnu-getups was required on
 Mac OS X for the dev env.  I've installed this package, but it does not
 resolve my problem.

 thanks,
 Bob

 CONFIDENTIALITY NOTICE
 NOTICE: This message is intended for the use of the individual or entity
 to which it is addressed and may contain information that is confidential,
 privileged and exempt from disclosure under applicable law. If the reader
 of this message is not the intended recipient, you are hereby notified that
 any printing, copying, dissemination, distribution, disclosure or
 forwarding of this communication is strictly prohibited. If you have
 received this communication in error, please contact the sender immediately
 and delete it from your system. Thank You.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Designate] Atlanta Summit Design Session

2014-03-31 Thread Betsy Luzader

Graham,

I'm definitely interested in a design session. Thanks for offering to put
in the application.

FYI, most of us from Rackspace get in late morning on Monday and are
leaving early afternoon on Friday.

Thanks again,

Betsy

On 3/31/14 9:46 AM, Hayes, Graham graham.ha...@hp.com wrote:

Hi All,

The design summit this year has allowed 'Other Projects' (ie non
incubated projects) to book design sessions.

Is there any interest in trying to get a session in Atlanta?

If people are interested I can do an application for Designate.

Cheers,

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


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

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Doug Hellmann

On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths 
kurt.griffi...@rackspace.com wrote:

  Hi folks, has there been any discussion on using oslo.cache within the
 auth_token middleware to allow for using other cache backends besides
 memcached? I didn't find a Keystone blueprint for it, and was considering
 registering one for Juno if the team thinks this feature makes sense. I'd
 be happy to put some time into the implementation.


That does make sense. We need to look at the dependency graph between the
keystoneclient and oslo.cache, though. It appears the current version of
oslo.cache is going to bring in quite a few oslo libraries that we would
not want keystoneclient to depend on [1]. Moving the middleware to a
separate library would solve that.

[1] https://wiki.openstack.org/wiki/Oslo/Dependencies

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

Re: [openstack-dev] [horizon] horizon PyPi distribution missing

2014-03-31 Thread Timur Sufiev

Thank you,

that was the actual cause of the error. I got the wrong year, my fault.

On Mon, Mar 31, 2014 at 3:55 PM, Akihiro Motoki amot...@gmail.com wrote:
According to the failure log, you seem to try to install 2012.2.4 (== Folsom).
I don't think this is the intended version you want to use. Please check it.

http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_917
2014-03-24 11:08:50.917 | Running setup.py install for horizon-2012.2.4

Thanks,
Akihiro

On Mon, Mar 31, 2014 at 6:05 PM, Timur Sufiev tsuf...@mirantis.com wrote:
Hello, Akihiro

[1]
http://logs.openstack.org/25/68125/16/check/gate-murano-dashboard-python26/8ebc940/console.html.gz#_2014-03-24_11_08_50_923
[2] https://review.openstack.org/#/c/68125/

http://tarballs.openstack.org/horizon/horizon-2014.1.b3.tar.gz

Thanks,
Akihiro

Like you, we've built a dashboard atop of horizon, mostly because of
the existing keystone integration. Everything else we do is external
to OpenStack.

--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter:
https://twitter.com/pabelanger

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

--
Timur Sufiev

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

--
Timur Sufiev

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

[openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Michał Dubiel

Hi All,

I have prepared commits I would like to have it reviewed and eventually
merged that add initial, limited support for FreeBSD as a host to nova. It
includes basic networking via freebsd_net driver (similar to the linux_net)
and few addons to libvirt compute driver in order to support the bhyve
hypervisor. Intent for those commits is let other play with openstack on
FreeBSD and to provide a code base for further development, as the current
version comes with many limitations like:

- Only FreeBSD guest OSes can be used
- No support for the config drive
- Only one disk and one Ethernet interface
- No pause/resume functionality
- No VM migration support
- No files injection to VMs filesystem
- Only works with bridged networking using nova-network with Flat/FlatDHCP
multi-host mode

Unit test are included, however, for all that to work on a real system you
have to use a slightly patched version of libvirt as not all features has
been merged to the official repository yet. My question is if that is
applicable to be merged at all, or should I wait for all necessary stuff to
be in libvirt official repository at first? I want also mention that there
is an active work underway in libvirt community to have all them
implemented and included in the libvirt code.

Regards,
Michal
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Mistral] Community meeting minutes - 03/31/2014

2014-03-31 Thread Renat Akhmerov

Thanks for joining IRC meeting today at #openstack-meeting channel.

As usually,

Minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.html
Full log: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-03-31-16.00.log.html

Looking forward to see you again in one week.

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Dolph Mathews

dogpile.cache would be substantially lighter on the client-side as it only
has a hard dependency on dogpile.core. It supports plenty of backends
beyond memcached and we already use it in keystone quite heavily.

  http://dogpilecache.readthedocs.org/en/latest/


On Mon, Mar 31, 2014 at 11:35 AM, Doug Hellmann doug.hellm...@dreamhost.com
 wrote:




 On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths 
 kurt.griffi...@rackspace.com wrote:

  Hi folks, has there been any discussion on using oslo.cache within the
 auth_token middleware to allow for using other cache backends besides
 memcached? I didn’t find a Keystone blueprint for it, and was considering
 registering one for Juno if the team thinks this feature makes sense. I’d
 be happy to put some time into the implementation.


 That does make sense. We need to look at the dependency graph between the
 keystoneclient and oslo.cache, though. It appears the current version of
 oslo.cache is going to bring in quite a few oslo libraries that we would
 not want keystoneclient to depend on [1]. Moving the middleware to a
 separate library would solve that.

 [1] https://wiki.openstack.org/wiki/Oslo/Dependencies

 Doug


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


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

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Aryeh Friedman

How do you handle the fact that as it stands bhyve can only run *nix like
OS's (specifically FreeBSD and Linux only)?   The long term answer seems to
be a working kqemu or use something like PetiteCloud (
http://www.petitecloud.org) as a bridge (run OS nested on bhyve under PC)


On Mon, Mar 31, 2014 at 1:01 PM, Michał Dubiel m...@semihalf.com wrote:

 Hi All,

 I have prepared commits I would like to have it reviewed and eventually
 merged that add initial, limited support for FreeBSD as a host to nova. It
 includes basic networking via freebsd_net driver (similar to the linux_net)
 and few addons to libvirt compute driver in order to support the bhyve
 hypervisor. Intent for those commits is let other play with openstack on
 FreeBSD and to provide a code base for further development, as the current
 version comes with many limitations like:

 - Only FreeBSD guest OSes can be used
 - No support for the config drive
 - Only one disk and one Ethernet interface
 - No pause/resume functionality
 - No VM migration support
 - No files injection to VMs filesystem
 - Only works with bridged networking using nova-network with Flat/FlatDHCP
 multi-host mode

 Unit test are included, however, for all that to work on a real system you
 have to use a slightly patched version of libvirt as not all features has
 been merged to the official repository yet. My question is if that is
 applicable to be merged at all, or should I wait for all necessary stuff to
 be in libvirt official repository at first? I want also mention that there
 is an active work underway in libvirt community to have all them
 implemented and included in the libvirt code.

 Regards,
 Michal

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




-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Russell Bryant

On 03/31/2014 01:01 PM, Michał Dubiel wrote:
 Hi All,
 
 I have prepared commits I would like to have it reviewed and eventually
 merged that add initial, limited support for FreeBSD as a host to nova.
 It includes basic networking via freebsd_net driver (similar to the
 linux_net) and few addons to libvirt compute driver in order to support
 the bhyve hypervisor. Intent for those commits is let other play with
 openstack on FreeBSD and to provide a code base for further development,
 as the current version comes with many limitations like:
 
 - Only FreeBSD guest OSes can be used
 - No support for the config drive
 - Only one disk and one Ethernet interface
 - No pause/resume functionality
 - No VM migration support
 - No files injection to VMs filesystem
 - Only works with bridged networking using nova-network with
 Flat/FlatDHCP multi-host mode
 
 Unit test are included, however, for all that to work on a real system
 you have to use a slightly patched version of libvirt as not all
 features has been merged to the official repository yet. My question is
 if that is applicable to be merged at all, or should I wait for all
 necessary stuff to be in libvirt official repository at first? I want
 also mention that there is an active work underway in libvirt community
 to have all them implemented and included in the libvirt code.

The limitations you mention are pretty severe, so I'm not sure this
sounds like something we would want to include in that state.

If the gaps were closed, the biggest blocker to considering it for
merging would be a CI platform that's running Nova in this setup against
every patch.  We require that for all hypervisor drivers now.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan

-- 
Russell Bryant

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

Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt

2014-03-31 Thread Roman Bogorodskiy

  Michał Dubiel wrote:

 Hi All,
 
 I have prepared commits I would like to have it reviewed and eventually
 merged that add initial, limited support for FreeBSD as a host to nova. It
 includes basic networking via freebsd_net driver (similar to the linux_net)
 and few addons to libvirt compute driver in order to support the bhyve
 hypervisor. Intent for those commits is let other play with openstack on
 FreeBSD and to provide a code base for further development, as the current
 version comes with many limitations like:
 
 - Only FreeBSD guest OSes can be used
 - No support for the config drive
 - Only one disk and one Ethernet interface
 - No pause/resume functionality
 - No VM migration support
 - No files injection to VMs filesystem
 - Only works with bridged networking using nova-network with Flat/FlatDHCP
 multi-host mode
 
 Unit test are included, however, for all that to work on a real system you
 have to use a slightly patched version of libvirt as not all features has
 been merged to the official repository yet. My question is if that is
 applicable to be merged at all, or should I wait for all necessary stuff to
 be in libvirt official repository at first? I want also mention that there
 is an active work underway in libvirt community to have all them
 implemented and included in the libvirt code.

Hi Michal,

I'd say it would be good to revive the old blueprint about bhyve
support and push the patches. Also, probably freebsd_net itself
deserve a blueprint on its own. And I guess it could be tested
independently of bhyve driver because as you might now qemu driver is
also supported on FreeBSD.

As for the bhyve, I think it's ok to push it now and mark it WIP for
example. I'd think it's not a small piece of code and will take some
time to review anyway.

But I think it cannot be merged until libvirt supports all the required
features (otherwise it'd be troublesome to setup gate jobs for bhyve for
I think).

As for the modifications to libvirt, unfortunately, they'll not get it
into the upcoming 1.2.3 as the freeze started already.

Roman Bogorodskiy


pgptY0LlVscTq.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican PTL Candidacy

confirmed

On 03/31/2014 12:18 PM, Jarret Raim wrote:
 I'd like to throw my name in for PTL for the Key Management Program which
 includes the Barbican, python-barbicanclient and Kite projects.
 
 I've been working on Barbican since the first line of code was committed
 and was responsible for building the team and desire at Rackspace to start
 the project. It is a confluence of ideas from my time as a security
 consultant, internal security architect and OpenStack contributor. I
 believe that Barbican is key to allowing other projects in OpenStack to
 expose desired features in the encryption space while meeting requirements
 from security or compliance conscious customers. Additionally, the team
 that we build for Barbican (both inside and outside of Rackspace) tends to
 draw security minded folks that contribute their time and expertise to the
 community.
 
 My goal for the Juno cycle is to move Barbican through the incubation
 process while incorporating the Kite work done in Keystone and filling out
 the next set of planned features. With the requirements for integration
 being clarified now, I'm not sure we'll be ready for integration in the
 Juno cycle, but we will certainly be tackling as many of those as possible.
 
 In addition to the integration work, Barbican has several community and
 feature goals:
 
 Community:
 * Continue to drive wider community adoption. We've had a great start with
 folks from HP, Nebula, Red Hat and others, but we want to continue to
 diversify the team.
 * Adopt a new blueprint system using Gerrit similar to Nova
 * Discuss the future of the oslo.crypto libraries with the Oslo team
 * Continue to evangelize Barbican and OpenStack in various venues through
 speaking and training engagements
 
 
 Features:
 * Asymmetric key generation and escrow support include support for
 external CAs
 * Land the Dogtag support patches from Red Hat
 * Auditing and logging compliance requirements
 * Land the preliminary work done for the Kite project
 
 
 
 
 
 Thanks,
 Jarret
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

[openstack-dev] Decorator behavior

2014-03-31 Thread John S Warren

At run time there are decorators that behave in an unexpected manner.
For instance, in nova/compute/manager.py when ComputeManager's
resize_instance method is called, the migration positional argument
is somehow added to kwargs (paired with the migration key) and is
stripped out of the args parameters when the decorators are called.
However, when this same method is called in
nova/tests/compute/test_compute_mgr.py, the migration positional
argument remains in args when the decorators are called.  In other
words at run time the decorators see these arguments:

(self, context, [], {'migration': migration, 'image': image,
'instance': instance, 'reservations': reservations})

while when running a test case, they see these arguments:

(self, context, [instance, image, reservations, migration,
instance_type], {})


What is happening at run time to cause this behavior?  How can this
behavior be duplicated when executing test cases, so that the test
cases correctly mimic run-time behavior?___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Barbican PTL Candidacy

On 03/31/2014 12:18 PM, Jarret Raim wrote:
 I'd like to throw my name in for PTL for the Key Management Program which
 includes the Barbican, python-barbicanclient and Kite projects.
Also please note for the purposes of elections the only repositories
eligible for consideration are the repositories listed in:
http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml

 
 I've been working on Barbican since the first line of code was committed
 and was responsible for building the team and desire at Rackspace to start
 the project. It is a confluence of ideas from my time as a security
 consultant, internal security architect and OpenStack contributor. I
 believe that Barbican is key to allowing other projects in OpenStack to
 expose desired features in the encryption space while meeting requirements
 from security or compliance conscious customers. Additionally, the team
 that we build for Barbican (both inside and outside of Rackspace) tends to
 draw security minded folks that contribute their time and expertise to the
 community.
 
 My goal for the Juno cycle is to move Barbican through the incubation
 process while incorporating the Kite work done in Keystone and filling out
 the next set of planned features. With the requirements for integration
 being clarified now, I'm not sure we'll be ready for integration in the
 Juno cycle, but we will certainly be tackling as many of those as possible.
 
 In addition to the integration work, Barbican has several community and
 feature goals:
 
 Community:
 * Continue to drive wider community adoption. We've had a great start with
 folks from HP, Nebula, Red Hat and others, but we want to continue to
 diversify the team.
 * Adopt a new blueprint system using Gerrit similar to Nova
 * Discuss the future of the oslo.crypto libraries with the Oslo team
 * Continue to evangelize Barbican and OpenStack in various venues through
 speaking and training engagements
 
 
 Features:
 * Asymmetric key generation and escrow support include support for
 external CAs
 * Land the Dogtag support patches from Red Hat
 * Auditing and logging compliance requirements
 * Land the preliminary work done for the Kite project
 
 
 
 
 
 Thanks,
 Jarret
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [nova] avahi-autoipd vs. nova networking (cloud-init)

2014-03-31 Thread Lars Kellogg-Stedman

On Sat, Mar 29, 2014 at 11:53:13AM -0400, Mike Spreitzer wrote:
 I run into trouble in Ubuntu VMs when avahi-autoipd is installed. 
 After avahi-autoipd is installed, there is an extra route (number 2 in the 
 [...]
 Of course, avahi-autoipd thinks it is doing me a favor.  Nova thinks it is 
 doing me harm.  Which is right, and how do we achieve harmony?

Why are you installing avahi-autoipd in your cloud instance?  The
autoipd tool is used for configuring network interfaces in the absence
of either a static configuration or a functioning dhcp
environment...and because you're running in a cloud environment,
you're pretty much guaranteed the latter.

If you really want zeroconf networking to be functional inside your
instances while at the same time maintaining access to the OpenStack
metadata service, you could add an explicit route to the metadata
address via your default gateway.  For example, given:

# ip route
default via 10.0.0.1 dev eth0  metric 100 
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.4 
169.254.0.0/16 dev eth0  scope link  metric 1000 

I would add:

  ip route add 169.254.169.254 via 10.0.0.1

And this restores access to the metadata service.  This forces the
kernel to pass traffic to 169.254.169.254 to the gateway, rather than
assuming it's accessible via a local network.

-- 
Lars Kellogg-Stedman l...@redhat.com | larsks @ irc
Cloud Engineering / OpenStack  |  @ twitter



pgpjmNHTFPbOK.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Decorator behavior

2014-03-31 Thread Dan Smith

 At run time there are decorators that behave in an unexpected manner.
 For instance, in nova/compute/manager.py when ComputeManager's
 resize_instance method is called, the migration positional argument
 is somehow added to kwargs (paired with the migration key) and is
 stripped out of the args parameters when the decorators are called.
 However, when this same method is called in
 nova/tests/compute/test_compute_mgr.py, the migration positional
 argument remains in args when the decorators are called.  In other
 words at run time the decorators see these arguments:
 
 (self, context, [], {'migration': migration, 'image': image,
 'instance': instance, 'reservations': reservations})
 
 while when running a test case, they see these arguments:
 
 (self, context, [instance, image, reservations, migration,
 instance_type], {})

All RPC-called methods get called with all of their arguments as keyword
arguments. I think this explains the runtime behavior you're seeing.
Tests tend to differ in this regard because test writers are human and
call the methods in the way they normally expect, passing positional
arguments when appropriate.

--Dan


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

Re: [openstack-dev] [Neutron] PTL Candidacy

confirmed

On 03/31/2014 01:04 PM, Kyle Mestery wrote:
 Hi everyone,
 
 I have decided to run for the OpenStack Networking (Neutron) PTL position.
 
 Why I Want To Be Neutron PTL
 -
 I want to be Neutron PTL because I wish to continue pushing Neutron forward
 and help it evolve, and have the skills necessary to do it. I've worked in 
 Open
 Source for many years, having contributed to projects such as Open vSwitch,
 libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a great
 team of developers, both core and non-core contributors. Being able to help
 them all work productively together and push Neutron forward is something I
 not only want to do, but something I think I can be very effective at.
 
 Qualifications
 -
 I have been a core developer since the beginning of the Havana cycle. My
 main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
 which I've co-lead for the last year. I wrote the OpenDaylight ML2
 driver, as well
 as the devstack integration and Jenkins setup for OpenDaylight. I have also
 been leading a sub-team focused on Group Based Policy since the Icehouse
 Summit. As on Open vSwitch developer, my focus has been on improving
 Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
 Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
 from the OpenStack community to an audience in the upper Midwest. I've
 presented at the last few OpenStack Summits on Open Source SDN topics, as
 well as giving presentations on OpenStack at other Open Source conferences. I
 recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
 developers to interact with not only each other but also developers from
 OpenStack Neutron and OpenDaylight.
 
 Icehouse Accomplishments
 -
 This past cycle, my main focus was continuing to expand the ML2 sub-team and
 assist plugin developers who were porting their existing core plugins
 into ML2 or
 writing brand new ML2 drivers. I also formed and lead the Group Based Policy
 sub-team, which is now marching towards a Proof of Concept for the Juno Summit
  In addition, I've spent time with the OpenDaylight project to ensure that
 OpenDaylight integrates with OpenStack Neutron as an ML2 driver.
 
 Looking forward to Juno
 -
 If I am elected PTL, I'd like to focus on a few areas for Neutron. One 
 immediate
 area of improvement I'd like to do is around the blueprint process. I've been
 watching what Russell and the Nova team have been doing with setting up the
 Nova BP process to use gerrit, and I'd like to move Neutron in this
 direction as well.
 Formalizing this process a bit more will lead to less surprises for BP
 drafters, and
 will also ensure core reviewers know what they are signing up for as
 people propose
 features. I'd also like to work to expand our core reviewer team in
 the Juno cycle. As
 the project has grown, the existing core reviewers could use some assistance 
 by
 working to expand the team and spread the review load. Along these
 lines, I'd also
 like to empower the sub-teams in Neutron. The project has grown to a point 
 where
 empowering the various sub-teams to allow more effective decision
 making would be
 a good thing. I'd like to continue the focus on ensuring Neutron is a
 good citizen in
 the community by ensuring we squash bugs related to the gate. And
 finally, I want to
 work to ensure we have a scalable, production quality Open Source
 Neutron reference
 implementation in the Juno timeframe.
 
 In closing
 -
 OpenStack Neutron has taken a big step forward in the Icehouse cycle
 with regards to
 stability and testing. Ensuring we continue to enhance the development
 process will
 allow us to continue making strides in this area and allow Neutron to
 continue evolving
 in a positive direction.
 
 Thank you,
 Kyle
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] [nova] Feature about QEMU Assisted online-extend volume

2014-03-31 Thread Duncan Thomas

On 29 March 2014 02:49, Zhangleiqiang (Trump) zhangleiqi...@huawei.com wrote:
 Hi, Duncan:
 Thanks for your advice.

 About the summit session you mentioned, what things can I do for it 
 ?

If you (or a colleague who can speak on your behalf) is going to the
summit, then go to 'http://summit.openstack.org/' and click 'suggest
session'. Note that you will need somebody to present / discuss /
defend the proposal at the summit, it rarely goes well if the proposer
isn't present.

Having a detailed blueprint available before the summit also helps, in
this case it looks like that is covered.

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

Re: [openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread CôngTT

Thanks anh. Lúc chiều e cũng bookmark bài này rồi. E phải xem kỹ phần kiến
trúc trong neutron, phần network này vẫn chưa thông lắm anh ạ.

P/s: Anh gửi tài liệu OVS cho e và Long nhé.
On 1 Apr 2014 00:04, Kyle Mestery mest...@noironetworks.com wrote:

Hi everyone,

I have decided to run for the OpenStack Networking (Neutron) PTL position.

Why I Want To Be Neutron PTL
-
I want to be Neutron PTL because I wish to continue pushing Neutron forward
and help it evolve, and have the skills necessary to do it. I've worked in
Open
Source for many years, having contributed to projects such as Open vSwitch,
libvirt, and OpenDaylight, as well as OpenStack Neutron. Neutron has a
great
team of developers, both core and non-core contributors. Being able to help
them all work productively together and push Neutron forward is something I
not only want to do, but something I think I can be very effective at.

Qualifications
-
I have been a core developer since the beginning of the Havana cycle. My
main focus in Neutron has been around the Modular Layer 2 (ML2) sub-team,
which I've co-lead for the last year. I wrote the OpenDaylight ML2
driver, as well
as the devstack integration and Jenkins setup for OpenDaylight. I have also
been leading a sub-team focused on Group Based Policy since the Icehouse
Summit. As on Open vSwitch developer, my focus has been on improving
Neutron's use of OVS, and enhancing OVS for use by Neutron. I founded the
Minnesota OpenStack Meetup in November of 2012, hosting numerous speakers
from the OpenStack community to an audience in the upper Midwest. I've
presented at the last few OpenStack Summits on Open Source SDN topics, as
well as giving presentations on OpenStack at other Open Source
conferences. I
recently co-hosted the first Open vSwitch Hackathon, which allowed core OVS
developers to interact with not only each other but also developers from
OpenStack Neutron and OpenDaylight.

Icehouse Accomplishments
-
This past cycle, my main focus was continuing to expand the ML2 sub-team
and
assist plugin developers who were porting their existing core plugins
into ML2 or
writing brand new ML2 drivers. I also formed and lead the Group Based
Policy
sub-team, which is now marching towards a Proof of Concept for the Juno
Summit
In addition, I've spent time with the OpenDaylight project to ensure that
OpenDaylight integrates with OpenStack Neutron as an ML2 driver.

Looking forward to Juno
-
If I am elected PTL, I'd like to focus on a few areas for Neutron. One
immediate
area of improvement I'd like to do is around the blueprint process. I've
been
watching what Russell and the Nova team have been doing with setting up the
Nova BP process to use gerrit, and I'd like to move Neutron in this
direction as well.
Formalizing this process a bit more will lead to less surprises for BP
drafters, and
will also ensure core reviewers know what they are signing up for as
people propose
features. I'd also like to work to expand our core reviewer team in
the Juno cycle. As
the project has grown, the existing core reviewers could use some
assistance by
working to expand the team and spread the review load. Along these
lines, I'd also
like to empower the sub-teams in Neutron. The project has grown to a point
where
empowering the various sub-teams to allow more effective decision
making would be
a good thing. I'd like to continue the focus on ensuring Neutron is a
good citizen in
the community by ensuring we squash bugs related to the gate. And
finally, I want to
work to ensure we have a scalable, production quality Open Source
Neutron reference
implementation in the Juno timeframe.

In closing
-
OpenStack Neutron has taken a big step forward in the Icehouse cycle
with regards to
stability and testing. Ensuring we continue to enhance the development
process will
allow us to continue making strides in this area and allow Neutron to
continue evolving
in a positive direction.

Thank you,
Kyle

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

[openstack-dev] [Neutron] Dynamic Routing Blueprint Updated

2014-03-31 Thread Artem Dmytrenko

Hi team.

The dynamic routing blueprint has been updated to reflect the feedback 
received during L3 subteam meetings over the last few weeks. The 
blueprint is registered here: 
https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing, and the 
full specification is available here: 
https://docs.google.com/a/midokura.com/document/d/1wUcgL6ZTqB14DsiNvGaA1Ao2Try5i5E7_VAzcavzTbY/edit.

Sincerely,
Artem Dmytrenko
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] PTL Candidacy

2014-03-31 Thread John Garbutt

Hi,

I would like to run for the OpenStack Compute (Nova) PTL position.

I find it really rewarding to help resolve conflict. Gallup says I am
a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
all sides of the story, learn about everyones point of view, help
frame the argument, and help come up with a resolution that works for
everyone. That is why the idea of being a PTL excites me.

Nova excites me because I love projects that integrate lots of
different components into a single cohesive user experience. (I see it
as one of the upsides of my Dyslexia.)

Should I get elected, Rackspace has promised that Nova PTL will be my
full time job.


My (OpenStack) life story...


My first involvement with Nova was in late 2010, working on what
became Citrix's Project Olympus private cloud packaging of OpenStack
and XenServer. We got Nova, Glance, Swift and XenServer all installed
and configured from a CD (or optional PXE) install.

After some changes in direction at Citrix, I started focusing on
XenServer and OpenStack integration, with a particular focus on Nova.
This lead me to form the XenAPI sub team, and help Russell with his
formalisation of the Nova Sub-Team concept.

In early 2013, I moved to Rackspace. That allowed me to focus more
attention on the rest of Nova. I am part of the dev team working on
(probably) the largest Nova installation in the world, Rackspace Cloud
Servers. I quickly joined nova-core, and then nova-drivers. Most
recently taking up the role of blueprint czar.

I feel I am in a better position than most to understand the breadth
of the Nova community, given my varied experience:
* moved from packaging OpenStack, then contributing code to Nova, now
helping more with the leadership of Nova
* worked on packaging OpenStack for private clouds (at Citrix)
* currently helping run (probably) the largest Nova deployment on the
planet, at Rackspace
* worked at a company whose strategy is more focused on its own
product, than the success of OpenStack (at Citrix). Note: I consider
this a perfectly valid situation. Without people concentrating on
non-OpenStack projects and products, Nova would have nothing to
orchestrate.


How I see the PTL role
--

The basics of the Project Team Lead (or Project Technical Lead) role
are covered here:
https://wiki.openstack.org/wiki/PTLguide

I feel that the role is really about fostering a vibrant community,
and ensuring decisions get made, not making the decisions. This
challenge really excites me, as in the past, I have had much fun, and
many successes, resolving conflicts between conflicting/competing
teams, helping them find a good resolution.

What I have found works is...
* Agree on a common set of user problems that need to be solved now
* ... and at the same time, gain a better understanding of where
people need/want to go in the future

That way, everyone starts to focus their efforts in the same direction.


What I would keep
-

In summary, I would keep most things. The Nova project is thriving.

The focus on cloud and not server virt should continue. That
doesn't mean we shouldn't work well at the small scale, we should work
well at both the large scale and the small scale. We should not stop
the work evolving the architecture of Nova and working out how to
evolve the API. Indeed, we also need to continue to improve how we
interface with Neutron, Glance, etc, etc.

We should also continue to avoid Nova scope creep, and continue to
reduce the scope of Nova where possible:
* split out nova-scheduler, to help cross project scheduling
* deprecate nova-network, or/and split it out of nova
* keep on the look out for other ideas

There are several people I would trust to be a good PTL for the next
cycle, which shows how much Russell has managed to scale out the
leadership in recent cycles. This drive to scale out the leadership of
Nova should continue.


But there are growing pains that need urgent attention...


What I would change
---

This is not about what we should build in Juno, it's how I'm thinking
the Nova community and Nova leadership should evolve during Juno:


1) Connecting developers with those using Nova

We are a very developer driven community. I would like to work with
deployers, packagers, and all users, to get their voices heard by the
Nova developer community.

The improved blueprint reviews and improved triaging of bugs are a
good start, but we need to continue to innovate here. Glance have
included a Product Manager, Brian Rosmaita, on their drivers team. I
am sure Nova would benefit from getting Product Managers, Operators,
and others, more involved in setting project priorities.

One idea: Agree on rough focus areas for each release. Focus areas are
a level of detail where everyone can engage, but with enough detail to
be useful in setting priorities of blueprints and bugs. Efforts that
match the focus areas can be given a higher

Re: [openstack-dev] [keystone] [oslo] Using oslo.cache in keystoneclient.middleware.auth_token

2014-03-31 Thread Morgan Fainberg

I’ve been working on (albeit slowly) getting the keystone implementation of 
dogpile.cache into oslo.cache. It’s been slow due to other demands, but I’m 
hoping to get back to it in the near future here so we can make moves like this 
more easily.
—
Morgan Fainberg
Principal Software Engineer
Core Developer, Keystone
m...@metacloud.com


On March 31, 2014 at 10:11:21, Dolph Mathews (dolph.math...@gmail.com) wrote:

dogpile.cache would be substantially lighter on the client-side as it only has 
a hard dependency on dogpile.core. It supports plenty of backends beyond 
memcached and we already use it in keystone quite heavily.

  http://dogpilecache.readthedocs.org/en/latest/


On Mon, Mar 31, 2014 at 11:35 AM, Doug Hellmann doug.hellm...@dreamhost.com 
wrote:



On Mon, Mar 31, 2014 at 12:18 PM, Kurt Griffiths kurt.griffi...@rackspace.com 
wrote:
Hi folks, has there been any discussion on using oslo.cache within the 
auth_token middleware to allow for using other cache backends besides 
memcached? I didn’t find a Keystone blueprint for it, and was considering 
registering one for Juno if the team thinks this feature makes sense. I’d be 
happy to put some time into the implementation.

That does make sense. We need to look at the dependency graph between the 
keystoneclient and oslo.cache, though. It appears the current version of 
oslo.cache is going to bring in quite a few oslo libraries that we would not 
want keystoneclient to depend on [1]. Moving the middleware to a separate 
library would solve that.

[1] https://wiki.openstack.org/wiki/Oslo/Dependencies

Doug


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


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

[openstack-dev] [Swift] PTL candidacy

2014-03-31 Thread John Dickinson

I'm announcing my candidacy for Swift PTL. I've been involved with Swift 
specifically and OpenStack in general since the beginning. I'd like to continue 
to serve in the role as Swift PTL.

Swift has grown quite a bit over the last 4 years. In this past year, we've 
added major new features refactored significant areas of the code to improve 
efficiency and extensibility. We've added support for global clusters. We've 
significantly refactored replication to be more efficient. We've cleaned up the 
volume interface to make it much simpler to extend. Swift is a great storage 
engine, powering some of the world's largest storage clouds. Let's keep making 
it better.

Going forward, I'd like to address four things in Swift in the next year:

1) Finish storage policies, including erasure code support. In my opinion, this 
is the biggest feature in Swift since it was open-sourced, and I'm really 
excited by the opportunities it enables. I sent an email earlier this month 
about our current plan on getting storage policies finished up: 
http://lists.openstack.org/pipermail/openstack-dev/2014-March/030937.html

2) Focus on performance and efficiency rather than on a feature train. We've 
started on several things here, including the ssync replication improvements 
and some profiling middleware. I'd also like to see improvement in replication 
bandwidth efficiency (especially with global clusters), time-to-first-byte 
latency improvement, better support of very dense storage, and support higher 
concurrency with less resources.

3) Better QA. Swift has always been a very stable system. We need to ensure 
that it remains stable, especially as new feature go in and other parts of the 
codebase change. Examples here include better functional test coverage, testing 
against real clusters, more end-to-end testing of workflows, running probetests 
automatically against submitted changes, and tracking performance metrics 
against patches. 

4) Better community efficiency. As the community has grown, we need to get 
better at offering feedback channels from production deployments, especially 
from non-developers. We need to get better at reducing the patch review time 
and encouraging newer developers to jump in and offer patches.

These are the things that I want to focus on as PTL in the next 6 to 12 months. 
My vision for Swift is that everyone will use it every day, even if they don't 
realize it. Together we can make it happen.

--John






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][L3] Dynamic Routing Use Cases

2014-03-31 Thread Carl Baldwin

Hi All,

The neutron L3 subteam [1] has been discussing dynamic routing use
cases for a couple of weeks in our meeting.  I attempted to capture
the use cases at a high level here [2].  It is far from complete, I'd
like some feedback from the community on the use cases.

Carl Baldwin

[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
[2] https://wiki.openstack.org/wiki/Neutron/DynamicRoutingUseCases

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

[openstack-dev] [Nova] Juno open for development

2014-03-31 Thread Russell Bryant

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

Re: [openstack-dev] [Nova] PTL Candidacy

2014-03-31 Thread John Garbutt

On 31 March 2014 18:53, John Garbutt j...@johngarbutt.com wrote:
 Hi,

 I would like to run for the OpenStack Compute (Nova) PTL position.

 I find it really rewarding to help resolve conflict. Gallup says I am
 a: Learner, Arranger, Achiever, Relator, Includer. I like to listen to
 all sides of the story, learn about everyones point of view, help
 frame the argument, and help come up with a resolution that works for
 everyone. That is why the idea of being a PTL excites me.

 Nova excites me because I love projects that integrate lots of
 different components into a single cohesive user experience. (I see it
 as one of the upsides of my Dyslexia.)

 Should I get elected, Rackspace has promised that Nova PTL will be my
 full time job.


 My (OpenStack) life story...
 

 My first involvement with Nova was in late 2010, working on what
 became Citrix's Project Olympus private cloud packaging of OpenStack
 and XenServer. We got Nova, Glance, Swift and XenServer all installed
 and configured from a CD (or optional PXE) install.

 After some changes in direction at Citrix, I started focusing on
 XenServer and OpenStack integration, with a particular focus on Nova.
 This lead me to form the XenAPI sub team, and help Russell with his
 formalisation of the Nova Sub-Team concept.

 In early 2013, I moved to Rackspace. That allowed me to focus more
 attention on the rest of Nova. I am part of the dev team working on
 (probably) the largest Nova installation in the world, Rackspace Cloud
 Servers. I quickly joined nova-core, and then nova-drivers. Most
 recently taking up the role of blueprint czar.

 I feel I am in a better position than most to understand the breadth
 of the Nova community, given my varied experience:
 * moved from packaging OpenStack, then contributing code to Nova, now
 helping more with the leadership of Nova
 * worked on packaging OpenStack for private clouds (at Citrix)
 * currently helping run (probably) the largest Nova deployment on the
 planet, at Rackspace
 * worked at a company whose strategy is more focused on its own
 product, than the success of OpenStack (at Citrix). Note: I consider
 this a perfectly valid situation. Without people concentrating on
 non-OpenStack projects and products, Nova would have nothing to
 orchestrate.


 How I see the PTL role
 --

 The basics of the Project Team Lead (or Project Technical Lead) role
 are covered here:
 https://wiki.openstack.org/wiki/PTLguide

 I feel that the role is really about fostering a vibrant community,
 and ensuring decisions get made, not making the decisions. This
 challenge really excites me, as in the past, I have had much fun, and
 many successes, resolving conflicts between conflicting/competing
 teams, helping them find a good resolution.

 What I have found works is...
 * Agree on a common set of user problems that need to be solved now
 * ... and at the same time, gain a better understanding of where
 people need/want to go in the future

 That way, everyone starts to focus their efforts in the same direction.


 What I would keep
 -

 In summary, I would keep most things. The Nova project is thriving.

 The focus on cloud and not server virt should continue. That
 doesn't mean we shouldn't work well at the small scale, we should work
 well at both the large scale and the small scale. We should not stop
 the work evolving the architecture of Nova and working out how to
 evolve the API. Indeed, we also need to continue to improve how we
 interface with Neutron, Glance, etc, etc.

 We should also continue to avoid Nova scope creep, and continue to
 reduce the scope of Nova where possible:
 * split out nova-scheduler, to help cross project scheduling
 * deprecate nova-network, or/and split it out of nova
 * keep on the look out for other ideas

 There are several people I would trust to be a good PTL for the next
 cycle, which shows how much Russell has managed to scale out the
 leadership in recent cycles. This drive to scale out the leadership of
 Nova should continue.


 But there are growing pains that need urgent attention...


 What I would change
 ---

 This is not about what we should build in Juno, it's how I'm thinking
 the Nova community and Nova leadership should evolve during Juno:


 1) Connecting developers with those using Nova

 We are a very developer driven community. I would like to work with
 deployers, packagers, and all users, to get their voices heard by the
 Nova developer community.

 The improved blueprint reviews and improved triaging of bugs are a
 good start, but we need to continue to innovate here. Glance have
 included a Product Manager, Brian Rosmaita, on their drivers team. I
 am sure Nova would benefit from getting Product Managers, Operators,
 and others, more involved in setting project priorities.

Just to clarify, I am not suggesting we give non-developers +2/-2/+A
on design specifications, but I would like

Re: [openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread Chris K

Hi David,

We are in feature freeze right now, waiting for the Juno cycle to open up,
so there are several reviews that are holding. If you are able please join
the #opensack-ironic IRC channel, there is almost always a core member in
channel who should be able to answer any questions you have about specific
reviews.

Chris Krelle


On Mon, Mar 31, 2014 at 8:47 AM, David Kranz dkr...@redhat.com wrote:

 I was reviewing some ironic changes that are more than a week old and do
 not have any reviews from the ironic team. Having at least one review from
 the ironic team would be very helpful.

  -David

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

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

[openstack-dev] [Horizon] PTL Candidacy

2014-03-31 Thread Lyle, David

I would like to announce my candidacy for Horizon PTL.

I've been working on and contributing to Horizon for the last three releases 
and had the pleasure to serve as the PTL for the Icehouse cycle.

In the Icehouse cycle, we started a number of changes that I would like to see 
completed in the Juno cycle:

1) Adding Role Based Access Control support in the user interface for all 
services across OpenStack.  This is an ongoing process as we have support for 
several services, and many more in progress.  Once the changes are completed, 
Horizon will be able to support users with various cloud operator defined roles 
beyond just member and admin.  This will also allow for a dramatic reduction in 
duplicate code.

2) Supporting richer client experiences and less custom JavaScript, by adopting 
AngularJS. In Juno, I would like to see further progress on this transition 
with effective use of Angular to improve end user experience with items like 
better client side validation and more responsive workflows.

3) An increased focus on usability. In Icehouse, Horizon added a wizard UI and 
with the help of the OpenStack-UX team conducted usability testing on Horizon.  
Horizon needs to work toward not only supporting as much of the OpenStack 
service APIs as possible, but making sure we do so in a well thought out and 
user enabling way. In Juno, I would like to see a focus on implementing more 
intuitive workflows.

4) Breaking horizon into logical pieces.  We formulated a plan to split the 
existing Horizon repo into several repos to separate concerns and improve 
extensibility and maintainability.  In Juno, we need to achieve this split.

5) Support infrastructure management.  In Icehouse, tuskar-ui (rename to 
follow) joined the Horizon Program, I am excited by the future inclusion of 
greater infrastructure and deployment management into the Horizon framework.  
We need to help this functionality progress and fill out the Horizon ecosystem. 


In the Icehouse release, we saw continued growth of the Horizon community.  I 
am very proud of the accomplishments we've made in Icehouse and I'm excited by 
the opportunities ahead in Juno.


Thanks,
David Lyle

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

Re: [openstack-dev] [Horizon] PTL Candidacy

confirmed

On 03/31/2014 02:52 PM, Lyle, David wrote:
 I would like to announce my candidacy for Horizon PTL.
 
 I've been working on and contributing to Horizon for the last three releases 
 and had the pleasure to serve as the PTL for the Icehouse cycle.
 
 In the Icehouse cycle, we started a number of changes that I would like to 
 see completed in the Juno cycle:
 
 1) Adding Role Based Access Control support in the user interface for all 
 services across OpenStack.  This is an ongoing process as we have support for 
 several services, and many more in progress.  Once the changes are completed, 
 Horizon will be able to support users with various cloud operator defined 
 roles beyond just member and admin.  This will also allow for a dramatic 
 reduction in duplicate code.
 
 2) Supporting richer client experiences and less custom JavaScript, by 
 adopting AngularJS. In Juno, I would like to see further progress on this 
 transition with effective use of Angular to improve end user experience with 
 items like better client side validation and more responsive workflows.
 
 3) An increased focus on usability. In Icehouse, Horizon added a wizard UI 
 and with the help of the OpenStack-UX team conducted usability testing on 
 Horizon.  Horizon needs to work toward not only supporting as much of the 
 OpenStack service APIs as possible, but making sure we do so in a well 
 thought out and user enabling way. In Juno, I would like to see a focus on 
 implementing more intuitive workflows.
 
 4) Breaking horizon into logical pieces.  We formulated a plan to split the 
 existing Horizon repo into several repos to separate concerns and improve 
 extensibility and maintainability.  In Juno, we need to achieve this split.
 
 5) Support infrastructure management.  In Icehouse, tuskar-ui (rename to 
 follow) joined the Horizon Program, I am excited by the future inclusion of 
 greater infrastructure and deployment management into the Horizon framework.  
 We need to help this functionality progress and fill out the Horizon 
 ecosystem. 
 
 
 In the Icehouse release, we saw continued growth of the Horizon community.  I 
 am very proud of the accomplishments we've made in Icehouse and I'm excited 
 by the opportunities ahead in Juno.
 
 
 Thanks,
 David Lyle
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


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

Re: [openstack-dev] bug/129135

2014-03-31 Thread Nathanael Burton

Also, how does this work for RHEL-based distros where they tend to backport
new kernel features?  For instance vxlan support was added in the kernel
for RHEL6.5 which is 2.6.32-based...  That changeset looks like it breaks
Neutron for ovs + vxlan on RHEL distros.

Nate


On Mon, Mar 31, 2014 at 1:07 PM, sowmini.varad...@hp.com wrote:


 openstack-dev,

 A question about the fix from https://review.openstack.org/#/c/82931

 After this fix, the neutron code now explicitly checks for kernel
 version 3.13- was this deliberate? (I was using an older 3.11 version
 before, and did not seem to have any issues before this change).

 Is there a specific kernel patch that ovs-vxlan is dependant on?

 Thanks
 Sowmini

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

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

Re: [openstack-dev] [Mistral] Engine overview and proposal

2014-03-31 Thread Dmitri Zimine

I am in the full agreement with the proposed approach (risked to copy below, 
let's see if email handles your diagrams): 

* Single Engine handles multiple executions asynchronously, in non-blocking way.
* Persistence access only from API and/or Engine, Engine writes, API reads. 
* Action runes don't talk to DB - it's very simple protocol and queue is 
perfectly fine. 
* This is scalable and as fault tolerant as underlying DB and Queue. Engine 
restart is no loss of info with right persistense; ActionRunner restart  is a 
lost of Action, which can fail for 100 other reasons thus expected, and with 
the right retry policy potentially recoverable. 

I'll inline minor points in the etherpad. 



 API EngineQueueDatabaseWorkers
  |   |   | | | ||   |
--- +-+  |   | | | ||   |
 |S|  |   | | | ||   |
 |t| -- +-+  | | | ||   |
 |a| | |  - - - - - - - - ||   |
 |r| | | - - - - t - - - - - - - - -  +-+  |
 |t| -- +-+  | | | |   | |  |
--- +-+  |   | | | |   | |  |
  |   |  +-+ - r - - - - - - - - - -  +-+  |
--- +-+  |  | | - - - - - -  R|   |
 |I|  |  | | - - t - - - - - - - - -  +-+  |
 |n|  |  | | - - t - - - - - - - - - - -  +-+
 |f|  |  +-+| | |   | | | |
 |o| - - - - - - - - - - - -  |   | | | |
--- +-+  |  +-+ - r - - - - - - - - - - -+-+ | |
  |   |  | | - - - - - -  R|  | |
--- +-+  |  +-+| | ||  | |
 |S| -- +-+  | | | ||  | |
 |t| | | - - - - - - - -  ||  | |
 |o| -- +-+  | | | ||  | |
 |p|  |  +-+ - r  - - - - - - - - - - - - +-+
--- +-+  |  | | - - - - - -  R|   |
  |   |  |%|| | ||   |
  |   |  +-+| | ||   |
  |   |   | | | ||   |


On Mar 31, 2014, at 4:09 AM, Kirill Izotov enyk...@stackstorm.com wrote:

 I have an idea regarding engine design i want to share with you. But first, 
 it seems like we need a small overview of the current implementations.
 
 I'm not sure how ML will react on a bunch of ASCII graphs, so here is an 
 etherpad: 
 https://etherpad.openstack.org/p/mistral-engine-overview-and-proposal
 
 What do you think, guys, is this the way to go?
 
 -- 
 Kirill Izotov
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Nova] Icehouse RC1 available

Hello everyone,

Nova just published its first Icehouse release candidate. Congrats to
all Nova developers for reaching this key milestone: 131 bugs were
fixed in Nova since feature freeze earlier this month !

The RC1 is available for download at:
https://launchpad.net/nova/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2014.1 final
version on April 17. You are therefore strongly encouraged to test and
validate this tarball !

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/nova/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/nova/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Note that the master branch of Nova is now open for Juno
development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-03-31 Thread Jeremy Stanley

On 2014-03-31 10:55:06 +0200 (+0200), Thierry Carrez wrote:
 No miracle here... All slots are pretty full as expected. I think our
 best bet is still the 30-min morning break on Wednesday or Thursday at
 10:30am.

Would finding an available room for an hour sometime on Monday make
sense instead? Since we don't have design sessions that day, it
might make it easier to collect some majority of interested ATCs for
longer than we can cram into a 30-minute break. On the other hand it
will potentially conflict with some other operations and general
conference stuff, so we end up leaving out people who might be doing
those things instead...
-- 
Jeremy Stanley

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

[openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread Mark McClain

All-

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL and would like to continue leading our team during 
the Juno cycle.  As PTL, I have worked to promote a vibrant open ecosystem of 
deployers, integrators and vendors within Neutron.  Our openness is exemplified 
by the new drivers/plugins, new contributors, and diversity of sub team 
leadership in Icehouse.

Qualifications
---
I have been a contributor to Neutron since Essex and a core team member since 
Folsom.  I have been developing software with Python professionally for 14 
years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
Neutron code base, I have worked extensively on DHCP, IP library, network 
namespaces, metadata services, database migrations, and LBaaS reference 
implementation.  I frequently present Neutron at local and regional OpenStack 
events to build community by engaging new developers, deployers, and 
integrators.

I am the top reviewer during the Icehouse cycle:
http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt

I am the top reviewer since the inception of Neutron:
http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt

Icehouse

As the technical lead during Icehouse, I kicked off the initiative to improve 
testing within Neutron.  This initiative included the creation of the mid-cycle 
sprint that brought the QA and Neutron teams together.  The successful sprint  
produced a more stable Neutron core, more API test coverage, the soon-to-be 
enabled full Tempest and Grenade jobs and a more connected community.  
Additionally, I promoted the policy of improve 3rd party testing of 
plugin/driver code from vendors [1].  This initiative has resulted in a more 
thoroughly tested and stable driver/plugin codebase for operators to deploy.

Juno
---
My vision for Juno is that our team continue to build upon the open environment 
that enables all vendors, deployers and integrators the opportunity to 
contribute to the development of Neutron.  During the cycle, I believe our team 
should focus on a few core initiatives:

* Nova Parity
We committed to delivering Nova Parity when Neutron was accepted as an 
Integrated project.  By delivering Distributed Virtual Routing, Nova-Network to 
Neutron migration, testing and documentation we will be following through on 
our commitment to the greater OpenStack community.

* Advanced Services
The team should implement a multi-vendor ‘flavor' API that provides tenants an 
easy to use API, deployers a choice and vendors an opportunity to innovate.  
This API should complement the existing APIs our teams have created over the 
last two cycles.  Additionally, we should add secure APIs and agent code to 
support SSL termination for LBaaS and SSL VPNs.

* Process Improvements
Our team has grown, but our processes for submitting and reviewing blueprints 
has largely stayed the same which has made the review process uneven. As the 
Icehouse cycle has wound down, I have been working to put new infrastructure in 
place to improve the blueprint process for Juno[2].  The new process should 
ensure a more consistent experience for all contributors in Juno.  In addition 
to refining the blueprint process, our sub team structure should be revised to 
improve communication, remove blockers, and facilitate more efficient reviews.

* Internal API and REST API Improvements
We have several exciting new features in development for Neutron, but at times 
our internal APIs have inhibited efficient implementation of these features.  
During the Juno cycle, we should begin the process of revising our internal 
interfaces to enable easier IPv6, migration to Python 3 and development of 
plugins/drivers and services,

* Group Policy
There is significant community interest in adding policy support to Neutron.  
During Juno, we should work on implementing the first iteration of the policy 
API extension.  This extensions will be aided by the work to improve the 
internal API.

* Testing
The team made significant testing gains during Icehouse.  We should build on 
that work during Juno and collaborate with the QA team to further refine and 
improve our testing through additional scenarios, varied migration 
configurations and functional tests.

* Documentation
Good documentation is a requirement for both deployers and developers we have 
made improvements to both Icehouse.  For Juno, I’d like to continue this work 
as it is essential for parity.

* Growing our plugin and driver community

See something missing from this list?  As PTL, I’m excited to work with our 
community to refine this list for Juno.


Other OpenStack Contributions
--
* Co-organizer of the Atlanta OpenStack Meetup
* Member of the Technical Committee since the Havana cycle
* Stable Core Team Member
* Requirements Core Team Member

Thanks,
mark

[1]

Re: [openstack-dev] [Neutron] PTL Candidacy

confirmed

On 03/31/2014 04:15 PM, Mark McClain wrote:
 All-
 
 I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.
 
 I am the current Neutron PTL and would like to continue leading our team 
 during the Juno cycle.  As PTL, I have worked to promote a vibrant open 
 ecosystem of deployers, integrators and vendors within Neutron.  Our openness 
 is exemplified by the new drivers/plugins, new contributors, and diversity of 
 sub team leadership in Icehouse.
 
 Qualifications
 ---
 I have been a contributor to Neutron since Essex and a core team member since 
 Folsom.  I have been developing software with Python professionally for 14 
 years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
 Neutron code base, I have worked extensively on DHCP, IP library, network 
 namespaces, metadata services, database migrations, and LBaaS reference 
 implementation.  I frequently present Neutron at local and regional OpenStack 
 events to build community by engaging new developers, deployers, and 
 integrators.
 
 I am the top reviewer during the Icehouse cycle:
 http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt
 
 I am the top reviewer since the inception of Neutron:
 http://russellbryant.net/openstack-stats/neutron-reviewers-1095.txt
 
 Icehouse
 
 As the technical lead during Icehouse, I kicked off the initiative to improve 
 testing within Neutron.  This initiative included the creation of the 
 mid-cycle sprint that brought the QA and Neutron teams together.  The 
 successful sprint  produced a more stable Neutron core, more API test 
 coverage, the soon-to-be enabled full Tempest and Grenade jobs and a more 
 connected community.  Additionally, I promoted the policy of improve 3rd 
 party testing of plugin/driver code from vendors [1].  This initiative has 
 resulted in a more thoroughly tested and stable driver/plugin codebase for 
 operators to deploy.
 
 Juno
 ---
 My vision for Juno is that our team continue to build upon the open 
 environment that enables all vendors, deployers and integrators the 
 opportunity to contribute to the development of Neutron.  During the cycle, I 
 believe our team should focus on a few core initiatives:
 
 * Nova Parity
 We committed to delivering Nova Parity when Neutron was accepted as an 
 Integrated project.  By delivering Distributed Virtual Routing, Nova-Network 
 to Neutron migration, testing and documentation we will be following through 
 on our commitment to the greater OpenStack community.
 
 * Advanced Services
 The team should implement a multi-vendor ‘flavor' API that provides tenants 
 an easy to use API, deployers a choice and vendors an opportunity to 
 innovate.  This API should complement the existing APIs our teams have 
 created over the last two cycles.  Additionally, we should add secure APIs 
 and agent code to support SSL termination for LBaaS and SSL VPNs.
 
 * Process Improvements
 Our team has grown, but our processes for submitting and reviewing blueprints 
 has largely stayed the same which has made the review process uneven. As the 
 Icehouse cycle has wound down, I have been working to put new infrastructure 
 in place to improve the blueprint process for Juno[2].  The new process 
 should ensure a more consistent experience for all contributors in Juno.  In 
 addition to refining the blueprint process, our sub team structure should be 
 revised to improve communication, remove blockers, and facilitate more 
 efficient reviews.
 
 * Internal API and REST API Improvements
 We have several exciting new features in development for Neutron, but at 
 times our internal APIs have inhibited efficient implementation of these 
 features.  During the Juno cycle, we should begin the process of revising our 
 internal interfaces to enable easier IPv6, migration to Python 3 and 
 development of plugins/drivers and services,
 
 * Group Policy
 There is significant community interest in adding policy support to Neutron.  
 During Juno, we should work on implementing the first iteration of the policy 
 API extension.  This extensions will be aided by the work to improve the 
 internal API.
 
 * Testing
 The team made significant testing gains during Icehouse.  We should build on 
 that work during Juno and collaborate with the QA team to further refine and 
 improve our testing through additional scenarios, varied migration 
 configurations and functional tests.
 
 * Documentation
 Good documentation is a requirement for both deployers and developers we have 
 made improvements to both Icehouse.  For Juno, I’d like to continue this work 
 as it is essential for parity.
 
 * Growing our plugin and driver community
 
 See something missing from this list?  As PTL, I’m excited to work with our 
 community to refine this list for Juno.
 
 
 Other OpenStack Contributions
 --
 * Co-organizer of the Atlanta OpenStack Meetup
 * Member

Re: [openstack-dev] [qa] [ironic] Need tempest reviews from ironic team

2014-03-31 Thread David Kranz


On 03/31/2014 02:42 PM, Chris K wrote:

Hi David,

We are in feature freeze right now, waiting for the Juno cycle to open 
up, so there are several reviews that are holding. If you are able 
please join the #opensack-ironic IRC channel, there is almost always a 
core member in channel who should be able to answer any questions you 
have about specific reviews.


Chris Krelle
Thanks, but this is not quite the issue. It is that many tempest 
reviewers do not know all the ins and outs of every api, particularly 
new ones. So it is helpful to have a +1 from some one who does. This has 
been very valuable in neutron and I'm sure it would be here as well. I 
will certainly ping in #openstack-ironic if there are any specific issues.


 -David




On Mon, Mar 31, 2014 at 8:47 AM, David Kranz dkr...@redhat.com 
mailto:dkr...@redhat.com wrote:


I was reviewing some ironic changes that are more than a week old
and do not have any reviews from the ironic team. Having at least
one review from the ironic team would be very helpful.

 -David

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




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


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

[openstack-dev] [Heat] Icehouse RC1 available

Hello everyone,

Last one for today, Heat just published its first Icehouse release
candidate. 63 bugs were fixed since feature freeze earlier this month.

The RC1 is available for download at:
https://launchpad.net/heat/icehouse/icehouse-rc1

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the 2014.1 final
version on April 17. You are therefore strongly encouraged to test and
validate this tarball !

Alternatively, you can directly test the milestone-proposed branch at:
https://github.com/openstack/heat/tree/milestone-proposed

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/heat/+filebug

and tag it *icehouse-rc-potential* to bring it to the release crew's
attention.

Note that the master branch of Heat is now open for Juno
development, and feature freeze restrictions no longer apply there.

Regards,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Domains prototype in Nova

2014-03-31 Thread Vishvananda Ishaya

Note that there has been a lot of discussion and a potential path forward for 
hierarchical project support in openstack. I personally think this makes a lot 
more sense than having a bunch of domain specific calls. Please take a look at 
the information in the wiki here:

https://wiki.openstack.org/wiki/HierarchicalMultitenancy

We are going to be discussing this in detail at the summit.

Vish

On Mar 28, 2014, at 7:06 AM, Henrique Truta henriquecostatr...@gmail.com 
wrote:

 Hi all!
 
 I've been working on a prototype of Domains in Nova. In that prototype the 
 user is now able to do the following API calls with a domain scoped token:
 
 GET v2/domains/{domain_id}/servers: Lists servers which projects belong to 
 the given domain
 GET v2/domains/{domain_id}/servers/{server_id}: Gets details from the given 
 server
 DELETE v2/domains/{domain_id}/servers/{server_id}: Deletes the given server
 POST v2/domains/{domain_id}/servers/{server_id}/action: Reboots the given 
 server
 
 Could you help me test these functionalities and review the code?
 
 The code can be found in my github repo 
 (https://github.com/henriquetruta/nova) on the domains-prototype branch.
 
 Thanks!
 
 -- 
 --
 Ítalo Henrique Costa Truta
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Juno open for development

I should specify that I meant updating the OS version used by the CI.

- Original Message -
From: Solly Ross sr...@redhat.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Sent: Monday, March 31, 2014 5:24:12 PM
Subject: Re: [openstack-dev] [Nova] Juno open for development

There was some talk about updating the CI for Juno.
Has this been done/when will this be done?

Best Regards,
Solly Ross

- Original Message -
From: Russell Bryant rbry...@redhat.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Monday, March 31, 2014 2:23:32 PM
Subject: [openstack-dev] [Nova] Juno open for development

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

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

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

Re: [openstack-dev] [Nova] Juno open for development

There was some talk about updating the CI for Juno.
Has this been done/when will this be done?

Best Regards,
Solly Ross

- Original Message -
From: Russell Bryant rbry...@redhat.com
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Sent: Monday, March 31, 2014 2:23:32 PM
Subject: [openstack-dev] [Nova] Juno open for development

We just merged the change that opens the master branch for Juno development:

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

We will be releasing icehouse-rc1 from the commit that precedes the
above patch.  If anything comes up that warrants another release
candidates, please get in contact with me directly.

On the Juno front, we are now ready to start accepting and reviewing
Juno blueprints.  The process is documented here:

https://wiki.openstack.org/wiki/Blueprints#Creation

If you have any questions not answered by that page, please bring them
up so that we can ensure the process is adequately documented.

Thanks,

-- 
Russell Bryant

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

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

Re: [openstack-dev] [Nova] Juno open for development

2014-03-31 Thread Clark Boylan

The infrastructure team can update the OSes used by the gate when new
versions of the distros we use release, and our cloud providers make
those images available to us (or provide us with glance upload access,
whichever comes first). That means we can't upgrade Ubuntu to Trusty
until Trusty releases, same story with Centos7.

Also, there is typically a period of making things work after we get
access to VMs running these new images. So you can probably count on
an additional delay before things are tested on Trusy and Centos7.

Clark

On Mon, Mar 31, 2014 at 2:25 PM, Solly Ross sr...@redhat.com wrote:
 I should specify that I meant updating the OS version used by the CI.

 - Original Message -
 From: Solly Ross sr...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Sent: Monday, March 31, 2014 5:24:12 PM
 Subject: Re: [openstack-dev] [Nova] Juno open for development

 There was some talk about updating the CI for Juno.
 Has this been done/when will this be done?

 Best Regards,
 Solly Ross

 - Original Message -
 From: Russell Bryant rbry...@redhat.com
 To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
 Sent: Monday, March 31, 2014 2:23:32 PM
 Subject: [openstack-dev] [Nova] Juno open for development

 We just merged the change that opens the master branch for Juno development:

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

 We will be releasing icehouse-rc1 from the commit that precedes the
 above patch.  If anything comes up that warrants another release
 candidates, please get in contact with me directly.

 On the Juno front, we are now ready to start accepting and reviewing
 Juno blueprints.  The process is documented here:

 https://wiki.openstack.org/wiki/Blueprints#Creation

 If you have any questions not answered by that page, please bring them
 up so that we can ensure the process is adequately documented.

 Thanks,

 --
 Russell Bryant

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

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

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

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

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-03-31 Thread Clint Byrum

Excerpts from Jeremy Stanley's message of 2014-03-31 13:03:28 -0700:
 On 2014-03-31 10:55:06 +0200 (+0200), Thierry Carrez wrote:
  No miracle here... All slots are pretty full as expected. I think our
  best bet is still the 30-min morning break on Wednesday or Thursday at
  10:30am.
 
 Would finding an available room for an hour sometime on Monday make
 sense instead? Since we don't have design sessions that day, it
 might make it easier to collect some majority of interested ATCs for
 longer than we can cram into a 30-minute break. On the other hand it
 will potentially conflict with some other operations and general
 conference stuff, so we end up leaving out people who might be doing
 those things instead...

Would it be entirely out of line to take a portion of an infra-team
session to do this? A lot of keys can be signed in 30 minutes.

* You will have the most important people in the WoT for OpenStack in
  that room. This will ensure that the signing is extremely relevant.
* The projection method will be available.
* This seems relevant to OpenStack development infrastructure.

If not, then taking over a session room directly after any day of the
event has been the most successful strategy I've seen at open source
conferences. It needs to be relatively soon after everything ends so that
people can still get to their respective plans.

If we can't commandeer a session, I'll go down the path of contacting
the conference/summit organizers to see if that is possible.

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

Re: [openstack-dev] [nova] [bug] nova server-group-list doesn't show any members

2014-03-31 Thread Vishvananda Ishaya


On Mar 27, 2014, at 4:38 PM, Chris Friesen chris.frie...@windriver.com wrote:

 On 03/27/2014 04:47 PM, Chris Friesen wrote:
 
 Interestingly, unit test
 nova.tests.api.openstack.compute.contrib.test_server_groups.ServerGroupTest.test_display_members
 passes just fine, and it seems to be running the same sqlalchemy code.
 
 Is this a case where sqlite behaves differently from mysql?
 
 Sorry to keep replying to myself, but this might actually hit us other places.
 
 Down in db/sqlalchemy/api.py we end up calling
 
 
 query = query.filter(column_attr.op(db_regexp_op)('None’))

Sqlalchemy handles mapping None to NULL in many cases, so it appears that the 
problem is that we are passing
None as a string here?

Vish

 
 
 When using mysql, it looks like a regexp comparison of the string 'None' 
 against a NULL field fails to match.
 
 Since sqlite doesn't have its own regexp function we provide one in 
 openstack/common/db/sqlalchemy/session.py.  In the buggy case we end up 
 calling it as regexp('None', None), where the types are unicode and 
 NoneType.  However, we end up converting the second arg to text type before 
 calling reg.search() on it, so it matches.
 
 Chris
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [third-party-testing] Enabling voting for 3rd party testing

2014-03-31 Thread Kyle Mestery

What is the criteria for this? The OpenDaylight Jenkins has been
reliably voting for a few weeks now, I'm wondering how and when we can
get it's voting rights approved.

Thanks!
Kyle

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

Re: [openstack-dev] [neutron] [third-party-testing] Enabling voting for 3rd party testing