date:20150113




On 1/13/2015 8:27 PM, liuxinguo wrote:

Hi all,

I have commit a bug-fix patch and it have passed the Jenkins check, but
in Jenkins gate it failed for gate-cinder-python27
http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/.

I have dig into the error log but can not see anything wrong in my patch
code.

Review page is: https://review.openstack.org/#/c/143765/

And the error log for gate-cinder-python27
http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/
in Jenkins gate can be seen in the attachment app:ds:attachment.

Appreciate for any input, thanks!

liu



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



Something busted in cinder after the oslo.concurrency 0.4.0 release 
yesterday, it's not just your patch failing:


http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiUmVxdWlyZWRPcHRFcnJvcjogdmFsdWUgcmVxdWlyZWQgZm9yIG9wdGlvbjogbG9ja19wYXRoXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLWNpbmRlci1weXRob24yN1wiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDIxMjA3MzI0MjYwLCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Jenkins gate failure] Can not find any error for my patch.




On 1/13/2015 9:50 PM, Matt Riedemann wrote:



On 1/13/2015 8:27 PM, liuxinguo wrote:

Hi all,

I have commit a bug-fix patch and it have passed the Jenkins check, but
in Jenkins gate it failed for gate-cinder-python27
http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/.


I have dig into the error log but can not see anything wrong in my patch
code.

Review page is: https://review.openstack.org/#/c/143765/

And the error log for gate-cinder-python27
http://logs.openstack.org/65/143765/9/gate/gate-cinder-python27/2e7afd6/

in Jenkins gate can be seen in the attachment app:ds:attachment.

Appreciate for any input, thanks!

liu



__

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



Something busted in cinder after the oslo.concurrency 0.4.0 release
yesterday, it's not just your patch failing:

http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiUmVxdWlyZWRPcHRFcnJvcjogdmFsdWUgcmVxdWlyZWQgZm9yIG9wdGlvbjogbG9ja19wYXRoXCIgQU5EIHRhZ3M6XCJjb25zb2xlXCIgQU5EIGJ1aWxkX25hbWU6XCJnYXRlLWNpbmRlci1weXRob24yN1wiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDIxMjA3MzI0MjYwLCJtb2RlIjoiIiwiYW5hbHl6ZV9maWVsZCI6IiJ9




Already reported:

https://bugs.launchpad.net/cinder/+bug/1410485

And fixed:

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

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [nova]nova not work with eventlet 0.16.0

2015-01-13 Thread Adam Gandelman

So eventlet 0.16.x has started hitting slaves and breaking stable branches
(its not like we weren't warned :\ )

https://bugs.launchpad.net/nova/+bug/1410626

Should hopefully be resolved by eventlet versions caps in icehouse + juno's
requirements:

https://review.openstack.org/#/q/I4bbbeb5bf9c22ed36f5c9a74fec6b487d2c15697,n,z

Cheers,
Adam


On Tue, Jan 6, 2015 at 1:18 AM, Eli Qiao ta...@linux.vnet.ibm.com wrote:

  hi all ,
 I set up nova environment with latest upstream code.
 nova-compute can not boot up due to failed to load libvirt driver.
 by further debugging. found that eventlet (0.16.0) remove util  which is
 referenced by libvirt driver.
 after I downgrade to (0.15.2) it works.

 *0.15.2*

 In [3]: print eventlet.__version__
 0.15.2

 In [5]: import eventlet.util

 In [6]:


 -
 *0.16.0*


 In [1]: import eventlet.util
 ---
 ImportError   Traceback (most recent call last)
 ipython-input-1-a23626d6f273 in module()
  1 import eventlet.util

 ImportError: No module named util

 In [3]: import eventlet

 In [4]: print eventlet.__version__
 0.16.0

 In [5]:

 


 In [1]: import nova.virt.libvirt.LibvirtDriver
 ---
 ImportError   Traceback (most recent call last)
 ipython-input-1-2bdce28fc3dd in module()
  1 import nova.virt.libvirt.LibvirtDriver

 /opt/stack/nova/nova/virt/libvirt/__init__.py in module()
  13 #under the License.
  14
 --- 15 from nova.virt.libvirt import driver
  16
  17 LibvirtDriver = driver.LibvirtDriver

 /opt/stack/nova/nova/virt/libvirt/driver.py in module()
  96 from nova.virt.libvirt import dmcrypt
  97 from nova.virt.libvirt import firewall as libvirt_firewall
 --- 98 from nova.virt.libvirt import host
  99 from nova.virt.libvirt import imagebackend
 100 from nova.virt.libvirt import imagecache

 /opt/stack/nova/nova/virt/libvirt/host.py in module()
  37 from eventlet import patcher
  38 from eventlet import tpool
 --- 39 from eventlet import util as eventlet_util
  40
  41 from nova import exception

 ImportError: cannot import name util

 In [2]: import eventlet

 In [3]: from eventlet import util
 ---
 ImportError   Traceback (most recent call last)
 ipython-input-3-f6f91e4749eb in module()
  1 from eventlet import util

 ImportError: cannot import name util

 In [4]:

 --
 Thanks,
 Eli (Li Yong) Qiao


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


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

Re: [openstack-dev] About DVR limit

2015-01-13 Thread Stamina than Valued an

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

 On Jan 13, 2015, at 6:01 PM, 龚永生 gong.yongsh...@99cloud.net wrote:
 
 Hi,
  I am yong sheng gong, I want to know if the DVR has these limits besides the 
 documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:
 
 1. one subnet can be connected to DVR router only once, which is confirmed by 
 BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
 2. one network cannot have more than one subnet connecting to DVR routers
 
 
 So the DVR limits the neutron model to:
 one network has just one subnet, and one subnet cannot connect to more than 
 one DVR routers.
 
 
 ps.
 req and limits documented at 
 http://docs.openstack.org/networking-guide/content/ha-dvr.html::
  DVR requirements
 
 You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR.
 
 Be sure that your firewall or security groups allows UDP traffic over the 
 VLAN, GRE, or VXLAN port to pass between the compute hosts.
 
  DVR limitations
 
 Distributed virtual router configurations work with the Open vSwitch Modular 
 Layer 2 driver only for Juno.
 
 In order to enable true north-south bandwidth between hypervisors (compute 
 nodes), you must use public IP addresses for every compute node and enable 
 floating IPs.
 
 For now, based on the current neutron design and architecture, DHCP cannot 
 become distributed across compute nodes.
 
 
 thanks,
 Yong sheng gong
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

2015-01-13 Thread Vasudevan, Swaminathan (PNB Roseville)




On 1/13/2015 12:11 PM, Steven Hardy wrote:

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:

Looks like the fix we merged didn't actually fix the problem. I have a patch
[1] to uncap the boto requirement on master and it's failing the ec2 tests
in tempest the same as before.


FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with Signature not provided errors (for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

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



Yeah, new bug reported, looks like we're hitting 401 Unauthorized errors 
when trying to create security groups in the test:


https://bugs.launchpad.net/nova/+bug/1410622

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] About DVR limit

Hi Joehuang,
FIP today as of Juno can be both in centralized node (dvr_snat) and distributed 
“dvr” compute nodes.
Thanks
Swami

From: joehuang [mailto:joehu...@huawei.com]
Sent: Tuesday, January 13, 2015 7:49 PM
To: OpenStack Development Mailing List (not for usage questions); 龚永生
Cc: Vasudevan, Swaminathan (PNB Roseville)
Subject: RE: [openstack-dev] About DVR limit

Hi, Swami,

I would like to know whether the FIP under DVR could be configured to 
distributed mode or central mode in Kilo, not find relevant information from 
http://specs.openstack.org/openstack/neutron-specs/.

For example, it will be helpful for following FIP use cases: 1) FIP will be 
addressed centrally by dedicated hardware 2) not all compute nodes have public 
address.

Best Regards
Chaoyi Huang ( Joe Huang )

From: Stamina than Valued an [mailto:souminat...@yahoo.com]
Sent: Wednesday, January 14, 2015 11:05 AM
To: 龚永生
Cc: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com; 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] About DVR limit

Hi yong Zheng,
Yes your understanding is right.
We only support ovs driver.
Regarding HA and multi network support, it will be available in kilo.

Public address consumption for north south traffic for compute node is also 
true. But to address this issue we do have a proposal that is worked out by the 
l3 sub team.

I hope this clarifies your doubts.

Please let me know if I can help you with anything else.

Thanks
Swami

Sent from my iPad

On Jan 13, 2015, at 6:01 PM, 龚永生 
gong.yongsh...@99cloud.netmailto:gong.yongsh...@99cloud.net wrote:
Hi,
 I am yong sheng gong, I want to know if the DVR has these limits besides the 
documented at http://docs.openstack.org/networking-guide/content/ha-dvr.html:

1. one subnet can be connected to DVR router only once, which is confirmed by 
BP https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr-multigateway
2. one network cannot have more than one subnet connecting to DVR routers

So the DVR limits the neutron model to:
one network has just one subnet, and one subnet cannot connect to more than one 
DVR routers.

ps.
req and limits documented at 
http://docs.openstack.org/networking-guide/content/ha-dvr.html::
 DVR requirements

·You must use the ML2 plug-in for Open VSwitch (OVS) to enable DVR.

·Be sure that your firewall or security groups allows UDP traffic over 
the VLAN, GRE, or VXLAN port to pass between the compute hosts.

 DVR limitations

·Distributed virtual router configurations work with the Open vSwitch 
Modular Layer 2 driver only for Juno.

·In order to enable true north-south bandwidth between hypervisors 
(compute nodes), you must use public IP addresses for every compute node and 
enable floating IPs.

·For now, based on the current neutron design and architecture, DHCP 
cannot become distributed across compute nodes.

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

Re: [openstack-dev] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-13 Thread Germy Lure

Hi all,
I think we just power the scheduler API to be able to add and remove
candidates is enough.

As mentioned this thread, the agent just doesn't receive new request but
still keep old service alive.
So, just stop schedule new request to it. Direct and simple.

Hope my expression is clear enough.
Germy

On Fri, Jan 9, 2015 at 10:15 PM, Jay Pipes jaypi...@gmail.com wrote:

 Adding [api] topic.

 On 01/08/2015 07:47 PM, Kevin Benton wrote:

 Is there another openstack service that allows this so we can make the
 API consistent between the two when this change is made?


 Kevin, thank you VERY much for asking the above question and caring about
 consistency in the APIs!

 There was a discussion on the ML about this very area of the APIs, and how
 there is current inconsistency to resolve:

 http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-
 vs-state

 You were involved in that thread, so I know you're very familiar with the
 problem domain :)

 In the above thread, I mentioned that this really was something that the
 API WG should tackle, and this here ML thread should be a catalyst for
 getting that done.

 What we need is a patch proposed to the openstack/api-wg that proposes
 some guidelines around the REST API structure for disabling some resource
 for administrative purposes, with some content that discusses the semantic
 differences between state and status, and makes recommendations on the
 naming of resource attributes that indicate an admnistrative state.

 Of course, this doesn't really address Jack M's question about whether
 there should be a separate mode (in Jack's terms) to indicate that some
 resource can be only manually assigned and not automatically assigned.
 Personally, I don't feel there is a need for another mode. I think if
 something has been administratively disabled, that an administrator should
 still be able to manually alter that thing.

 All the best,
 -jay

  On Thu, Jan 8, 2015 at 3:09 PM, Carl Baldwin c...@ecbaldwin.net
 mailto:c...@ecbaldwin.net wrote:

 I added a link to @Jack's post to the ML to the bug report [1].  I am
 willing to support @Itsuro with reviews of the implementation and am
 willing to consult if you need and would like to ping me.

 Carl

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

 On Thu, Jan 8, 2015 at 7:49 AM, McCann, Jack jack.mcc...@hp.com
 mailto:jack.mcc...@hp.com wrote:
   +1 on need for this feature
  
   The way I've thought about this is we need a mode that stops the
 *automatic*
   scheduling of routers/dhcp-servers to specific hosts/agents,
 while allowing
   manual assignment of routers/dhcp-servers to those hosts/agents,
 and where
   any existing routers/dhcp-servers on those hosts continue to
 operate as normal.
  
   The maintenance use case was mentioned: I want to evacuate
 routers/dhcp-servers
   from a host before taking it down, and having the scheduler add
 new routers/dhcp
   while I'm evacuating the node is a) an annoyance, and b) causes a
 service blip
   when I have to right away move that new router/dhcp to another
 host.
  
   The other use case is adding a new host/agent into an existing
 environment.
   I want to be able to bring the new host/agent up and into the
 neutron config, but
   I don't want any of my customers' routers/dhcp-servers scheduled
 there until I've
   had a chance to assign some test routers/dhcp-servers and make
 sure the new server
   is properly configured and fully operational.
  
   - Jack
  
   ___
   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
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton


 ___
 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

2015-01-13 Thread Zane Bitter


On 13/01/15 11:58, Tomas Sedovic wrote:

I also had a chat with Steve Hardy and he suggested adding a STOPPED
state to the stack (this isn't in the spec). While not strictly
necessary to implement the spec, this would help people figure out that
the stack has reached a breakpoint instead of just waiting on a
resource
that takes a long time to finish (the heat-engine log and event-list
still show that a breakpoint was reached but I'd like to have it in
stack-list and resource-list, too).

It makes more sense to me to call it PAUSED (we're not completely
stopping the stack creation after all, just pausing it for a bit), I'll
let Steve explain why that's not the right choice :-).


+1 to PAUSED. To me, STOPPED implies an end state (which a breakpoint is
not).


I agree we need an easy way for the user to see why nothing is
happening, but adding additional states to the stack is a pretty
dangerous change that risks creating regressions all over the place. If
we can find _any_ other way to surface the information, it would be
preferable IMHO.


Would adding a new state to resources be similarly tricky, or could we
do that instead? That way you'd see what's going on in `resource-list`
which is should be good enough.


Yeah, that would be considerably less risky I think.

- ZB

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

Re: [openstack-dev] oslo.concurrency 0.4.0 released

On 01/13/2015 11:46 AM, Matt Riedemann wrote:
 
 
 On 1/13/2015 10:21 AM, Matt Riedemann wrote:


 On 1/13/2015 9:07 AM, Doug Hellmann wrote:
 The Oslo team is pleased to announce the release of
 oslo.concurrency 0.4.0: oslo.concurrency library

 This release removes the use of ConfigFilter when accessing
 configuration options, making it possible for applications
 to set defaults for the lock path option that refer to other
 option values.

 This version also adds a new context manager for detecting
 long-running operations and logging when they take longer
 than expected. See oslo_concurrency.watchdog.

 For more details, please see the git log history below and
   http://launchpad.net/oslo.concurrency/+milestone/0.4.0

 Please report issues through launchpad:
   http://bugs.launchpad.net/oslo.concurrency

 

 Changes in openstack/oslo.concurrency  0.3.0..0.4.0

 3dfefe6 Bump to hacking 0.10
 43dc67e Updated from global requirements
 df35680 add watchdog module
 18bcbe2 Updated from global requirements
 234b007 make time format for processutils match lockutils
 a414266 Correct the translation domain for loading messages
 9066336 Add a reader/writer lock
 9dd6d21 Don't use ConfigFilter for lockutils
 093ed4f Report import warnings where the import occurs
 7c7493f Port processutils to Python 3
 2aafe6f Activate pep8 check that _ is imported
 32bf940 Drop requirements-py3.txt
 deb0152 Updated from global requirements
 d59543d Clean up API documentation
 5de5c42 Workflow documentation is now in infra-manual
 09ab853 Remove noqa from test files
 3de55f3 test compatibility for old imports
 4fd64cb Fix bug link in README.rst

diffstat (except docs and test files):

   .gitignore   |   1 -
   CONTRIBUTING.rst |   7 +-
   README.rst   |   2 +-
   oslo/concurrency/__init__.py |   2 +-
   oslo_concurrency/_i18n.py|   2 +-
   oslo_concurrency/lockutils.py| 175 +++-
   oslo_concurrency/opts.py |   2 +-
   oslo_concurrency/processutils.py |  23 +-
   oslo_concurrency/watchdog.py |  66 +
   requirements-py3.txt |  14 -
   requirements.txt |   6 +-
   setup.cfg|   5 +-
   test-requirements.txt|   3 +-
   tests/__init__.py|   2 +-
   tests/test_import.py |  31 +++
   tests/test_lockutils.py  |   4 +-
   tests/test_processutils.py   |  18 +-
   tests/test_warning.py|  32 +++
   tests/test_watchdog.py   |  75 ++
   tox.ini  |   5 -
   31 files changed, 832 insertions(+), 90 deletions(-)

Requirements updates:

   diff --git a/requirements.txt b/requirements.txt
   index a27b434..fb89633 100644
   --- a/requirements.txt
   +++ b/requirements.txt
   @@ -9 +9 @@ fixtures=0.3.14
   -oslo.config=1.4.0  # Apache-2.0
   +oslo.config=1.6.0  # Apache-2.0
   @@ -11 +11 @@ oslo.i18n=1.0.0  # Apache-2.0
   -oslo.utils=1.0.0   # Apache-2.0
   +oslo.utils=1.2.0   # Apache-2.0
   @@ -14 +14 @@ six=1.7.0
   -retrying=1.2.2,!=1.3.0 # Apache-2.0
   +retrying=1.2.3,!=1.3.0 # Apache-2.0
   diff --git a/test-requirements.txt b/test-requirements.txt
   index c424655..32cdaae 100644
   --- a/test-requirements.txt
   +++ b/test-requirements.txt
   @@ -5 +5 @@
   -hacking=0.9.1,0.10
   +hacking=0.10.0,0.11
   @@ -7,0 +8 @@ coverage=3.6
   +futures=2.1.6

 __


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


 Looks like we probably have a new bug in nova now:

 http://goo.gl/i7qa0f

 
 Bug is reported with details inline:
 
 https://bugs.launchpad.net/oslo.concurrency/+bug/1410348

Here is a way to address if from purely the nova side -
https://review.openstack.org/146929

-Sean

-- 
Sean Dague
http://dague.net

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

[openstack-dev] [barbican] Kilo Mid-Cycle Sprint

2015-01-13 Thread Douglas Mendizabal

Hi openstack-dev!

I just wanted to send a reminder that the Barbican mid-cycle Sprint will be 
taking place on February 16-18 in Austin, TX, which is just five weeks away.  
There’ll be an overlap of a couple of days with the OSSG Mid-Cycle Sprint, 
which will hopefully give us a chance to collaborate remotely with the OSSG 
folks.  For more information and RSVP follow the link:

https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint

Thanks,
-Douglas Mendizábal


Douglas Mendizábal
IRC: redrobot
PGP Key: 245C 7B6F 70E9 D8F3 F5D5  0CC9 AD14 1F30 2D58 923C
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] request spec freeze exception for Add rootwrap-daemon-mode blueprint

2015-01-13 Thread Mike Durnosvistov

Hi,



I’d like to request an spec freeze exception for “Add rootwrap-daemon-mode
blueprint”.


*https://review.openstack.org/#/c/105404/
https://review.openstack.org/#/c/105404/*


This change introduces performance boost for disk and network operations
that

are required to be run with root priviledges in ``nova-compute`` and

``nova-network``.



Thanks,

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

Re: [openstack-dev] [nova] reckoning time for nova ec2 stack

2015-01-13 Thread Steven Hardy

On Tue, Jan 13, 2015 at 10:00:04AM -0600, Matt Riedemann wrote:
 Looks like the fix we merged didn't actually fix the problem. I have a patch
 [1] to uncap the boto requirement on master and it's failing the ec2 tests
 in tempest the same as before.

FWIW, I just re-tested and boto 2.35.1 works fine for me locally, if you
revert my patch it breaks again with Signature not provided errors (for
all ec2 API requests).

If you look at the failures in the log, it actually looks like a different
problem:

EC2ResponseError: EC2ResponseError: 401 Unauthorized

This is not the same as the original error which rejected any request
inside the nova API before even calling keystone with a message like this:

AuthFailure: Signature not provided

AFAICT this means my patch is working, and there's a different problem
affecting only a subset of the ec2 boto tests.

Steve

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

Re: [openstack-dev] [Glance] IRC logging

On 2015-01-13 18:02:41 + (+), Louis Taylor wrote:
 This would be great, since it avoids the scheduling and which
 channel have we moved to questions when a different slot is
 required.

Yep, once every team has its meeting in a separate channel, they'll
all be Tuesday at 1900 UTC and you get to pick which meeting you'll
participate in that week. Also make sure you join all 100+ project
channels in case someone needs to ping you about something in a
random meeting.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-13 Thread Matthias Runge

On 13/01/15 16:31, Jeremy Stanley wrote:
 On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote:
 [...]
 Why were the libraries ripped from the Horizon codebase in the
 first place? It seems to me they belong with the code using it.
 
 I disagree. If those libraries aren't developed as part of Horizon
 then they should not be copied into and distributed as part of its
 source tree. That's code duplication, plain and simple.
 
 I'm in favor of cleaning out all the vendoring of third-party
 libraries in OpenStack projects, but agree that it would be nice to
 find a cross-platform/portable mechanism for handling them.
 
Yes!

Keeping libraries separate, makes maintaining stuff so much easier.

You don't need to persuade me here. I completely agree.

Matthias

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

Re: [openstack-dev] oslo.concurrency 0.4.0 released

2015-01-13 Thread Doug Hellmann


 On Jan 13, 2015, at 12:12 PM, Sean Dague s...@dague.net wrote:
 
 On 01/13/2015 11:46 AM, Matt Riedemann wrote:
 
 
 On 1/13/2015 10:21 AM, Matt Riedemann wrote:
 
 
 On 1/13/2015 9:07 AM, Doug Hellmann wrote:
 The Oslo team is pleased to announce the release of
 oslo.concurrency 0.4.0: oslo.concurrency library
 
 This release removes the use of ConfigFilter when accessing
 configuration options, making it possible for applications
 to set defaults for the lock path option that refer to other
 option values.
 
 This version also adds a new context manager for detecting
 long-running operations and logging when they take longer
 than expected. See oslo_concurrency.watchdog.
 
 For more details, please see the git log history below and
  http://launchpad.net/oslo.concurrency/+milestone/0.4.0
 
 Please report issues through launchpad:
  http://bugs.launchpad.net/oslo.concurrency
 
 
 
 Changes in openstack/oslo.concurrency  0.3.0..0.4.0
 
 3dfefe6 Bump to hacking 0.10
 43dc67e Updated from global requirements
 df35680 add watchdog module
 18bcbe2 Updated from global requirements
 234b007 make time format for processutils match lockutils
 a414266 Correct the translation domain for loading messages
 9066336 Add a reader/writer lock
 9dd6d21 Don't use ConfigFilter for lockutils
 093ed4f Report import warnings where the import occurs
 7c7493f Port processutils to Python 3
 2aafe6f Activate pep8 check that _ is imported
 32bf940 Drop requirements-py3.txt
 deb0152 Updated from global requirements
 d59543d Clean up API documentation
 5de5c42 Workflow documentation is now in infra-manual
 09ab853 Remove noqa from test files
 3de55f3 test compatibility for old imports
 4fd64cb Fix bug link in README.rst
 
   diffstat (except docs and test files):
 
  .gitignore   |   1 -
  CONTRIBUTING.rst |   7 +-
  README.rst   |   2 +-
  oslo/concurrency/__init__.py |   2 +-
  oslo_concurrency/_i18n.py|   2 +-
  oslo_concurrency/lockutils.py| 175 +++-
  oslo_concurrency/opts.py |   2 +-
  oslo_concurrency/processutils.py |  23 +-
  oslo_concurrency/watchdog.py |  66 +
  requirements-py3.txt |  14 -
  requirements.txt |   6 +-
  setup.cfg|   5 +-
  test-requirements.txt|   3 +-
  tests/__init__.py|   2 +-
  tests/test_import.py |  31 +++
  tests/test_lockutils.py  |   4 +-
  tests/test_processutils.py   |  18 +-
  tests/test_warning.py|  32 +++
  tests/test_watchdog.py   |  75 ++
  tox.ini  |   5 -
  31 files changed, 832 insertions(+), 90 deletions(-)
 
   Requirements updates:
 
  diff --git a/requirements.txt b/requirements.txt
  index a27b434..fb89633 100644
  --- a/requirements.txt
  +++ b/requirements.txt
  @@ -9 +9 @@ fixtures=0.3.14
  -oslo.config=1.4.0  # Apache-2.0
  +oslo.config=1.6.0  # Apache-2.0
  @@ -11 +11 @@ oslo.i18n=1.0.0  # Apache-2.0
  -oslo.utils=1.0.0   # Apache-2.0
  +oslo.utils=1.2.0   # Apache-2.0
  @@ -14 +14 @@ six=1.7.0
  -retrying=1.2.2,!=1.3.0 # Apache-2.0
  +retrying=1.2.3,!=1.3.0 # Apache-2.0
  diff --git a/test-requirements.txt b/test-requirements.txt
  index c424655..32cdaae 100644
  --- a/test-requirements.txt
  +++ b/test-requirements.txt
  @@ -5 +5 @@
  -hacking=0.9.1,0.10
  +hacking=0.10.0,0.11
  @@ -7,0 +8 @@ coverage=3.6
  +futures=2.1.6
 
 __
 
 
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 Looks like we probably have a new bug in nova now:
 
 http://goo.gl/i7qa0f
 
 
 Bug is reported with details inline:
 
 https://bugs.launchpad.net/oslo.concurrency/+bug/1410348
 
 Here is a way to address if from purely the nova side -
 https://review.openstack.org/146929

Patch to oslo.concurrency: https://review.openstack.org/#/c/146932/
Patch to nova to use the above: https://review.openstack.org/#/c/146937/

My nova patch would require a new release of oslo.concurrency, which we’ll be 
making as quickly as possible, but in the mean time it makes sense to merge 
Sean’s patch to nova.

Doug

 
   -Sean
 
 -- 
 Sean Dague
 http://dague.net
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Zane Bitter


On 13/01/15 10:01, Jeremy Stanley wrote:

On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:

Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.


I second this recommendation. If Rally wants to depend on things
which are not part of OpenStack and not required to run or test
OpenStack in an official capacity (and since it's not an official
OpenStack project it's entirely within its rights to want to do
that), then forcing it to comply with the list of requirements for
official OpenStack projects is an unnecessarily restrictive choice.


FWIW I don't really agree with this advice. The purpose of 
openstack/requirements is to ensure that it's possible to create a 
distribution of OpenStack without conflicting version requirements, not 
to force every project to use every dependency listed. As such, some 
co-ordination around client libraries for related projects seems like it 
ought to be an uncontroversial addition. (Obviously it's easy to imagine 
potential additions that would legitimately be highly controversial, but 
IMHO this isn't one of them.) Saying that we require people to use our 
tools to get into the club but that our tools are not going to 
accommodate them in any way until they are in sounds a bit too close to 
Go away to my ears.



That said, I'd like to suggest another possible workaround: in Heat we 
keep resource plugins for non-official projects in the /contrib tree, 
and each plugin has it's own setup.cfg and requirements.txt. For example:


http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican

So the user has the option to install each plugin, and it comes with its 
own requirements, independent of the main Heat installation. Perhaps 
Rally could consider something similar.


cheers,
Zane.

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Louis Taylor

On Tue, Jan 13, 2015 at 10:54:13AM -0700, John Griffith wrote:
 I'd echo all the points made regarding logging shouldn't be a
 problem; we're an Open Source project so the idea of our communication
 being public making anybody nervous and not wanting to participate
 seems really off to me.  Yes many of us setup our IRC clients to log,
 some of us record everything anyway; most of all some of us like to go
 back through logs to recap discussions that we had with others
 regarding features, bug fixes etc.  It's a valuable thing to have IMO.

Yes, and transparency in the development is only a good thing in my opinion.

 While I'm at it, do meeting channels make sense for project meetings?  Seems
 like if every project has an IRC channel they could/should probably just have
 their meetings there (just make sure there's a meetbot setup).

This would be great, since it avoids the scheduling and which channel have we
moved to questions when a different slot is required.

Louis


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

[openstack-dev] [Ironic] Bay Area Midcycle

2015-01-13 Thread Jim Rollenhagen

Hi all,

Devananda proposed having a second Ironic midcycle meetup a few weeks
ago.[0] Well, it's happening. :)

To be clear, this is a developer-focused code sprint, *not* a planning
meeting. We want to land code, not write specs or plan roadmaps.

The meetup will be February 11-13 at Rackspace SFO. More details are
on the wiki:
https://wiki.openstack.org/wiki/Sprints/IronicKiloSprint#San_Francisco_Sprint

We'll be adding recommended hotels soon, though we don't have a group
rate. The office is in SOMA; if you're not familiar with the area, that
means using public transit is highly recommended over driving.

Please RSVP here:
https://www.eventbrite.com/e/openstack-ironic-kilo-midcycle-sprint-in-san-francisco-tickets-15184923515

Hope to see everyone there! :)

// jim

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

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

2015-01-13 Thread Tomas Sedovic


On 01/12/2015 07:05 PM, Steven Hardy wrote:

On Mon, Jan 12, 2015 at 04:29:15PM +0100, Tomas Sedovic wrote:

Hey folks,

I did a quick proof of concept for a part of the Stack Breakpoint spec[1]
and I put the does this resource have a breakpoint flag into the metadata
of the resource:

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

I'm not sure where this info really belongs, though. It does sound like
metadata to me (plus we don't have to change the database schema that way),
but can we use it for breakpoints etc., too? Or is metadata strictly for
Heat users and not for engine-specific stuff?


Metadata is supposed to be for template defined metadata (with the notable
exception of server resources where we merge SoftwareDeployment metadata in
to that defined in the template).

So if we're going to use the metadata template interface as a way to define
the breakpoint, this is OK, but do we want to mix the definition of the
stack with this flow control data? (I personally think probably not).

I can think of a couple of alternatives:

1. Use resource_data, which is intended for per-resource internal data, and
set it based on API data passed on create/update (see Resource.data_set)

2. Store the breakpoint metadata in the environment


Ooh, I forgot about resource_data! That sounds perfect, actually.



I think the environment may be the best option, but we'll have to work out
how to best represent a tree of nested stacks (something the spec interface
description doesn't consider AFAICS).


I think we have two orthogonal questions here:

1. How do end users set up and clear breakpoints
2. How does the engine stores breakpoint-related data

As per the spec (and it makes perfect sense to me), users will declare 
breakpoints via the environment and through CLI (which as you say can be 
translated to the environment).


But we ran then read that and just store has_breakpoint in each 
resource's data.


The spec does mention breakpoints on nested stacks briefly:

 For nested stack, the breakpoint would be prefixed with
 the name of the nested template.

I'm assuming we'll need some sort of separator, but the general idea 
sounds okay to me. Something like this, perhaps:


nested_stack/nested_template.yaml/SomeResource




If we use the environment, then no additional API interfaces are needed,
just supporting a new key in the existing data, and python-heatclient can
take care of translating any CLI --breakpoint argument into environment
data.


I also had a chat with Steve Hardy and he suggested adding a STOPPED state
to the stack (this isn't in the spec). While not strictly necessary to
implement the spec, this would help people figure out that the stack has
reached a breakpoint instead of just waiting on a resource that takes a long
time to finish (the heat-engine log and event-list still show that a
breakpoint was reached but I'd like to have it in stack-list and
resource-list, too).

It makes more sense to me to call it PAUSED (we're not completely stopping
the stack creation after all, just pausing it for a bit), I'll let Steve
explain why that's not the right choice :-).


So, I've not got strong opinions on the name, it's more the workflow:

1. User triggers a stack create/update
2. Heat walks the graph, hits a breakpoint and stops.
3. Heat explicitly triggers continuation of the create/update

My argument is that (3) is always a stack update, either a PUT or PATCH
update, e.g we _are_ completely stopping stack creation, then a user can
choose to re-start it (either with the same or a different definition).

So, it _is_ really an end state, as a user might never choose to update
from the stopped state, in which case *_STOPPED makes more sense.

Paused implies the same action as the PATCH update, only we trigger
continuation of the operation from the point we reached via some sort of
user signal.

If we actually pause an in-progress action via the scheduler, we'd have to
start worrying about stuff like token expiry, hitting timeouts, resilience
to engine restarts, etc, etc.  So forcing an explicit update seems simpler
to me.

Steve

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




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

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

2015-01-13 Thread Tomas Sedovic


On 01/13/2015 01:15 AM, Ton Ngo wrote:

 I was also thinking of using the environment to hold the breakpoint,
similarly to parameters.  The CLI and API would process it just like
parameters.

As for the state of a stack hitting the breakpoint, leveraging the
FAILED state seems to be sufficient, we just need to add enough information
to differentiate between a failed resource and a resource at a breakpoint.
Something like emitting an event or a message should be enough to make that
distinction.   Debugger for native program typically does the same thing,
leveraging the exception handling in the OS by inserting an artificial
error at the breakpoint to force a program to stop.  Then the debugger
would just remember the address of these artificial errors to decode the
state of the stopped program.

As for the workflow, instead of spinning in the scheduler waiting for a
signal, I was thinking of moving the stack off the engine as a failed
stack. So this would be an end-state for the stack as Steve suggested, but
without adding a new stack state.   Again, this is similar to how a program
being debugged is handled:  they are moved off the ready queue and their
context is preserved for examination.  This seems to keep the
implementation simple and we don't have to worry about timeout,
performance, etc.  Continuing from the breakpoint then should be similar to
stack-update on a failed stack.  We do need some additional handling, such
as allowing resource in-progress to run to completion instead of aborting.

 For the parallel paths in a template, I am thinking about these
alternatives:
1. Stop after all the current in-progress resources complete, but do not
start any new resources even if there is no dependency.  This should be
easier to implement, but the state of the stack would be non-deterministic.
2. Stop only the paths with the breakpoint, continue all other parallel
paths to completion.  This seems harder to implement, but the stack would
be in a deterministic state and easier for the user to reason with.

To be compatible with convergence, I had suggested to Clint earlier to
add a mode where the convergence engine does not attempt to retry so the
user can debug, and I believe this was added to the blueprint.

Ton,



Regarding the spinning schedule, I get the token expiry and stuff, but 
it is *super simple* to implement.


Literally a while loop that yields. Two lines of code.

And we don't have to change anything in the scheduler or the way we 
handle stack or whatever. Heat already knows how to handle this situation.


Can we start with that implementation (because it's simple and correct) 
and then take it from there? Assuming we can stick to the same API/UI, 
we should be able to change it later when we've documented issues with 
the current approach.



As for parallel execution, I definitely prefer the deterministic 
approach: stop on the breakpoint and everything that depends on it, but 
resolve everything else that you can.


Again, this is trivially handled by Heat already (my patch has no 
special handling for this case). If you want to pause everything, you 
can always set up more breakpoints and advance them either manually or 
all at once with the (to be implemented) stepping functionality.







From:   Steven Hardy sha...@redhat.com
To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
Date:   01/12/2015 02:40 PM
Subject:Re: [openstack-dev] [Heat] Where to keep data about stack
 breakpoints?



On Mon, Jan 12, 2015 at 05:10:47PM -0500, Zane Bitter wrote:

On 12/01/15 13:05, Steven Hardy wrote:

I also had a chat with Steve Hardy and he suggested adding a STOPPED

state

to the stack (this isn't in the spec). While not strictly necessary to
implement the spec, this would help people figure out that the stack

has

reached a breakpoint instead of just waiting on a resource that takes

a long

time to finish (the heat-engine log and event-list still show that a
breakpoint was reached but I'd like to have it in stack-list and
resource-list, too).

It makes more sense to me to call it PAUSED (we're not completely

stopping

the stack creation after all, just pausing it for a bit), I'll let

Steve

explain why that's not the right choice :-).

So, I've not got strong opinions on the name, it's more the workflow:

1. User triggers a stack create/update
2. Heat walks the graph, hits a breakpoint and stops.
3. Heat explicitly triggers continuation of the create/update


Did you mean the user rather than Heat for (3)?


Oops, yes I did.


My argument is that (3) is always a stack update, either a PUT or PATCH
update, e.g we_are_  completely stopping stack creation, then a user can
choose to re-start it (either with the same or a different definition).


Hmmm, ok that's interesting. I have not been thinking of it that way.

I've

always thought of it like this:

Re: [openstack-dev] [TripleO] Meetup Reminder

2015-01-13 Thread Geoff Arnold

Clint: do you have a more precise agenda for the meetup?

I like what Morgan’s proposing for the Keystone midcycle next week:
Day 1: architecture and requirements
Day 2: detail design work
Day 3: hackathon

Cheers,

Geoff

 On Jan 4, 2015, at 12:55 PM, Clint Byrum cl...@fewbar.com wrote:
 
 Happy New Year!
 
 Just a friendly reminder to those of you who are interested in TripleO,
 we have a three-day Meetup scheduled for February 18-20 in Seattle, WA.
 All are welcome, though space is limited to 30 participants. Thus far we
 have 8 people signed up in the etherpad:
 
 https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
 
 Please do add yourself to the list if you intend to come. There is
 information on hotels and we will add any event notifications and agenda
 items that come up.
 
 Thanks, and see you all there!
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread John Griffith

On Tue, Jan 13, 2015 at 10:06 AM, Kuvaja, Erno kuv...@hp.com wrote:

 -Original Message-
 From: Dave Walker [mailto:em...@daviey.com]
 Sent: 13 January 2015 15:10
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Glance] IRC logging

 On 13 January 2015 at 12:32, Kuvaja, Erno kuv...@hp.com wrote:
  I'm heavily against the public logging to the level that I will just leave 
  the
 channel if that will be enabled. My point is not foul language and I do
 understand that there could be some benefits out of it. Personally I think we
 have enough tracked public communication means like ask.openstack.org
 and the mailing lists. IRC is and has always been real time communications
 with defined audience.

  I think the major benefits of this defined audience are:
  1) One does not need to express themselves in a way that is for public. (
 Misunderstandings can be corrected on the fly if needed. ) There is no need
 to explain to anyone reading the logs what you actually meant during the
 conversation month ago.
  2) there is level of confidentiality within that defined audience. (
  For example someone not familiar with the processes thinks they have
  found security vulnerability and comes to the IRC-channel to ask
  second opinion. Those details are not public and that bug can still be
  raised and dealt properly. Once the discussion is logged and the logs
  are publicly available the details are publicly available as well. )
  3) That defined audience does not usually limit content. I have no problem
 to throw my e-mail address, phone number etc. into the channel, I would not
 yell them out publicly.

  For me personally the last point is the biggest problem, professionally the
 second is major concern. I have been using IRC for so long time that I'm not
 willing to take the risk I can't filter myself on my regular channels. 
 Meetings
 are different story as there it is defined time and at least I'm on meeting
 mode that time knowing it will be publicly logged.

  The channels are not locked so anyone can keep a client online and log it
 for themselves if they feel need for it and lots of people do so. There is 
 just
 that big barrier having it within the defined group you can see on the 
 channel
 versus public to anyone.

  As opposed to Cindy's original statement of not wanting to be available 
  off-
 hours, that's solved already: you can set your client to away or not respond.
 It's really common on any IRC network that nick is online while user is not 
 or
 is ignoring that real time outreach by personal preference. No-one
 will/should take that personally or offensive. Not having bouncer/shell to 
 run
 your client is as well personal preference, I doubt anyone can claim they
 could not do it with the options available nowadays.

   - Erno (jokke_) Kuvaja

 Hi,

 I think these concerns are more based around fear, than any real merit.  I
 would suggest that any IRC communication should be treated as public, and
 therefore the idea of bouncing around personal contacts details is pretty
 poor personal security.  If this is required, then using private messages 
 would
 seem to be perfectly suitable.

 A user can join any #openstack-* channel, and not necessarily be a friend of
 the project.  The concerns about security issues should be treated as if they
 have already become public.

 It seems that Openstack currently has around 40 non-meeting channels
 logged[0] and contrasting with the Ubuntu project, there are some 350 public
 logged channels[1] - with the logs going back to 2004.  This has caused 
 little
 issue over the years.

 It would seem logical to introduce project-wide irc logging IMO.  I
 *have* found it useful to search through archives of projects, and find it
 frustrating when this data is not available.

 I really struggle with the idea that contributors of a developer channel do 
 not
 consider themselves to be talking in a public forum, which to me - is the 
 same
 as being logged.  Without this mindset, the channel (and project?) merely
 becomes a cabal developers area.

 [0] http://eavesdrop.openstack.org/irclogs/
 [1] http://irclogs.ubuntu.com/2015/01/01/

 --
 Kind Regards,
 Dave Walker

 I do not have a problem to tell my phone number to someone at my local which 
 is packed with people I do not know and they might hear it, I would have 
 problem with my local if they would start recording all discussions in their 
 premises and posting those publicly in the internet. I don't have even 
 problem X people recording their visits there as long as it stays in their 
 private collection, again same thing I would have problem them putting those 
 records out public and I would try to ensure not being in their vicinity. Why 
 should I/we/one treat IRC differently to any other public venue of discussion?

 - Erno

 __

 OpenStack Development Mailing List

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Kuvaja, Erno

 -Original Message-
 From: Dave Walker [mailto:em...@daviey.com]
 Sent: 13 January 2015 15:10
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Glance] IRC logging

 On 13 January 2015 at 12:32, Kuvaja, Erno kuv...@hp.com wrote:
  I'm heavily against the public logging to the level that I will just leave 
  the
 channel if that will be enabled. My point is not foul language and I do
 understand that there could be some benefits out of it. Personally I think we
 have enough tracked public communication means like ask.openstack.org
 and the mailing lists. IRC is and has always been real time communications
 with defined audience.

  I think the major benefits of this defined audience are:
  1) One does not need to express themselves in a way that is for public. (
 Misunderstandings can be corrected on the fly if needed. ) There is no need
 to explain to anyone reading the logs what you actually meant during the
 conversation month ago.
  2) there is level of confidentiality within that defined audience. (
  For example someone not familiar with the processes thinks they have
  found security vulnerability and comes to the IRC-channel to ask
  second opinion. Those details are not public and that bug can still be
  raised and dealt properly. Once the discussion is logged and the logs
  are publicly available the details are publicly available as well. )
  3) That defined audience does not usually limit content. I have no problem
 to throw my e-mail address, phone number etc. into the channel, I would not
 yell them out publicly.

  For me personally the last point is the biggest problem, professionally the
 second is major concern. I have been using IRC for so long time that I'm not
 willing to take the risk I can't filter myself on my regular channels. 
 Meetings
 are different story as there it is defined time and at least I'm on meeting
 mode that time knowing it will be publicly logged.

  The channels are not locked so anyone can keep a client online and log it
 for themselves if they feel need for it and lots of people do so. There is 
 just
 that big barrier having it within the defined group you can see on the channel
 versus public to anyone.

  As opposed to Cindy's original statement of not wanting to be available off-
 hours, that's solved already: you can set your client to away or not respond.
 It's really common on any IRC network that nick is online while user is not or
 is ignoring that real time outreach by personal preference. No-one
 will/should take that personally or offensive. Not having bouncer/shell to run
 your client is as well personal preference, I doubt anyone can claim they
 could not do it with the options available nowadays.

   - Erno (jokke_) Kuvaja

 Hi,

 I think these concerns are more based around fear, than any real merit.  I
 would suggest that any IRC communication should be treated as public, and
 therefore the idea of bouncing around personal contacts details is pretty
 poor personal security.  If this is required, then using private messages 
 would
 seem to be perfectly suitable.

 A user can join any #openstack-* channel, and not necessarily be a friend of
 the project.  The concerns about security issues should be treated as if they
 have already become public.

 It seems that Openstack currently has around 40 non-meeting channels
 logged[0] and contrasting with the Ubuntu project, there are some 350 public
 logged channels[1] - with the logs going back to 2004.  This has caused little
 issue over the years.

 It would seem logical to introduce project-wide irc logging IMO.  I
 *have* found it useful to search through archives of projects, and find it
 frustrating when this data is not available.

 I really struggle with the idea that contributors of a developer channel do 
 not
 consider themselves to be talking in a public forum, which to me - is the same
 as being logged.  Without this mindset, the channel (and project?) merely
 becomes a cabal developers area.

 [0] http://eavesdrop.openstack.org/irclogs/
 [1] http://irclogs.ubuntu.com/2015/01/01/

 --
 Kind Regards,
 Dave Walker

I do not have a problem to tell my phone number to someone at my local which is 
packed with people I do not know and they might hear it, I would have problem 
with my local if they would start recording all discussions in their premises 
and posting those publicly in the internet. I don't have even problem X people 
recording their visits there as long as it stays in their private collection, 
again same thing I would have problem them putting those records out public and 
I would try to ensure not being in their vicinity. Why should I/we/one treat 
IRC differently to any other public venue of discussion?

- Erno

 __

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: OpenStack-dev-

[openstack-dev] [nova] Request spec freeze exception for “Native HTML5 consoles for VMware”

2015-01-13 Thread Radoslav Gerganov


I’d like to request an exception for:

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

The dependent spec for consolidation of the console APIs is already 
approved, so now we have a clean way to add a new API for VMware.


Thanks,
Rado

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

Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver Specs

2015-01-13 Thread Yapeng Wu

Hi, Sachi,

Please see my inlined replies.

Also, please refer to this link when you try to integrate OpenStack GBP and ODL 
GBP:
https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallODLIntegrationDevstack


Yapeng

From: Sachi Gupta [mailto:sachi.gu...@tcs.com]
Sent: Tuesday, January 13, 2015 4:02 AM
To: OpenStack Development Mailing List (not for usage questions); 
groupbasedpolicy-...@lists.opendaylight.org; Yapeng Wu
Cc: bu...@noironetworks.com
Subject: Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver 
Specs

Hi,

While working on the integration of Openstack With ODL GBP, I have the below 
queries:

  1.  Endpoint-group Create: When I create a new policy-target-group from 
Openstack say gbp target-policy-group-create group1, it internally creates a 
l2.policy which includes the creation of the network and subnet. Meaning 
creation of EPG will create Network and subnet implicitly in Openstack and also 
the corresponding EPG, subnet, l3-context, l2-flood-domain, l2-bridge-domain 
will be created in the ODL GBP. So during the above EPG creation, neutron 
network and subnet call will come to the neutron northbound of ODL or only to 
ODL GBP??
[Yapeng] First, when creating policy-target-group, you need to give 
“provided-policy-rule-sets” or “consumed-policy-rule-sets” parameter. Currently 
we don’t support policy-target-group update. Second, neutron network and subnet 
call won’t go to ODL.

  1.

  1.  In ODL, there is no Endpoint create API, instead there is an API to 
register the endpoints. So what is the sync between the OS and ODL for Endpoint 
create and register.?
[Yapeng] The current working scheme is as follow: ODL GBP has new APIs for 
openstack-endpoint register and unregister supports.[1][2] When Openstack GBP 
creates policy-target, a neutron port will be created by implicit driver, 
openstack-endpoint register API will be invoked and the OVS tap-port-id will be 
passed as parameter to ODL GBP. Later when VM is booted, the OVS tap-port-id 
will be populated on openvswitch, this will trigger ODL to update ovs flow 
tables.

[1] https://git.opendaylight.org/gerrit/#/c/13554/
[2] https://git.opendaylight.org/gerrit/#/c/13896/


Thanks  Regards
Sachi Gupta



From:Yapeng Wu yapeng...@huawei.com
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:01/12/2015 09:01 PM
Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL
PolicyDriverSpecs




Hello, Sachi,

They both works. “End point group” has been renamed to “policy target group”. 
It is recommended to use “gbp policy-target-group-create”.

Yapeng


From: Sachi Gupta [mailto:sachi.gu...@tcs.com]
Sent: Monday, January 12, 2015 7:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver 
Specs

Hi,

Can anyone explain the difference between gbp group-create and gbp 
policy-target-group-create??

I think both these are working same.

Thanks  Regards
Sachi Gupta




From:Sumit Naiksatam sumitnaiksa...@gmail.com
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:11/26/2014 01:35 PM
Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy 
DriverSpecs





Hi, This GBP spec is currently being worked on:
https://review.openstack.org/#/c/134285/

It will be helpful if you can add [Policy][Group-based-policy] in
the subject of your emails, so that the email gets characterized
correctly.

Thanks,
~Sumit.

On Tue, Nov 25, 2014 at 4:27 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hey All,

 I need to understand the interaction between the Openstack GBP and the
 Opendaylight GBP project which will be done by ODL Policy driver.

 Can someone provide me with specs of ODL Policy driver for making my
 understanding on call flow.


 Thanks  Regards
 Sachi Gupta

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. 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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread John Griffith

On Tue, Jan 13, 2015 at 11:25 AM, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2015-01-13 18:02:41 + (+), Louis Taylor wrote:
 This would be great, since it avoids the scheduling and which
 channel have we moved to questions when a different slot is
 required.

 Yep, once every team has its meeting in a separate channel, they'll
 all be Tuesday at 1900 UTC and you get to pick which meeting you'll
Ahh yes, good point

 participate in that week. Also make sure you join all 100+ project
 channels in case someone needs to ping you about something in a
 random meeting.
Well that's really no different than what I have to do today anyway :)

 --
 Jeremy Stanley

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

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

Re: [openstack-dev] [Ironic] Bay Area Midcycle

2015-01-13 Thread Jim Rollenhagen

On Tue, Jan 13, 2015 at 10:28:08AM -0800, Jim Rollenhagen wrote:
 Hi all,
 
 Devananda proposed having a second Ironic midcycle meetup a few weeks
 ago.[0] Well, it's happening. :)
 
Oops, forgot my link here:
http://lists.openstack.org/pipermail/openstack-dev/2014-December/053618.html

// jim

 To be clear, this is a developer-focused code sprint, *not* a planning
 meeting. We want to land code, not write specs or plan roadmaps.
 
 The meetup will be February 11-13 at Rackspace SFO. More details are
 on the wiki:
 https://wiki.openstack.org/wiki/Sprints/IronicKiloSprint#San_Francisco_Sprint
 
 We'll be adding recommended hotels soon, though we don't have a group
 rate. The office is in SOMA; if you're not familiar with the area, that
 means using public transit is highly recommended over driving.
 
 Please RSVP here:
 https://www.eventbrite.com/e/openstack-ironic-kilo-midcycle-sprint-in-san-francisco-tickets-15184923515
 
 Hope to see everyone there! :)
 
 // jim
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

2015-01-13 Thread Andreas Jaeger

On 01/13/2015 11:16 PM, Tomasz Napierala wrote:
 
 On 13 Jan 2015, at 10:51, Przemyslaw Kaminski pkamin...@mirantis.com wrote:

 For example

 https://www.python.org/download/releases/2.6.9/

 All official maintenance for Python 2.6, including security patches,
 has ended.

 https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS

 Especially the SSL stuff is interesting

 http://bugs.python.org/issue22935
 
 This looks like final word here. We cannot provide software, that has no 
 security support.

Distributors do support it as part of their offering. Shipping python
2.6 from source as is is indeed nothing you want to do,

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


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

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

2015-01-13 Thread Bartłomiej Piotrowski


On 01/13/2015 11:16 PM, Tomasz Napierala wrote:



On 13 Jan 2015, at 10:51, Przemyslaw Kaminski pkamin...@mirantis.com wrote:

For example

https://www.python.org/download/releases/2.6.9/

All official maintenance for Python 2.6, including security patches,
has ended.

https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS

Especially the SSL stuff is interesting

http://bugs.python.org/issue22935


This looks like final word here. We cannot provide software, that has no 
security support.

Regards,



I can hardly see it as a justification for maintaining yet another 
package on our own while Red Hat is supposed to provide backports of 
security fixes to python 2.6 until 2020.


I wanted to hear exact use cases of 2.7 features that allow us to 
accomplish things easier than it is now with 2.6. As Doug already said, 
clients and Oslo libraries will maintain compatibility with 2.6. So what 
is the real gain?


Regards,
Bartłomiej

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

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

2015-01-13 Thread Kamil Sambor

Tomasz we are not using ssl in our client so now we not gain anything from
moving to 2.7 .

Best regards,
– Kamil S.

On Wed, Jan 14, 2015 at 8:32 AM, Bartłomiej Piotrowski 
bpiotrow...@mirantis.com wrote:

 On 01/13/2015 11:16 PM, Tomasz Napierala wrote:


  On 13 Jan 2015, at 10:51, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

 For example

 https://www.python.org/download/releases/2.6.9/

 All official maintenance for Python 2.6, including security patches,
 has ended.

 https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS

 Especially the SSL stuff is interesting

 http://bugs.python.org/issue22935


 This looks like final word here. We cannot provide software, that has no
 security support.

 Regards,


 I can hardly see it as a justification for maintaining yet another package
 on our own while Red Hat is supposed to provide backports of security fixes
 to python 2.6 until 2020.

 I wanted to hear exact use cases of 2.7 features that allow us to
 accomplish things easier than it is now with 2.6. As Doug already said,
 clients and Oslo libraries will maintain compatibility with 2.6. So what is
 the real gain?

 Regards,
 Bartłomiej


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

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

[openstack-dev] [Nova] Requesting spec freeze exception for cells-instance-migration

2015-01-13 Thread Andrew Laski


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

This is part of the infrastructure buildup for Cells v2 which is 
priority work in Kilo.  It is needed to get closer to a working cellsv2 
prototype.


This work is focused on methods for populating the instance_mapping 
table with data about current instances.  It is an important piece of 
the migration path to cells v2 so being able to continue working on it 
this cycle will help keep momentum on the cells v2 effort. Thanks.


-Andrew

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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

On 01/13/2015 02:10 PM, Jay Pipes wrote:
 On 01/13/2015 12:39 PM, Zane Bitter wrote:
 On 13/01/15 10:01, Jeremy Stanley wrote:
 On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
 Why doesn't rally just remove itself from projects.txt, then there
 would be no restrictions on what it adds.

 I second this recommendation. If Rally wants to depend on things
 which are not part of OpenStack and not required to run or test
 OpenStack in an official capacity (and since it's not an official
 OpenStack project it's entirely within its rights to want to do
 that), then forcing it to comply with the list of requirements for
 official OpenStack projects is an unnecessarily restrictive choice.

 FWIW I don't really agree with this advice. The purpose of
 openstack/requirements is to ensure that it's possible to create a
 distribution of OpenStack without conflicting version requirements, not
 to force every project to use every dependency listed. As such, some
 co-ordination around client libraries for related projects seems like it
 ought to be an uncontroversial addition. (Obviously it's easy to imagine
 potential additions that would legitimately be highly controversial, but
 IMHO this isn't one of them.) Saying that we require people to use our
 tools to get into the club but that our tools are not going to
 accommodate them in any way until they are in sounds a bit too close to
 Go away to my ears.
 
 +1

I think as we grow global-requirements probably needs to be broken up
into functional lists. What's allowed in base-iass, what's allowed in
application services, what's allowed in docs, etc, etc.

The complexity of keeping the g-r list actually working goes up sort of
n^2 as the size of it, because pip doesn't have a real solver. This is a
barely functional set of plate spinning so just add everything misses
the point that the breaks get more and more difficult to unwind.

If someone is up for stepping up and contributing to breaking up into
domains, please do. But I think while this remains a global list we
really do need to be a bit careful here.

 That said, I'd like to suggest another possible workaround: in Heat we
 keep resource plugins for non-official projects in the /contrib tree,
 and each plugin has it's own setup.cfg and requirements.txt. For example:

 http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican

 So the user has the option to install each plugin, and it comes with its
 own requirements, independent of the main Heat installation. Perhaps
 Rally could consider something similar.
 
 Seems like a very reasonable solution to me.
 
 Thanks for bringing it up,
 -jay
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Glance] IRC logging

On 2015-01-13 13:59:26 -0500 (-0500), Sean Dague wrote:
 Which is a really important point. I hang in the 3 meeting channels,
[...]

Ahem, it's four now BTW. ;)
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Glance] IRC logging

On 01/13/2015 01:25 PM, Jeremy Stanley wrote:
 On 2015-01-13 18:02:41 + (+), Louis Taylor wrote:
 This would be great, since it avoids the scheduling and which
 channel have we moved to questions when a different slot is
 required.
 
 Yep, once every team has its meeting in a separate channel, they'll
 all be Tuesday at 1900 UTC and you get to pick which meeting you'll
 participate in that week. Also make sure you join all 100+ project
 channels in case someone needs to ping you about something in a
 random meeting.

Which is a really important point. I hang in the 3 meeting channels, and
-dev. And I can manage about 6 - 8 openstack channels after that for
projects that I'm actively involved in. After that, it's just too much
distraction.

The meeting channels are a good leveler to ensure that people that might
need to be pinged can be around, or at least see things afterwards.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Jay Pipes


On 01/13/2015 12:39 PM, Zane Bitter wrote:

On 13/01/15 10:01, Jeremy Stanley wrote:

On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:

Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.


I second this recommendation. If Rally wants to depend on things
which are not part of OpenStack and not required to run or test
OpenStack in an official capacity (and since it's not an official
OpenStack project it's entirely within its rights to want to do
that), then forcing it to comply with the list of requirements for
official OpenStack projects is an unnecessarily restrictive choice.


FWIW I don't really agree with this advice. The purpose of
openstack/requirements is to ensure that it's possible to create a
distribution of OpenStack without conflicting version requirements, not
to force every project to use every dependency listed. As such, some
co-ordination around client libraries for related projects seems like it
ought to be an uncontroversial addition. (Obviously it's easy to imagine
potential additions that would legitimately be highly controversial, but
IMHO this isn't one of them.) Saying that we require people to use our
tools to get into the club but that our tools are not going to
accommodate them in any way until they are in sounds a bit too close to
Go away to my ears.


+1


That said, I'd like to suggest another possible workaround: in Heat we
keep resource plugins for non-official projects in the /contrib tree,
and each plugin has it's own setup.cfg and requirements.txt. For example:

http://git.openstack.org/cgit/openstack/heat/tree/contrib/heat_barbican

So the user has the option to install each plugin, and it comes with its
own requirements, independent of the main Heat installation. Perhaps
Rally could consider something similar.


Seems like a very reasonable solution to me.

Thanks for bringing it up,
-jay

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

Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)

2015-01-13 Thread David Kranz

On 01/08/2015 05:34 AM, Ken'ichi Ohmichi wrote:

Hi,

Unfortunately, I cannot join tomorrow meeting.
So I'd like to share the progress of tempest-lib RestClient
dev before the meeting.

As Paris summit consensus, we have a plan to move RestClient
from tempest to tempest-lib for moving API tests to each project
in the future. And we are cleaning the code of RestClient up in
tempest now. The progress will be complete with some patches[1].
After merging them, I will move the code to tempest-lib.

This dev requires many patches/reviews, and many people have
already worked well. Thank you very much for helping this dev,
and I appreciate continuous effort.

[1]:
https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:rest-client,n,z

Thanks
Ken Ohmichi
Ken, I have a question about this. The end goal is to move the service
clients and so they must also be free of CONF references. But your
current changes create a ServiceClient that still uses CONF in its
constructor rather than taking the arguments. So I'm not sure what
ServiceClient is adding. I also think whatever class the service clients
are inheriting cannot contain CONF values?

I was assuming the final arrangement would be something like, using
neutron as an example:

tempest_lib.RestClient(all needed args)
tempest_lib.NeutronClient(all needed args to super)
tempest.NeutronClient(pass CONF values to super)

and where the tempest_lib neutron client would be used by neutron tests
either through inheritance or delegation. Is that different than your
vision?

-David

---

2015-01-08 2:44 GMT+09:00 David Kranz dkr...@redhat.com:

Hi everyone,

Just a quick reminder that the weekly OpenStack QA team IRC meeting will be
tomorrow Thursday, January 8th at 22:00 UTC in the #openstack-meeting
channel.

The agenda for tomorrow's meeting can be found here:
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting
Anyone is welcome to add an item to the agenda.

It's also worth noting that a few weeks ago we started having a regular
dedicated Devstack topic during the meetings. So if anyone is interested in
Devstack development please join the meetings to be a part of the
discussion.

To help people figure out what time 22:00 UTC is in other timezones
tomorrow's
meeting will be at:

17:00 EST
07:00 JST
08:30 ACDT
23:00 CET
16:00 CST
14:00 PST

-David Kranz

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

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

Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was Meeting Thursday January 8th at 22:00 UTC)

2015-01-13 Thread Kenichi Oomichi

Hi David,

-Original Message-
From: David Kranz [mailto:dkr...@redhat.com]
Sent: Wednesday, January 14, 2015 4:25 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [QA] Moving tempest clients to tempest-lib (was
Meeting Thursday January 8th at 22:00 UTC)

On 01/08/2015 05:34 AM, Ken'ichi Ohmichi wrote:
Hi,

Unfortunately, I cannot join tomorrow meeting.
So I'd like to share the progress of tempest-lib RestClient
dev before the meeting.

This dev requires many patches/reviews, and many people have
already worked well. Thank you very much for helping this dev,
and I appreciate continuous effort.

[1]:
https://review.openstack.org/#/q/status:open+project:openstack/tempest+branch:master+topic:rest-client,n,z

Thanks
Ken Ohmichi

Ken, I have a question about this. The end goal is to move the service
clients and so they must also be free of CONF references. But your
current changes create a ServiceClient that still uses CONF in its
constructor rather than taking the arguments. So I'm not sure what
ServiceClient is adding. I also think whatever class the service clients
are inheriting cannot contain CONF values?

I was assuming the final arrangement would be something like, using
neutron as an example:

tempest_lib.RestClient(all needed args)
tempest_lib.NeutronClient(all needed args to super)
tempest.NeutronClient(pass CONF values to super)

and where the tempest_lib neutron client would be used by neutron tests
either through inheritance or delegation. Is that different than your
vision?

Yeah, that is the same as my vision about service clients.
At this time, I just move CONF values to service clients just for RestClient.
But maybe we will change tempest/clients.py to the following for passing CONF
values:

- self.network_client = NetworkClientJSON(self.auth_provider)
+ self.network_client = NetworkClientJSON(self.auth_provider,
+ CONF.network.catalog_type,
+ CONF.network.region or
CONF.identity.region,
+
endpoint_type=CONF.network.endpoint_type,
+
build_interval=CONF.network.build_interval,
+
build_timeout=CONF.network.build_timeout,
+
disable_ssl_certificate_validation=CONF.identity.disable_ssl_certificate_validation,
+
ca_certs=CONF.identity.ca_certificates_file,
+
trace_requests=CONF.debug.trace_requests)

That is the next step for moving service clients to tempest-lib.

Thanks
Ken'ichi Ohmichi

Re: [openstack-dev] [glance] Replication on image create

2015-01-13 Thread Jay Pipes

On 01/13/2015 04:55 PM, Boden Russell wrote:

Looking for some feedback from the glance dev team on a potential BP…

The use case I’m trying to solve is —

As an admin, I want my glance image bits replicated to multiple store
locations (of the same store type) during a glance create operation.

For example, I have 3 HTTP based backend locations I want to store my
glance image bits on. When I create / upload a new glance image, I want
those bits put onto all 3 HTTP based locations and have the image's
'locations' metadata properly reflect all stored locations.

There are obviously multiple approaches to getting this done.

[1] Allow per glance store drivers the ability to manage config and
connectivity to multiple backends. For example in the glance-api.conf:

[DEFAULT]
store_backends = http1,http2,http3
...
[http1]
# http 1 backend props
...
[http2]
# http 2 backend props
...
[http2]
# http 2 backend props
...

And then in the HTTP store driver use a configuration approach like
cinder multi-backend does (e.g.:
https://github.com/openstack/cinder/blob/2f09c3031ef2d2db598ec4c56f6127e33d29b2cc/cinder/volume/configuration.py#L52).
Here, the store driver handles all the logic w/r/t pushing the image
bits to all backends, etc..

The problem with this solution is that the HTTP Glance storage backend
is readonly. You cannot upload an image to Glance using the http backend.

[2] A separate (3rd party) process which handles the image replication
and location metadata updates... For example listens for the glance
notification on create and then takes the steps necessary to replicate
the bits elsewhere and update the image metadata (locations).

This is the solution that I would recommend. Frankly, this kind of
replication should be an async out-of-band process similar to
bittorrent. Just have bittorrent or rsync or whatever replicate the
image bits to a set of target locations and then call the
glanceclient.v2.client.images.add_location() method:

https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211

to add the URI of the replicated image bits.

[3] etc...

In a prototype I implemented #1 which can be done with no impact outside
of the store driver code itself.

I'm not entirely sure how you did that considering the http storage
backend is readonly. Are you saying you implemented the add() method for
the glance_store._drivers.http.Store class?

Best,
-jay

I prefer #1 over #2 given approach #2

may need pull the image bits back down from the initial location in
order to push for replication; additional processing.

Is the dev team adverse to option #1 for the store driver's who wish to
implement it and / or what are the other (preferred) options here?

Thank you,
- boden

Re: [openstack-dev] [Heat] Where to keep data about stack breakpoints?

2015-01-13 Thread Ton Ngo

Hi Tomas,
 I think your patch is a great start so we can prototype quickly;  I am
trying it out right now.  We can break up the implementation into several
parts that can be updated more or less independently based on the feedback.
Ton,

From:   Tomas Sedovic tsedo...@redhat.com
To: openstack-dev@lists.openstack.org
Date:   01/13/2015 09:20 AM
Subject:Re: [openstack-dev] [Heat] Where to keep data about stack
breakpoints?

On 01/13/2015 01:15 AM, Ton Ngo wrote:
  I was also thinking of using the environment to hold the breakpoint,
 similarly to parameters.  The CLI and API would process it just like
 parameters.

 As for the state of a stack hitting the breakpoint, leveraging the
 FAILED state seems to be sufficient, we just need to add enough
information
 to differentiate between a failed resource and a resource at a
breakpoint.
 Something like emitting an event or a message should be enough to make
that
 distinction.   Debugger for native program typically does the same thing,
 leveraging the exception handling in the OS by inserting an artificial
 error at the breakpoint to force a program to stop.  Then the debugger
 would just remember the address of these artificial errors to decode the
 state of the stopped program.

 As for the workflow, instead of spinning in the scheduler waiting for
a
 signal, I was thinking of moving the stack off the engine as a failed
 stack. So this would be an end-state for the stack as Steve suggested,
but
 without adding a new stack state.   Again, this is similar to how a
program
 being debugged is handled:  they are moved off the ready queue and their
 context is preserved for examination.  This seems to keep the
 implementation simple and we don't have to worry about timeout,
 performance, etc.  Continuing from the breakpoint then should be similar
to
 stack-update on a failed stack.  We do need some additional handling,
such
 as allowing resource in-progress to run to completion instead of
aborting.

  For the parallel paths in a template, I am thinking about these
 alternatives:
 1. Stop after all the current in-progress resources complete, but do not
 start any new resources even if there is no dependency.  This should be
 easier to implement, but the state of the stack would be
non-deterministic.
 2. Stop only the paths with the breakpoint, continue all other parallel
 paths to completion.  This seems harder to implement, but the stack would
 be in a deterministic state and easier for the user to reason with.

 To be compatible with convergence, I had suggested to Clint earlier
to
 add a mode where the convergence engine does not attempt to retry so the
 user can debug, and I believe this was added to the blueprint.

 Ton,

Regarding the spinning schedule, I get the token expiry and stuff, but
it is *super simple* to implement.

Literally a while loop that yields. Two lines of code.

And we don't have to change anything in the scheduler or the way we
handle stack or whatever. Heat already knows how to handle this situation.

Can we start with that implementation (because it's simple and correct)
and then take it from there? Assuming we can stick to the same API/UI,
we should be able to change it later when we've documented issues with
the current approach.

As for parallel execution, I definitely prefer the deterministic
approach: stop on the breakpoint and everything that depends on it, but
resolve everything else that you can.

Again, this is trivially handled by Heat already (my patch has no
special handling for this case). If you want to pause everything, you
can always set up more breakpoints and advance them either manually or
all at once with the (to be implemented) stepping functionality.

 From:  Steven Hardy sha...@redhat.com
 To:OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
 Date:  01/12/2015 02:40 PM
 Subject:   Re: [openstack-dev] [Heat] Where to keep data about
stack
  breakpoints?

 On Mon, Jan 12, 2015 at 05:10:47PM -0500, Zane Bitter wrote:
 On 12/01/15 13:05, Steven Hardy wrote:
 I also had a chat with Steve Hardy and he suggested adding a STOPPED
 state
 to the stack (this isn't in the spec). While not strictly necessary
to
 implement the spec, this would help people figure out that the stack
 has
 reached a breakpoint instead of just waiting on a resource that takes
 a long
 time to finish (the heat-engine log and event-list still show that a
 breakpoint was reached but I'd like to have it in stack-list and
 resource-list, too).

 It makes more sense to me to call it PAUSED (we're not completely
 stopping
 the stack creation after all, just pausing it for a bit), I'll let
 Steve
 explain why that's not the right choice :-).
 So, I've not got strong opinions on the name, it's more the workflow:

 1. User triggers a stack create/update
 2. Heat walks the graph, hits a

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Serg Melikyan

I support this, it will help to not break compatibility with
global-requirements for sole purpose to include python client for other
stackforge project.

On Tue, Jan 13, 2015 at 12:14 AM, Boris Pavlovic bo...@pavlovic.me wrote:

 Hello TC,

 I would like to propose to allow adding all python-clients from stackforge
 (that are regarding global-requirements) to global requirements.

 It doesn't cost anything and simplifies life for everybody on stackforge.

 P.S. We already have billions libs in global requirements that aren't even
 on stackforge.
 Having few more or less doesn't make any sense...


 Best regards,
 Boris Pavlovic

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




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

+7 (495) 640-4904, 0261
+7 (903) 156-0836
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver Specs

2015-01-13 Thread Sachi Gupta

Hi,

While working on the integration of Openstack With ODL GBP, I have the 
below queries:

Endpoint-group Create: When I create a new policy-target-group from 
Openstack say gbp target-policy-group-create group1, it internally 
creates a l2.policy which includes the creation of the network and subnet. 
Meaning creation of EPG will create Network and subnet implicitly in 
Openstack and also the corresponding EPG, subnet, l3-context, 
l2-flood-domain, l2-bridge-domain will be created in the ODL GBP. So 
during the above EPG creation, neutron network and subnet call will come 
to the neutron northbound of ODL or only to ODL GBP??

In ODL, there is no Endpoint create API, instead there is an API to 
register the endpoints. So what is the sync between the OS and ODL for 
Endpoint create and register.?


Thanks  Regards
Sachi Gupta



From:   Yapeng Wu yapeng...@huawei.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:   01/12/2015 09:01 PM
Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL 
Policy  Driver  Specs



Hello, Sachi,
 
They both works. “End point group” has been renamed to “policy target 
group”. It is recommended to use “gbp policy-target-group-create”.
 
Yapeng
 
 
From: Sachi Gupta [mailto:sachi.gu...@tcs.com] 
Sent: Monday, January 12, 2015 7:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy 
Driver Specs
 
Hi, 

Can anyone explain the difference between gbp group-create and gbp 
policy-target-group-create?? 

I think both these are working same. 

Thanks  Regards
Sachi Gupta




From:Sumit Naiksatam sumitnaiksa...@gmail.com 
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org 
Date:11/26/2014 01:35 PM 
Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL 
Policy DriverSpecs 




Hi, This GBP spec is currently being worked on:
https://review.openstack.org/#/c/134285/

It will be helpful if you can add [Policy][Group-based-policy] in
the subject of your emails, so that the email gets characterized
correctly.

Thanks,
~Sumit.

On Tue, Nov 25, 2014 at 4:27 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hey All,

 I need to understand the interaction between the Openstack GBP and the
 Opendaylight GBP project which will be done by ODL Policy driver.

 Can someone provide me with specs of ODL Policy driver for making my
 understanding on call flow.


 Thanks  Regards
 Sachi Gupta

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. 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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Cross-Project meeting, Tue January 13th, 21:00 UTC

2015-01-13 Thread Thierry Carrez

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a (probably short) cross-project meeting today at 21:00 UTC,
with the following agenda:

* CLI Sorting Argument Guidelines [1]
* Proposed Vancouver Design Summit format [2]
* Open discussion  announcements

[1] https://review.openstack.org/#/c/145544/
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054122.html

See you there !

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

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Kilo devstack issue

2015-01-13 Thread Pasquale Porreca

I had the same issue and, as John Griffith pointed out, it is due to the
fact n-novnvc service is no more a default service in devstack. You need
to enable the service in local.conf file by adding the line

|enable_service n-novnc|


On 01/12/15 20:21, John Griffith wrote:
 On Mon, Jan 12, 2015 at 10:03 AM, Nikesh Kumar Mahalka
 nikeshmaha...@vedams.com wrote:
 Hi,
 We deployed a kilo devstack on ubuntu 14.04 server.
 We successfully launched a instance from dashboard, but we are unable to
 open console from dashboard for instance.Also instacne is unable to get ip

 Below is link for local.conf
 http://paste.openstack.org/show/156497/



 Regards
 Nikesh

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

 Correct, see this thread:
 http://lists.openstack.org/pipermail/openstack-dev/2015-January/054157.html

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

-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Martin Geisler

Kuvaja, Erno kuv...@hp.com writes:

 I'm heavily against the public logging to the level that I will just
 leave the channel if that will be enabled. My point is not foul
 language and I do understand that there could be some benefits out of
 it. Personally I think we have enough tracked public communication
 means like ask.openstack.org and the mailing lists. IRC is and has
 always been real time communications with defined audience.

For what it's worth, we've had the same discussion in the Mercurial
community and decided no *not* enable public logging on the IRC channel.

The arguments are similar to what you say, plus people said that they
would behave differently if the channels were logged in public.

We don't have problems with foul language, but people felt that they
would be more restricted if everything they write end up in a log like
on a mailing list.

Some people said that they would be less active on the list during their
work hours -- not because it was strictly forbidden for them to spend
some time help an open source project (and everybody needs a break once
in a while), but because they felt it could look strange if their boss
sees a full archive of their activity.

It is similar to how I'm allowed to use the Internet for personal things
at work (as long as I do it in a reasonable amount) but I don't want to
hand over a complete log to my boss.

So people should be aware that enabling logging and putting a notice
about it in the channel topic is likely to affect the behavior. It will
have some pros (people can search the logs for old discussions) and some
cons (people might not bother posting a summary of an IRC discussion on
the mailing list).

-- 
Martin Geisler

http://google.com/+MartinGeisler


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

Re: [openstack-dev] Fw: [Heat] Enhancement on addition to heat template with glance

2015-01-13 Thread Steven Hardy

On Tue, Jan 13, 2015 at 05:50:57PM +0530, Anusha Rayani wrote:
Hello Steve,
 
Thanks for your response.
 
Yes,we do have an resource class defined in Heat to upload an image, but
in this case we can only use the image from URL where as using --file 
option to glance image-create we can upload a disk image from local
filesystem to glance.
$ glance image-create
  --file FILE Local file that contains disk image to be uploaded
during creation. Alternatively, images can be
passed
to the client via stdin.
 
However GlanceImage class has only an option to upload the image from
location/URL.

Heat resources are a representation of the underlying API, you're referring
to a convenience function which is part of python-glanceclient, which can
read a local file and upload the binary image data to the glance API.

I don't think having such an interface to the Heat resource makes sense,
for the following reasons:

1. The heat service has no access to your local filesystem, so you'd have
to upload the entire binary image to heat, then we'd have to upload it
again to glance, this is a huge and unjustified overhead IMO.

2. There are several existing patterns which solve this, such as:
- uploading the image via glance image-create then passing the ID in to
  the heat stack as a parameter
- hosting the image in swift or a webserver and passing the URL to heat
  then consuming it via GlanceImage

Can you explain why uploading the image to heat would be worthwhile, vs one
of the other interfaces I just mentioned?

Thanks,

Steve

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

Re: [openstack-dev] [horizon] static files handling, bower/

On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
[...]
 But, as far as I understand, node.js will become a development
 requirement (and most probably a requirement for testing), but not for
 deployment.
[...]

A requirement for testing _is_ a requirement for deployment. If it's
not tested, it's broken. If you're deploying software on a platform
where it can't be tested then you're simply _hoping_ that it's not
broken, and that is almost certainly a false hope.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Fuel][client][IMPORTANT] Making Fuel Client a separate project

2015-01-13 Thread Roman Prykhodchenko

Folks,

this is another status update.

The patch for moving python-fuelclient to a separate project has been merged. 
At the moment Stackforge repository, a Gerrit project and all Gerrit groups 
have been created. There are two guys in the core group: I and Dmitri Pyzhov 
(dpyz...@mirantis.com mailto:dpyz...@mirantis.com). You can obtain the 
sources from https://github.com/stackforge/python-fuelclient 
https://github.com/stackforge/python-fuelclient.
I kindly ask authors of all changes to Fuel Client to start moving them to the 
new project.
At the moment I’m working on enabling the same testing process in FuelCI, 
testing in OpenStack CI will be enabled later because that requires some 
refactoring of the existing tests in python-fuelclient.

Stay tuned.


- romcheg

 12 січ. 2015 о 12:44 Roman Prykhodchenko m...@romcheg.me написав(ла):
 
 Hi folks!
 
 This is a status update.
 Right now the patch for creating a new project on Stackforge is blocked by a 
 bug in Zuul [1] which is actually a bug in python-daemon, the patch for this 
 is already published [2] and waiting for being approved.
 After the patch is merged and all projects and groups are created I will file 
 a request to perform initial setup of core groups. Once they are created it 
 will be possible to land new patches.
 Meanwhile OSCI team is working [3] on adjusting build system to use 
 python-fuelclient from PyPi [4].
 Stay tuned for further updates.
 
 References:
 Zuul’s tests fail with dependencies error 
 https://storyboard.openstack.org/#!/story/2000107 
 https://storyboard.openstack.org/#!/story/2000107
 Pin python-daemon2.0 https://review.openstack.org/#/c/146350/ 
 https://review.openstack.org/#/c/146350/
 Create repositories for python-fuelclient package 
 https://bugs.launchpad.net/fuel/+bug/1409673 
 https://bugs.launchpad.net/fuel/+bug/1409673
 python-fuelclient on PyPi https://pypi.python.org/pypi/python-fuelclient 
 https://pypi.python.org/pypi/python-fuelclient
 
 
 9 січ. 2015 о 15:14 Roman Prykhodchenko m...@romcheg.me 
 mailto:m...@romcheg.me написав(ла):
 
 Hi folks,
 
 according to the Fuel client refactoring plan [1] it’s necessary to move it 
 out to a separate repository on Stackforge.
 
 The process of doing that consists of two major steps:
 - Landing a patch [2] to project-config for creating a new Stackforge project
 - Creating an initial core group for python-fuelclient
 - Moving all un-merged patches from fuel-web to python-fuelclient gerrit repo
 
 The first step of this process has already been started so I kindly ask all 
 fuelers to DO NOT MERGE any new patches to fuel-web IF THEY DO touch 
 fuelclient folder.
 After the project is set up I will let everyone know about that and will 
 tell what to do after that so I encourage all interested people to check 
 this thread once in a while.
 
 
 # References:
 
 1. Re-thinking Fuel Client https://review.openstack.org/#/c/145843 
 https://review.openstack.org/#/c/145843
 2. Add python-fuelclient to Stackforge 
 https://review.openstack.org/#/c/145843 
 https://review.openstack.org/#/c/145843
 
 
 - romcheg
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org 
 mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron][L3][Devstack] Bug during delete loating Ps?

2015-01-13 Thread Kevin Benton

Do you mean like this?[1] :)

https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1168

On Tue, Jan 13, 2015 at 1:38 AM, Miguel Ángel Ajo majop...@redhat.com
wrote:

 That’s nice Sunil, can you send the patch for review on gerrit?

 May be it’s also interesting to avoid sending a notify_routers_updated
 when there are
 no router_ids.


 Miguel Ángel Ajo

 On Sunday, 11 de January de 2015 at 08:42, Sunil Kumar wrote:

  This trivial patch fixes the tracebacks:

 $ cat disassociate_floating_ips.patch
 --- neutron/db/l3_db.py.orig2015-01-10 22:20:30.101506298 -0800
 +++ neutron/db/l3_db.py 2015-01-10 22:24:18.111479818 -0800
 @@ -1257,4 +1257,4 @@

  def notify_routers_updated(self, context, router_ids):
  super(L3_NAT_db_mixin, self).notify_routers_updated(
 -context, list(router_ids), 'disassociate_floatingips', {})
 +context, list(router_ids) if router_ids else None,
 'disassociate_floatingips', {})


 -Sunil
 --
 *From:* Sunil Kumar [su...@embrane.com]
 *Sent:* Saturday, January 10, 2015 7:07 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* [openstack-dev] [Neutron][L3][Devstack] Bug during delete
 floating IPs?

  Not sure if its something seen by others. I hit this when I run
 tempest.scenario.test_network_basic_ops.TestNetworkBasicOps against master:

 2015-01-10 17:45:13.227 5350 DEBUG neutron.plugins.ml2.plugin
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Deleting port
 e5deb014-0063-4d55-8ee3-5ba3524fee14 delete_port
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:995
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Created new semaphore
 db-access internal_lock
 /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:206
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Acquired semaphore db-access
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:229
 2015-01-10 17:45:13.252 5350 DEBUG neutron.plugins.ml2.plugin
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Calling delete_port for
 e5deb014-0063-4d55-8ee3-5ba3524fee14 owned by network:floatingip
 delete_port /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:1043
 2015-01-10 17:45:13.254 5350 DEBUG neutron.openstack.common.lockutils
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Releasing semaphore db-access
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:238
 2015-01-10 17:45:13.282 5350 ERROR neutron.api.v2.resource
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] delete failed
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource Traceback (most
 recent call last):
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/api/v2/resource.py, line 83, in resource
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource result =
 method(request=request, **args)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/api/v2/base.py, line 479, in delete
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
 obj_deleter(request.context, id, **kwargs)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/db/l3_dvr_db.py, line 198, in
 delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
 self).delete_floatingip(context, id)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 1237, in
 delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource router_id =
 self._delete_floatingip(context, id)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 902, in
 _delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
 l3_port_check=False)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py, line 1050, in
 delete_port
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource
 l3plugin.notify_routers_updated(context, router_ids)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 1260, in
 notify_routers_updated
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource context,
 list(router_ids), 'disassociate_floatingips', {})
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource TypeError:
 'NoneType' object is not iterable

 Looks like the code is assuming that router_ids can never be None, which
 clearly is the case here. Is that a bug?

 Looking elsewhere in the l3_db.py,
 L3RpcNotifierMixin.notify_routers_updated() does make a check for
 router_ids (which means that that function does expect it to be empty some
 times), but the list() is killing it before it

Re: [openstack-dev] [Nova] Kilo Release Status - just passed spec freeze

2015-01-13 Thread Neil Jerram

John Garbutt j...@johngarbutt.com writes:

 Hi all,

 With the release of kilo-1 we have frozen the approval of new specs for kilo.

 This is to make sure we can focus on our agreed kilo priorities:
 http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html

 As always, there are exceptions, here is how:

 1) email ML, [nova] Request Spec Freeze Exception in the subject
 2) nova-drivers will review the spec in gerrit, at normal
 3) either the spec gets a -2 for kilo, or the spec gets approved, in
 the usual way

Hi John,

Do I need to follow this process for
https://review.openstack.org/#/c/130732/ ?  This spec was approved as of
Patch Set 7, but with some requests for minor clarifications to the
text.  When I uploaded Patch Sets 8 and 9, to make those clarifications,
it appears that those approvals were lost.

Hence I'm not clear what the situation now is - please could you advise?

 Hopefully that helps clear things up. Catch me on IRC for questions.

Ah, OK, I'll do that too!  Also planning to attend the Nova meeting on
Thursday, in case that's the right forum to discuss this.

Many thanks,
 Neil

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

[openstack-dev] [nova] request spec freeze exception for Api add vnic_type support

2015-01-13 Thread Czesnowicz, Przemyslaw

Hi,

I'd like to request an spec freeze exception for Api add vnic_type support.

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

There is agreement in SRIOV community that this a very needed change.
This change will simplify using  sriov (or other vnic_types) and make it more 
flexible.

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

[openstack-dev] [nova] Kilo FeatureProposalFreeze 22nd Jan and FeatureFreeze 5th Feb

2015-01-13 Thread John Garbutt

Hi,

In kilo we agreed to focus more on stability and technical debt
related work. As such...

If your code is *not* on this list of kilo priorities:
http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html

Then the following dates apply (as previously announced)...

22nd Jan is FeatureProposalFreeze
https://wiki.openstack.org/wiki/FeatureProposalFreeze

5th Feb (kilo-2) is FeatureFreeze
https://wiki.openstack.org/wiki/FeatureFreeze

For bugs and things on the kilo priorities list, we will follow the
regular dates:
https://wiki.openstack.org/wiki/Kilo_Release_Schedule


On the 22nd Jan, blueprints that do not have all their code up for
review, and marked as NeedsCodeReview, will either be unapproved, or
moved to kilo-3, depending on if the blueprint is on the kilo priority
list.

On the 6th Feb, we will start an exception process to admit
non-priority list code into kilo-3.

That process will be officially announced after the nova midcycle
meetup, but it will look at lot like this:
* email to the ML with [nova] FFE Request in the subject
* three nova-core sign up on the ML to review the code
* a nova-driver approves the ability to move to kilo-3
* ...but only once we have made space by completing a kilo-3 blueprint

Thanks,
John

PS
I think the 23rd of Jan would be a good day for a Blueprint Code
Review day, where we all hang out in #openstack-nova and do our best
to review as many blueprints as possible.

If you would like to help organise that push, please email me off list.

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

[openstack-dev] [Ironic] Getting reply back from external DHCP server.

2015-01-13 Thread Peeyush Gupta

Hi all,

I have been using external DHCP server with my Ironic setup. I have
successfully deployed a physical server using that setup. I set up
dhcp_provider=none in ironic.conf. I restarted conductor process.

Now, the problem is that external DHCP is not able to send confirmation
of deployment to Ironic server, which results in timeout for the
instance. I want to know how Ironic is handling external DHCP, do I need
to make changes other than putting dhcp_provider=none?

Thanks,

-- 
Peeyush Gupta
gpeey...@linux.vnet.ibm.com 



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

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

2015-01-13 Thread Przemyslaw Kaminski

For example

https://www.python.org/download/releases/2.6.9/

All official maintenance for Python 2.6, including security patches,
has ended.

https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS

Especially the SSL stuff is interesting

http://bugs.python.org/issue22935

P.

On 01/13/2015 08:39 AM, Bartłomiej Piotrowski wrote:
 On 01/12/2015 03:55 PM, Roman Prykhodchenko wrote:
 Folks,
 
 as it was planned and then announced at the OpenStack summit
 OpenStack services deprecated Python-2.6 support. At the moment
 several services and libraries are already only compatible with
 Python=2.7. And there is no common sense in trying to get back
 compatibility with Py2.6 because OpenStack infra does not run
 tests for that version of Python.
 
 The point of this email is that some components of Fuel, say,
 Nailgun and Fuel Client are still only tested with Python-2.6.
 Fuel Client in it’s turn is about to use OpenStack CI’s
 python-jobs for running unit tests. That means that in order to
 make it compatible with Py2.6 there is a need to run a separate
 python job in FuelCI.
 
 However, I believe that forcing the things being compatible with
 2.6 when the rest of ecosystem decided not to go with it and when
 Py2.7 is already available in the main CentOS repo sounds like a
 battle with the common sense. So my proposal is to drop 2.6
 support in Fuel-6.1.
 
 While I come from the lands where being bleeding edge is preferred,
 I ask myself (as not programmer) one thing: what does 2.7 provide
 that you cannot easily achieve in 2.6?
 
 Regards, Bartłomiej
 
 __

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

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

Re: [openstack-dev] [heat][tripleo] Making diskimage-builder install from forked repo?

2015-01-13 Thread Thomas Spatzier

 From: Steve Baker sba...@redhat.com
 To: openstack-dev@lists.openstack.org
 Date: 12/01/2015 21:16
 Subject: Re: [openstack-dev] [heat][tripleo] Making diskimage-
 builder install from forked repo?

 On 09/01/15 07:06, Gregory Haynes wrote:
  Excerpts from Steven Hardy's message of 2015-01-08 17:37:55 +:
  Hi all,

  I'm trying to test a fedora-software-config image with some updated
  components.  I need:

  - Install latest master os-apply-config (the commit I want isn't
released)
  - Install os-refresh-config fork from https://
 review.openstack.org/#/c/145764

  I can't even get the o-a-c from master part working:

  export PATH=${PWD}/dib-utils/bin:$PATH
  export
  ELEMENTS_PATH=tripleo-image-elements/elements:heat-templates/hot/
 software-config/elements
  export DIB_INSTALLTYPE_os_apply_config=source

  diskimage-builder/bin/disk-image-create vm fedora selinux-permissive \
 os-collect-config os-refresh-config os-apply-config \
 heat-config-ansible \
 heat-config-cfn-init \
 heat-config-docker \
 heat-config-puppet \
 heat-config-salt \
 heat-config-script \
 ntp \
 -o fedora-software-config.qcow2

  This is what I'm doing, both tools end up as pip installed versions
AFAICS,
  so I've had to resort to manually hacking the image post-DiB using
  virt-copy-in.

  Pretty sure there's a way to make DiB do this, but don't know what,
anyone
  able to share some clues?  Do I have to hack the elements, or is there
a
  better way?

  The docs are pretty sparse, so any help would be much appreciated! :)

  Thanks,

  Steve

  Hey Steve,

  source-repositories is your friend here :) (check out
  dib/elements/source-repositires/README). One potential gotcha is that
  because source-repositires is an element it really only applies to
tools
  used within images (and os-apply-config is used outside the image). To
  fix this we have a shim in tripleo-incubator/scripts/pull-tools which
  emulates the functionality of source-repositories.

  Example usage:

  * checkout os-apply-config to the ref you wish to use
  * export DIB_REPOLOCATION_os_apply_config=/path/to/oac
  * export DIB_REPOREF_os_refresh_config=refs/changes/64/145764/1
  * start your devtesting

 The good news is that devstack is already set up to do this. When
 HEAT_CREATE_TEST_IMAGE=True devstack will build packages from the
 currently checked-out os-*-config tools, build a pip repo and configure
 apache to serve it.

Very cool! Didn't know about it. Thanks for sharing this information :-)

 Then the elements *should* install from these packages - we're not
 gating on this functionality (yet) so its possible it has regressed but
 shouldn't be too hard to get going again.

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

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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Flavio Percoco


On 13/01/15 01:14 +0400, Boris Pavlovic wrote:

Hello TC, 

I would like to propose to allow adding all python-clients from stackforge
(that are regarding global-requirements) to global requirements. 


I believe this is not a thing for the TC to decided but the dev
community, especially the infra team, requirement's cores, etc.

What python-clients are you referring to? Are you referring to libs
that live in stackforge or dependencies for things that live in
stackforge?

Do you have an (or many) example?

Flavio

--
@flaper87
Flavio Percoco


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

[openstack-dev] oslo.db 1.4.1 release

2015-01-13 Thread Victor Sergeyev

Hello folks!

The Oslo team is pleased to announce the release of oslo.db - 1.4.1

This is a bugfix release to address a problem found in the 1.4.0 release -
 oslo.db API change break neutron functional tests

Change in openstack/oslo.db  1.4.0..1.4.1

commit b1fc55c7ce6004311379f4002fdceddcc8da9784
Author: Mike Bayer mike...@zzzcomputing.com
Date:   Mon Jan 12 17:26:23 2015 -0500

Restore the check_foreign_keys() method.

This method was prematurely removed from oslo.db without
a deprecation phase, when Alembic added support for
foreign key autodetection.   oslo.db continues to use
alembic for this purpose, however the
ModelsMigrationsSync.check_foreign_keys() method is restored
directly for those projects which were calling into it
explicitly.

diffstat
 oslo_db/sqlalchemy/test_migrations.py   |  72 +
 oslo_db/tests/sqlalchemy/test_migrations.py | 187 +


Please report issues through launchpad:
 http://bugs.launchpad.net/oslo.db
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Fw: [Heat] Enhancement on addition to heat template with glance

2015-01-13 Thread Anusha Rayani

 
Hello All,

I would like to implement glance image upload based on the path given from the 
HOT template.

Currently I could see we can give already uploaded image id/name.

Please let me know any further suggestions on this.

Thanks,
Anusha Rayani
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

2015-01-13 Thread Chris Dent


On Mon, 12 Jan 2015, Sean Dague wrote:


I think it's important to look at this in the narrower context, we're
not testing full environments here, this is custom crafting HTTP req /
resp in a limited context to make sure components are completing a contract.


Yes, exactly.

In fact one of the things that keeps coming up in conversations is
that people keep asking about ways of extending the response body
validation and I'm reluctant to make that aspect of things _too_
powerful. The goal is to validate that the HTTP is doing the right
thing, not to validate the persistence layer or the business logic
that is assembling the details of the resources.

In that sense the place where the attention and power should be in the
tests is in the crafting of the requests and in the validation of the
response headers. Part of the reason for including jsonpath was to be
able to do spot checks into the response body rather than including
some simulcrum of the entire response in the test.

And even including that was a matter of convenience to deal with
ambiguity in the JSON producers. The original response body tests
were simple assertions that some string fragment is somewhere in
the body.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-13 Thread Eduard Matei

Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set before
starting first time nodepool, so template got incorrect key)
Next question: where do i configure the apache logs server address? I have
a separate vm with jenkins account and running apache2 exposing
/srv/static/logs, but where do i enter its ip address ? (in jenkins,
nodepool or... )

Thanks,
Eduard

On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  You are correct to run nodepoold as nodepool user.

 I didn’t see any issues…

 Could you double check the public keys listed in .ssh/authorized_keys in
 the template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY?

 Ramy



 *From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
 *Sent:* Monday, January 12, 2015 5:30 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help
 setting up CI



 Hi,

 Regarding the last issue, i fixed it by logging in and manually pip
 install docutils. Image was created successfully.



 Now the problem is that nodepool is not able to login into instances
 created from that image.

 I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running,
 and also i am able to login to the instance from user nodepool, but
 nodepoold gives error:

 2015-01-12 14:19:03,095 DEBUG paramiko.transport: Switch to new keys ...

 2015-01-12 14:19:03,109 DEBUG paramiko.transport: Trying key
 c03fbf64440cd0c2ecbc07ce4ed59804 from /home/nodepool/.ssh/id_rsa

 2015-01-12 14:19:03,135 DEBUG paramiko.transport: userauth is OK

 2015-01-12 14:19:03,162 INFO paramiko.transport: Authentication
 (publickey) failed.

 2015-01-12 14:19:03,185 DEBUG paramiko.transport: Trying discovered key
 c03fbf64440cd0c2ecbc07ce4ed59804 in /home/nodepool/.ssh/id_rsa

 2015-01-12 14:19:03,187 DEBUG paramiko.transport: userauth is OK

 ^C2015-01-12 14:19:03,210 INFO paramiko.transport: Authentication
 (publickey) failed.

 2015-01-12 14:19:03,253 DEBUG paramiko.transport: EOF in transport thread

 2015-01-12 14:19:03,254 INFO nodepool.utils: Password auth exception. Try
 number 4...





 echo $NODEPOOL_SSH_KEY


 B3NzaC1yc2EDAQABAAABAQC9gP6qui1fmHrj02p6OGvnz7kMTJ2rOC3SBYP/Ij/6yz+SU8rL5rqL6jqT30xzy9t1q0zsdJCNB2jExD4xb+NFbaoGlvjF85m12eFqP4CQenxUOdYAepf5sjV2l8WAO3ylspQ78ipLKec98NeKQwLrHB+xon6QfAHXr6ZJ9NRZbmWw/OdpOgAG9Cab+ELTmkfEYgQz01cZE22xEAMvPXz57KlWPvxtE7YwYWy180Yib97EftylsNkrchbSXCwiqgKUf04qWhTgNrVuRJ9mytil6S82VNDxHzTzeCCxY412CV6dDJNLzJItpf/CXQelj/6wJs1GgFl5GWJnqortMR2v



  cat /home/nodepool/.ssh/id_rsa.pub

 ssh-rsa
 B3NzaC1yc2EDAQABAAABAQC9gP6qui1fmHrj02p6OGvnz7kMTJ2rOC3SBYP/Ij/6yz+SU8rL5rqL6jqT30xzy9t1q0zsdJCNB2jExD4xb+NFbaoGlvjF85m12eFqP4CQenxUOdYAepf5sjV2l8WAO3ylspQ78ipLKec98NeKQwLrHB+xon6QfAHXr6ZJ9NRZbmWw/OdpOgAG9Cab+ELTmkfEYgQz01cZE22xEAMvPXz57KlWPvxtE7YwYWy180Yib97EftylsNkrchbSXCwiqgKUf04qWhTgNrVuRJ9mytil6S82VNDxHzTzeCCxY412CV6dDJNLzJItpf/CXQelj/6wJs1GgFl5GWJnqortMR2v
 jenkins@jenkins-cinderci



 ssh ubuntu@10.100.128.136 -v

 OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014

 debug1: Reading configuration data /home/nodepool/.ssh/config

 debug1: Reading configuration data /etc/ssh/ssh_config

 debug1: /etc/ssh/ssh_config line 19: Applying options for *

 debug1: Connecting to 10.100.128.136 [10.100.128.136] port 22.

 debug1: Connection established.

 

 debug1: Offering RSA public key: /home/nodepool/.ssh/id_rsa

 debug1: Server accepts key: pkalg ssh-rsa blen 279

 debug1: key_parse_private2: missing begin marker

 debug1: read PEM private key done: type RSA

 debug1: Authentication succeeded (publickey).

 Authenticated to 10.100.128.136 ([10.100.128.136]:22).

 ...



 I was able to login into the template instance and also am able to login
 into the slave instances.

 Also nodepoold was able to login into template instance but now it fails
 loging in into slave.



 I tried running it as either nodepol or jenkins users, same result.



 Thanks,

 Eduard



 On Mon, Jan 12, 2015 at 2:09 PM, Eduard Matei 
 eduard.ma...@cloudfounders.com wrote:

  Hi,

 Back with another error during image creation with nodepool:

 2015-01-12 13:05:17,775 INFO nodepool.image.build.local_01.d-p-c:
 Downloading python-daemon-2.0.1.tar.gz (62kB)

 2015-01-12 13:05:18,022 INFO nodepool.image.build.local_01.d-p-c:
 Traceback (most recent call last):

 2015-01-12 13:05:18,023 INFO nodepool.image.build.local_01.d-p-c:
 File string, line 20, in module

 2015-01-12 13:05:18,023 INFO nodepool.image.build.local_01.d-p-c:
 File /tmp/pip-build-r6RJKq/python-daemon/setup.py, line 27, in module

 2015-01-12 13:05:18,024 INFO nodepool.image.build.local_01.d-p-c:
 import version

 2015-01-12 13:05:18,024 INFO nodepool.image.build.local_01.d-p-c:
 File version.py, line 51, in module

 2015-01-12 13:05:18,024 INFO nodepool.image.build.local_01.d-p-c:
 import docutils.core

 2015-01-12 13:05:18,024 INFO nodepool.image.build.local_01.d-p-c:
 ImportError: No module named

Re: [openstack-dev] Fw: [Heat] Enhancement on addition to heat template with glance

2015-01-13 Thread Steven Hardy

On Tue, Jan 13, 2015 at 03:33:09PM +0530, Anusha Rayani wrote:
Hello All,
 
I would like to implement glance image upload based on the path given from
the HOT template.

You may need to provide more details - heat already accepts a location
property?

https://github.com/openstack/heat/blob/master/heat/engine/resources/glance_image.py#L97

If you have an image locally, you probably need to either make it available
via a web server or upload it to swift, then pass the URL to heat.

It doesn't really make sense to upload the entire image via heat from a
local path, if that's what you mean?

Steve

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

Re: [openstack-dev] [Fuel] Lack of additional setup on 10Gbit interfaces.

2015-01-13 Thread Skamruk, Piotr

On mon, 2015-01-12 at 14:31 -0800, Dmitry Borodaenko wrote:
 Hi Piotr,
 
 Thanks for writing up a detailed summary of the problem! At the
 moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to
 add this functionality to Fuel Web UI [1]
 
 [0] 
 http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configuration-via-cli
 [1] https://blueprints.launchpad.net/fuel/+spec/set-mtu-for-interfaces
Good point. I missed this.
So from cli I can patch this before initial deploy changes.
Changing this on deployed environment is, or is not possible?

btw. is there a way to force from fuel master node puppetsync on
particular deployed environment?

 
 I'm not sure it's safe to assume that if you have a 10G NICs the rest
 of your network is going to support jumbo frames, do you think simply
 being able to set MTU explicitly (when you know for a fact that
 particular MTU value works) would be good enough of a solution?
Yes, I think that setting this should be based on user decision, and
should be configurable per interface in some point of webui.


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

[openstack-dev] [nova] request spec freeze exception for Add spec for VIF Driver for SR-IOV InfiniBand

2015-01-13 Thread Moshe Levi

Hi,

I'd like to request an exception for Add spec for VIF Driver for SR-IOV 
InfiniBand.
https://review.openstack.org/#/c/131729/

This is  very localized change, that does not affect any other types and 
justify by InfiniBand use cases.
Work in progress code https://review.openstack.org/#/c/145779/



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

Re: [openstack-dev] [api] API Definition Formats

2015-01-13 Thread Chris Dent


On Tue, 13 Jan 2015, Ian Cordasco wrote:


On 1/12/15, 17:21, Chris Dent chd...@redhat.com wrote:


On Mon, 12 Jan 2015, Ian Cordasco wrote:


This worked extremely well in my experience and helped improve
development
time for new endpoints and new endpoint versions. The documentation was
also heavily used for the multiple internal clients for that API.


This idea of definition formats seems like a reasonable idea (see my
response to Anne over on the gabbi thread[1]) but I worry about a few
things:


Your response below suggests that I didn't make the point above about
how I think this is a reasonable idea strongly enough. My comments
were not to disparage the idea but rather to start applying some flesh
on the bare bones of some concerns that might arise as people try to apply
the idea.


* Unless you're auto generating the code from the formal defition you
  run into a lot of opportunities for truth to get out of sync between
  the definition and the implementation.


The /documentation/ was used by /developers/ to build the internal
clients. It was also used by the front-end developers who built the
user-facing interface that consumed these APIs.


Yes, that restates the problem nicely: all code always has the problem
I stated: documentation (in whatever form) is highly likely to get out
of sync with implementations. You made some motions towards ways to
guard against this problem when you described how tests and
documentation can be interlinked. Sounds great! But it doesn't
entirely ameliorate the concern.


* Specifying every single endpoint or many endpoints is just about as
  anti-REST as you can get if you're a HATEOAS believer. I suspect
  this line of concern is well-trod ground and not worth bringing back
  up, but all this stuff about versioning is meh and death to client
  diversity.


Except that we don’t even try to achieve HATEOAS (or at least the
OpenStack APIs I’ve seen don’t). If we’re being practical about it, then
the idea that we have a contract between the API consumer (also read:
user) and the server makes for a drastic simplification. The fact that the
documentation is auto-generated means that writing tests with gabbi would
be so much simpler for you (than waiting for people familiar with it to
help you).


We don't try to achieve HATEOAS _now_ but why should it be off the
radar for things we do in the future? There's a frequent tension in
the API discussions between describing and validating the existing
APIs and describing a target for future improvements. I think we should
be doing both. There could be room for discussion about increased
hypermedia. It is _one_ of the ways to allow robust longevity of APIs. I
don't personally want to open that can of worms if it has been opened
many times before, but it is worth noting the option as it provides a
much different technique for addressing the concerns about versioning
and documentation.


All that said, what you describe in the following would be nice if it
can be made true and work well. I suspect I'm still scarred from WSDL
and company but I'm not optimistic that culturally it can be made to
work. Simple HTTP APIs wins over SOAP and pragmatic HTTP wins over true
REST and JSON wins over XML because all of the latter have a flavor of
flexibility and easy to diddle that does not exist in the former. The
problem is social, not technical.


Well I’ve only seen it used with JSON, so I’m not sure where you got XML
from (or SOAP for that matter). Besides, this is a tool that will help the
API developers more than it will hurt them. In-tree definitions in a
(fairly) human readable format that clearly states what is accepted and
generated by an endpoint means that scrutinizing Pecan and WSME isn’t
necessary (until you start writing the endpoint itself).


What I was expressing in that paragraph was a bit of allegoric
thinking: This thing you're suggesting smells a bit like these other
things that although they sounded like good ideas failed to have
long-lived success all for much the same reason.

I guess I should have made the implicit questions explicit: How is this
formalism that you are suggesting different from those? How can we guard
against the social tendency of devs who have freedom of choice to choose
tools that are embedded in the ethic of easy to diddle? How can we
ensure that the tools we create fall on that side of things?

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

Re: [openstack-dev] [Neutron][L3][Devstack] Bug during delete loating Ps?

2015-01-13 Thread Miguel Ángel Ajo

That’s nice Sunil, can you send the patch for review on gerrit?

May be it’s also interesting to avoid sending a notify_routers_updated when 
there are
no router_ids.


Miguel Ángel Ajo


On Sunday, 11 de January de 2015 at 08:42, Sunil Kumar wrote:

 This trivial patch fixes the tracebacks:
  
 $ cat disassociate_floating_ips.patch  
 --- neutron/db/l3_db.py.orig2015-01-10 22:20:30.101506298 -0800
 +++ neutron/db/l3_db.py 2015-01-10 22:24:18.111479818 -0800
 @@ -1257,4 +1257,4 @@
   
  def notify_routers_updated(self, context, router_ids):
  super(L3_NAT_db_mixin, self).notify_routers_updated(
 -context, list(router_ids), 'disassociate_floatingips', {})
 +context, list(router_ids) if router_ids else None, 
 'disassociate_floatingips', {})
  
  
 -Sunil
 From: Sunil Kumar [su...@embrane.com (mailto:su...@embrane.com)]
 Sent: Saturday, January 10, 2015 7:07 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [Neutron][L3][Devstack] Bug during delete floating 
 IPs?
  
 Not sure if its something seen by others. I hit this when I run 
 tempest.scenario.test_network_basic_ops.TestNetworkBasicOps against master:
  
 2015-01-10 17:45:13.227 5350 DEBUG neutron.plugins.ml2.plugin 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Deleting port 
 e5deb014-0063-4d55-8ee3-5ba3524fee14 delete_port 
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:995
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Created new semaphore db-access 
 internal_lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:206
 2015-01-10 17:45:13.228 5350 DEBUG neutron.openstack.common.lockutils 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Acquired semaphore db-access 
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:229
 2015-01-10 17:45:13.252 5350 DEBUG neutron.plugins.ml2.plugin 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] Calling delete_port for 
 e5deb014-0063-4d55-8ee3-5ba3524fee14 owned by network:floatingip delete_port 
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py:1043
 2015-01-10 17:45:13.254 5350 DEBUG neutron.openstack.common.lockutils 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f ] Releasing semaphore db-access 
 lock /opt/stack/new/neutron/neutron/openstack/common/lockutils.py:238
 2015-01-10 17:45:13.282 5350 ERROR neutron.api.v2.resource 
 [req-2ab4b380-cf3a-4663-90c3-a05ef5f4da0f None] delete failed
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource Traceback (most 
 recent call last):
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/api/v2/resource.py, line 83, in resource
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource result = 
 method(request=request, **args)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/api/v2/base.py, line 479, in delete
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource 
 obj_deleter(request.context, id, **kwargs)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/db/l3_dvr_db.py, line 198, in 
 delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource 
 self).delete_floatingip(context, id)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 1237, in delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource router_id = 
 self._delete_floatingip(context, id)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 902, in _delete_floatingip
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource 
 l3_port_check=False)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/plugins/ml2/plugin.py, line 1050, in 
 delete_port
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource 
 l3plugin.notify_routers_updated(context, router_ids)
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource   File 
 /opt/stack/new/neutron/neutron/db/l3_db.py, line 1260, in 
 notify_routers_updated
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource context, 
 list(router_ids), 'disassociate_floatingips', {})
 2015-01-10 17:45:13.282 5350 TRACE neutron.api.v2.resource TypeError: 
 'NoneType' object is not iterable
  
 Looks like the code is assuming that router_ids can never be None, which 
 clearly is the case here. Is that a bug?
  
 Looking elsewhere in the l3_db.py, 
 L3RpcNotifierMixin.notify_routers_updated() does make a check for router_ids 
 (which means that that function does expect it to be empty some times), but 
 the list() is killing it before it reaches that.
  
 This backtrace repeats itself many many times in the neutron logs.
  
 Thanks for your help.
 -Sunil

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Boris Pavlovic

Flavio,

Current 2 python clients are Mistral and Murano that I would like to use in
Rally.

I can't add them to requirements = so I need to work everywhere in
lazy-mode + print exceptions to end users
e.g. you don't have this client, so install it - which is really not user
friendly.

Best regards,
Boris Pavlovic

On Tue, Jan 13, 2015 at 1:46 PM, Flavio Percoco fla...@redhat.com wrote:

 On 13/01/15 01:14 +0400, Boris Pavlovic wrote:

 Hello TC,

 I would like to propose to allow adding all python-clients from stackforge
 (that are regarding global-requirements) to global requirements.


 I believe this is not a thing for the TC to decided but the dev
 community, especially the infra team, requirement's cores, etc.

 What python-clients are you referring to? Are you referring to libs
 that live in stackforge or dependencies for things that live in
 stackforge?

 Do you have an (or many) example?

 Flavio

 --
 @flaper87
 Flavio Percoco

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


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

Re: [openstack-dev] [Fuel] Lack of additional setup on 10Gbit interfaces.

2015-01-13 Thread Vladimir Kuklin

Hi Piotr

Currently, you are not able trigger a network reconfiguration on the node
without redeploying the whole node. We are working on this and it should
become available in 6.1 as a part of
https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization and
https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks

Regarding puppetsync - you can simply call puppet sync mcollective agents
on the particular nodes using something like

mco rpc --agent puppetsync --action rsync -I /^[0-9]/


On Tue, Jan 13, 2015 at 2:36 PM, Skamruk, Piotr piotr.skam...@intel.com
wrote:

 On mon, 2015-01-12 at 14:31 -0800, Dmitry Borodaenko wrote:
  Hi Piotr,
 
  Thanks for writing up a detailed summary of the problem! At the
  moment, we have a way to set MTU using Fuel CLI [0] and a blueprint to
  add this functionality to Fuel Web UI [1]
 
  [0]
 http://docs.mirantis.com/openstack/fuel/fuel-6.0/reference-architecture.html#adjust-the-network-configuration-via-cli
  [1] https://blueprints.launchpad.net/fuel/+spec/set-mtu-for-interfaces
 Good point. I missed this.
 So from cli I can patch this before initial deploy changes.
 Changing this on deployed environment is, or is not possible?

 btw. is there a way to force from fuel master node puppetsync on
 particular deployed environment?

 
  I'm not sure it's safe to assume that if you have a 10G NICs the rest
  of your network is going to support jumbo frames, do you think simply
  being able to set MTU explicitly (when you know for a fact that
  particular MTU value works) would be good enough of a solution?
 Yes, I think that setting this should be based on user decision, and
 should be configurable per interface in some point of webui.


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




-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fw: [Heat] Enhancement on addition to heat template with glance

2015-01-13 Thread Anusha Rayani

 Hello Steve,

Thanks for your response.

Yes,we do have an resource class defined in Heat to upload an image, but in 
this case we can only use the image from URL where as using --file  option to 
glance image-create we can upload a disk image from local filesystem to glance.

$ glance image-create 
  --file FILE Local file that contains disk image to be uploaded
    during creation. Alternatively, images can be passed
    to the client via stdin.

However GlanceImage class has only an option to upload the image from 
location/URL.

Thanks,
Anusha Rayani
 Tata Consultancy Services
 Cell:- 9703299907
 Mailto: anusha.ray...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 

-Steven Hardy sha...@redhat.com wrote: -
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
From: Steven Hardy sha...@redhat.com
Date: 01/13/2015 05:04PM
Subject: Re: [openstack-dev] Fw: [Heat] Enhancement on addition to heat 
template with glance

On Tue, Jan 13, 2015 at 03:33:09PM +0530, Anusha Rayani wrote:
    Hello All,
 
    I would like to implement glance image upload based on the path given from
    the HOT template.

You may need to provide more details - heat already accepts a location
property?

https://github.com/openstack/heat/blob/master/heat/engine/resources/glance_image.py#L97

If you have an image locally, you probably need to either make it available
via a web server or upload it to swift, then pass the URL to heat.

It doesn't really make sense to upload the entire image via heat from a
local path, if that's what you mean?

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

On 01/13/2015 06:56 AM, Boris Pavlovic wrote:
 Flavio, 
 
 Current 2 python clients are Mistral and Murano that I would like to use
 in Rally. 
 
 I can't add them to requirements = so I need to work everywhere in
 lazy-mode + print exceptions to end users 
 e.g. you don't have this client, so install it - which is really not
 user friendly.

Why doesn't rally just remove itself from projects.txt, then there would
be no restrictions on what it adds.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Daniel P. Berrange

On Tue, Jan 13, 2015 at 12:32:23PM +, Kuvaja, Erno wrote:
 I think the major benefits of this defined audience are:
 1) One does not need to express themselves in a way that is for public.
 ( Misunderstandings can be corrected on the fly if needed. ) There is no
 need to explain to anyone reading the logs what you actually meant during
 the conversation month ago.

 2) there is level of confidentiality within that defined audience. (
 For example someone not familiar with the processes thinks they have
 found security vulnerability and comes to the IRC-channel to ask second
 opinion. Those details are not public and that bug can still be raised
 and dealt properly. Once the discussion is logged and the logs are
 publicly available the details are publicly available as well. )
 3) That defined audience does not usually limit content. I have no
 problem to throw my e-mail address, phone number etc. into the channel,
 I would not yell them out publicly.

[snip]

 The channels are not locked so anyone can keep a client online and log
 it for themselves if they feel need for it and lots of people do so.

And any of those people can easily just publish their IRC logs on the
web at any time. So the 3 supposed advantages of non-logging your list
above are simply a facade that don't really exist.

I've been half inclined to setup an IRC bot to log all the openstack
channels myself, precisely because only some of the OpenStack channels
are officially logged.

Fundamentally IRC is a completely open public forum and should be
treated as such, whether logged or not, because you have to assume
any 3rd party could be publishing logs at any time.

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

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Daniel P. Berrange

On Tue, Jan 13, 2015 at 08:27:58AM -0500, Sean Dague wrote:
 On 01/13/2015 08:01 AM, Thierry Carrez wrote:
  Kuvaja, Erno wrote:
  [...]
  1) One does not need to express themselves in a way that is for public. ( 
  Misunderstandings can be corrected on the fly if needed. ) There is no 
  need to explain to anyone reading the logs what you actually meant during 
  the conversation month ago.
  2) there is level of confidentiality within that defined audience. ( For 
  example someone not familiar with the processes thinks they have found 
  security vulnerability and comes to the IRC-channel to ask second opinion. 
  Those details are not public and that bug can still be raised and dealt 
  properly. Once the discussion is logged and the logs are publicly 
  available the details are publicly available as well. )
  3) That defined audience does not usually limit content. I have no problem 
  to throw my e-mail address, phone number etc. into the channel, I would 
  not yell them out publicly.
  [...]
  
  All 3 arguments point to issues you have with *public* channels, not
  *logged* channels.
  
  Our IRC channels are, in effect, already public. Anyone can join them,
  anyone can log them. An embargoed vulnerability discussed on an IRC
  channel (logged or not) should be considered leaked. I agree that
  logging makes it easier for random people to access that already-public
  information, but you can't consider an IRC channel private (and change
  your communication style or content) because it's not logged by eavesdrop.
  
  What you seem to be after is a private, invitation-only IRC channel.
  That's an orthogonal issue to the concept of logging.
 
 Honestly, I do think it's probably worth having an OpenStack wide bit of
 guidance here, especially now that every project has felt the need to
 spin up their own channel instead of using #openstack-dev (which is
 currently mostly void of content).
 
 Not having these logs means we often are missing important parts of
 historical context when decisions are made, because a lot more design is
 happening in unarchived formats than archived ones.

Yep, there have been a number of occassions when conversations that are
relevant to my work have taken place on IRC channels for projects that
I don't normally participate in. It would have been useful to be able
to see the logs and in some cases the channels were not logged. I think
that the project should log all #openstack* IRC channels unconditionally
to maximise the spread of knowledge and improve/facilitate collaboration
 communication between teams. We are a supposedly open, collaborative
project after all.

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

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

Re: [openstack-dev] [Ironic] Getting reply back from external DHCP server.

2015-01-13 Thread Lucas Alvares Gomes

Hi again,

One more thing, when configuring the DHCP Ironic will pass some extra DHCP
information to the server, this include things like the address of the TFTP
server where the PXE configuration files are and also a token so the deploy
ramdisk can authenticate with the Ironic API.

Does your DHCP server is configured with similar information?

Just to test if it's an authentication problem, try to set the
auth_strategy confirguration to noauth and see if the deployment succeed.

[1]
https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L262-L266

Cheers,
Lucas

On Tue, Jan 13, 2015 at 12:04 PM, Lucas Alvares Gomes lucasago...@gmail.com
 wrote:

 Hi Peeyush,

 Now, the problem is that external DHCP is not able to send confirmation
 of deployment to Ironic server, which results in timeout for the
 instance. I want to know how Ironic is handling external DHCP, do I need
 to make changes other than putting dhcp_provider=none?


 AFAIUI setting dhcp_provider=none should be enough. Now, I don't know what
 DHCP confirmation you're saying - assuming you're using a pxe_* driver -
 the deployment of the node happens in 2 phases:

 1) Ironic create the PXE configurations for that node, set the boot
 device, configure the DHCP server (in you're case it's non-op) and power on
 the node.

 2) The node will boot the deploy ramdisk, expose the local disk as an
 iSCSI device and send it to Ironic[1] (is that the confirmation you're
 talking about ?). From there Ironic will write the image onto de disk,
 notify the ramdisk that the deployment is completed[2] and we are done.

 So we don't expect any confirmation from a DHCP server, can you please
 paste the error message you are getting?

 [1]
 https://github.com/openstack/diskimage-builder/blob/master/elements/deploy-ironic/init.d/80-deploy-ironic#L46-L54

 [2]
 https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L478

 Cheers,
 Lucas

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Kuvaja, Erno

I'm heavily against the public logging to the level that I will just leave the 
channel if that will be enabled. My point is not foul language and I do 
understand that there could be some benefits out of it. Personally I think we 
have enough tracked public communication means like ask.openstack.org and the 
mailing lists. IRC is and has always been real time communications with defined 
audience. 

I think the major benefits of this defined audience are:
1) One does not need to express themselves in a way that is for public. ( 
Misunderstandings can be corrected on the fly if needed. ) There is no need to 
explain to anyone reading the logs what you actually meant during the 
conversation month ago.
2) there is level of confidentiality within that defined audience. ( For 
example someone not familiar with the processes thinks they have found security 
vulnerability and comes to the IRC-channel to ask second opinion. Those details 
are not public and that bug can still be raised and dealt properly. Once the 
discussion is logged and the logs are publicly available the details are 
publicly available as well. )
3) That defined audience does not usually limit content. I have no problem to 
throw my e-mail address, phone number etc. into the channel, I would not yell 
them out publicly.

For me personally the last point is the biggest problem, professionally the 
second is major concern. I have been using IRC for so long time that I'm not 
willing to take the risk I can't filter myself on my regular channels. Meetings 
are different story as there it is defined time and at least I'm on meeting 
mode that time knowing it will be publicly logged.

The channels are not locked so anyone can keep a client online and log it for 
themselves if they feel need for it and lots of people do so. There is just 
that big barrier having it within the defined group you can see on the channel 
versus public to anyone. 

As opposed to Cindy's original statement of not wanting to be available 
off-hours, that's solved already: you can set your client to away or not 
respond. It's really common on any IRC network that nick is online while user 
is not or is ignoring that real time outreach by personal preference. No-one 
will/should take that personally or offensive. Not having bouncer/shell to run 
your client is as well personal preference, I doubt anyone can claim they could 
not do it with the options available nowadays.

 - Erno (jokke_) Kuvaja

 -Original Message-
 From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
 Sent: 05 January 2015 19:11
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Glance] IRC logging
 
 Thanks Cindy!
 
 Glance cores, can you all please pitch in?
 
 -Nikhil
 
 
 From: Cindy Pallares [cpalla...@redhat.com]
 Sent: Monday, January 05, 2015 12:28 PM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Glance] IRC logging
 
 I've made a patch, we can vote on it there.
 
 https://review.openstack.org/#/c/145025/
 
 
 On 01/05/2015 11:15 AM, Amrith Kumar wrote:
  I think logging the channel is a benefit even if, as Nikhil points out, it 
  is not
 an official meeting. Trove logs both the #openstack-trove channel and the
 meetings when they occur. I have also had some conversations with other
 ATC's on #openstack-oslo and #openstack-security and have found that the
 eavesdrop logs at http://eavesdrop.openstack.org/irclogs/ to be invaluable
 in either bug comments or code review comments.
 
  The IRC channel is an integral part of communicating within the OpenStack
 community. The use of foul language and other inappropriate behavior
 should be monitored not by admins but by other members of the community
 and called out just as one would call out similar behavior in a non-virtual 
 work
 environment. I submit to you that profanity and inappropriate conduct in an
 IRC channel constitutes a hostile work environment just as much as it does in
 a non-virtual environment.
 
  Therefore I submit to you that there is no place for such behavior on an IRC
 channel irrespective of whether it is logged or not.
 
  Thanks,
 
  -amrith
 
  | -Original Message-
  | From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
  | Sent: Monday, January 05, 2015 11:58 AM
  | To: OpenStack Development Mailing List (not for usage questions)
  | Subject: Re: [openstack-dev] [Glance] IRC logging
  |
  |
  |
  |  On Jan 5, 2015, at 08:07, Nikhil Komawar
  |  nikhil.koma...@rackspace.com
  | wrote:
  | 
  |  Based on the feedback received, we would like to avoid logging on
  |  the
  | project channel. My take from the discussion was that it gives many
  | a folks a feeling of informal platform to express their ideas freely
  | in contrast to the meeting channels.
  | 
  |  However, at the same time I would like to point out that using
  |  foul
  | language in the open freenode channels is a bad

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Thierry Carrez

Kuvaja, Erno wrote:
 [...]
 1) One does not need to express themselves in a way that is for public. ( 
 Misunderstandings can be corrected on the fly if needed. ) There is no need 
 to explain to anyone reading the logs what you actually meant during the 
 conversation month ago.
 2) there is level of confidentiality within that defined audience. ( For 
 example someone not familiar with the processes thinks they have found 
 security vulnerability and comes to the IRC-channel to ask second opinion. 
 Those details are not public and that bug can still be raised and dealt 
 properly. Once the discussion is logged and the logs are publicly available 
 the details are publicly available as well. )
 3) That defined audience does not usually limit content. I have no problem to 
 throw my e-mail address, phone number etc. into the channel, I would not yell 
 them out publicly.
 [...]

All 3 arguments point to issues you have with *public* channels, not
*logged* channels.

Our IRC channels are, in effect, already public. Anyone can join them,
anyone can log them. An embargoed vulnerability discussed on an IRC
channel (logged or not) should be considered leaked. I agree that
logging makes it easier for random people to access that already-public
information, but you can't consider an IRC channel private (and change
your communication style or content) because it's not logged by eavesdrop.

What you seem to be after is a private, invitation-only IRC channel.
That's an orthogonal issue to the concept of logging.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [Glance] IRC logging

On 01/13/2015 08:01 AM, Thierry Carrez wrote:
 Kuvaja, Erno wrote:
 [...]
 1) One does not need to express themselves in a way that is for public. ( 
 Misunderstandings can be corrected on the fly if needed. ) There is no need 
 to explain to anyone reading the logs what you actually meant during the 
 conversation month ago.
 2) there is level of confidentiality within that defined audience. ( For 
 example someone not familiar with the processes thinks they have found 
 security vulnerability and comes to the IRC-channel to ask second opinion. 
 Those details are not public and that bug can still be raised and dealt 
 properly. Once the discussion is logged and the logs are publicly available 
 the details are publicly available as well. )
 3) That defined audience does not usually limit content. I have no problem 
 to throw my e-mail address, phone number etc. into the channel, I would not 
 yell them out publicly.
 [...]
 
 All 3 arguments point to issues you have with *public* channels, not
 *logged* channels.
 
 Our IRC channels are, in effect, already public. Anyone can join them,
 anyone can log them. An embargoed vulnerability discussed on an IRC
 channel (logged or not) should be considered leaked. I agree that
 logging makes it easier for random people to access that already-public
 information, but you can't consider an IRC channel private (and change
 your communication style or content) because it's not logged by eavesdrop.
 
 What you seem to be after is a private, invitation-only IRC channel.
 That's an orthogonal issue to the concept of logging.

Honestly, I do think it's probably worth having an OpenStack wide bit of
guidance here, especially now that every project has felt the need to
spin up their own channel instead of using #openstack-dev (which is
currently mostly void of content).

Not having these logs means we often are missing important parts of
historical context when decisions are made, because a lot more design is
happening in unarchived formats than archived ones.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Glance] IRC logging

On 01/13/2015 08:23 AM, Kuvaja, Erno wrote:
 -Original Message-
 From: Thierry Carrez [mailto:thie...@openstack.org]
 Sent: 13 January 2015 13:02
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Glance] IRC logging

 Kuvaja, Erno wrote:
 [...]
 1) One does not need to express themselves in a way that is for public. (
 Misunderstandings can be corrected on the fly if needed. ) There is no need
 to explain to anyone reading the logs what you actually meant during the
 conversation month ago.
 2) there is level of confidentiality within that defined audience. (
 For example someone not familiar with the processes thinks they have
 found security vulnerability and comes to the IRC-channel to ask
 second opinion. Those details are not public and that bug can still be
 raised and dealt properly. Once the discussion is logged and the logs
 are publicly available the details are publicly available as well. )
 3) That defined audience does not usually limit content. I have no problem
 to throw my e-mail address, phone number etc. into the channel, I would not
 yell them out publicly.
 [...]

 All 3 arguments point to issues you have with *public* channels, not
 *logged* channels.

 Our IRC channels are, in effect, already public. Anyone can join them, anyone
 can log them. An embargoed vulnerability discussed on an IRC channel
 (logged or not) should be considered leaked. I agree that logging makes it
 easier for random people to access that already-public information, but you
 can't consider an IRC channel private (and change your communication style
 or content) because it's not logged by eavesdrop.

 What you seem to be after is a private, invitation-only IRC channel.
 That's an orthogonal issue to the concept of logging.

 Nope, what I'm saying is that I'm opposing public logging to the level that I 
 will not be part if it will be enabled. If someone start publishing the logs 
 they collect from the channel my response is the same I will ask to stop 
 doing that and if it's not enough I will just leave.  I do not use tinfoil 
 hat nor live in a bubble thinking that information is private but I prefer 
 not to make it more obvious. And your private channel would not solve 
 someone logging and publishing the logs anyways, any level of privacy in 
 the communication is based on trust was it participants, service/venue 
 providers or something else so lets not make it more difficult than it is.

This is an extremely confusing point of view to me when it comes to a
channel dedicated to the development of a piece Open Source Software.

All the various artifacts on how we got to a piece of software are
valuable in the future maintenance of it, as well as realizing why we
did not go down certain paths in the past.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [api] API Definition Formats

On 01/09/2015 04:17 PM, Everett Toews wrote:
 One thing that has come up in the past couple of API WG meetings [1] is just 
 how useful a proper API definition would be for the OpenStack projects.
 
 By API definition I mean a format like Swagger, RAML, API Blueprint, etc. 
 These formats are a machine/human readable way of describing your API. 
 Ideally they drive the implementation of both the service and the client, 
 rather than treating the format like documentation where it’s produced as a 
 by product of the implementation.
 
 I think this blog post [2] does an excellent job of summarizing the role of 
 API definition formats.
 
 Some of the other benefits include validation of requests/responses, easier 
 review of API design/changes, more consideration given to client design, 
 generating some portion of your client code, generating documentation, mock 
 testing, etc. 
 
 If you have experience with an API definition format, how has it benefitted 
 your prior projects?
 
 Do you think it would benefit your current OpenStack project?

It would hugely benefit OpenStack to have this clear some where that was
readable.

I don't specifically have experience with these, my only feedback would
be make sure whatever format supports having multiple examples per API
call referenced or embedded.

My experience is that API specs aren't typically fully read and
injested. Instead examples are used to get some minimum working code,
then bits are spot referenced and evolved until the client code looks
like it does what was expected. So providing multiple examples per API
will help more people wrap their head around the interface in question.

-Sean

 
 Thanks,
 Everett
 
 [1] https://wiki.openstack.org/wiki/Meetings/API-WG
 [2] 
 http://apievangelist.com/2014/12/21/making-sure-the-most-important-layers-of-api-space-stay-open/
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Flavio Percoco


On 13/01/15 08:27 -0500, Sean Dague wrote:

On 01/13/2015 08:01 AM, Thierry Carrez wrote:

Kuvaja, Erno wrote:

[...]
1) One does not need to express themselves in a way that is for public. ( 
Misunderstandings can be corrected on the fly if needed. ) There is no need to 
explain to anyone reading the logs what you actually meant during the 
conversation month ago.
2) there is level of confidentiality within that defined audience. ( For 
example someone not familiar with the processes thinks they have found security 
vulnerability and comes to the IRC-channel to ask second opinion. Those details 
are not public and that bug can still be raised and dealt properly. Once the 
discussion is logged and the logs are publicly available the details are 
publicly available as well. )
3) That defined audience does not usually limit content. I have no problem to 
throw my e-mail address, phone number etc. into the channel, I would not yell 
them out publicly.
[...]


All 3 arguments point to issues you have with *public* channels, not
*logged* channels.

Our IRC channels are, in effect, already public. Anyone can join them,
anyone can log them. An embargoed vulnerability discussed on an IRC
channel (logged or not) should be considered leaked. I agree that
logging makes it easier for random people to access that already-public
information, but you can't consider an IRC channel private (and change
your communication style or content) because it's not logged by eavesdrop.

What you seem to be after is a private, invitation-only IRC channel.
That's an orthogonal issue to the concept of logging.


Honestly, I do think it's probably worth having an OpenStack wide bit of
guidance here, especially now that every project has felt the need to
spin up their own channel instead of using #openstack-dev (which is
currently mostly void of content).

Not having these logs means we often are missing important parts of
historical context when decisions are made, because a lot more design is
happening in unarchived formats than archived ones.


+2A

As mentioned in my last email, I think this is worth doing and asking
for. It will also avoid this kinds of discussions and it'll also make
clear the status of our IRC channels.

For example, people with concerns like Erno's would know in advance
that all openstack related IRC channels are logged.

Not sure how/when this can be asked/enforced but it'd avoid this kind
of discussions, at least.

Flavio



-Sean

--
Sean Dague
http://dague.net

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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Chris Dent


On Tue, 13 Jan 2015, Daniel P. Berrange wrote:


Yep, there have been a number of occassions when conversations that are
relevant to my work have taken place on IRC channels for projects that
I don't normally participate in. It would have been useful to be able
to see the logs and in some cases the channels were not logged. I think
that the project should log all #openstack* IRC channels unconditionally
to maximise the spread of knowledge and improve/facilitate collaboration
 communication between teams. We are a supposedly open, collaborative
project after all.


I have no objection to the channels being logged but I think we need
to be careful about relying on the channels and the logs too much
for whatever is deemed as important conversation.

I think any medium which is driven by synchronous conversation is
fairly detrimental to fully participatory and _reasoned_ discussion
amongst people who are distributed around the world.

Yes, it's true that having the logs works to ameliorate many of the
problems presented by synchrony but it does little to address two
fairly large problems:

* it's so freaking noisy and interruption causing (even if you try
  to be good about ignoring it)
* decisions get made by the people are who are present _now_ and no
  others

(The second is obviously a more relevant problem.)

So: Yes please to logs, but no thank you to IRC being such a primary
medium of communication (which, in my experience, it has been in
OpenStack).

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

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

Re: [openstack-dev] [Ironic] Getting reply back from external DHCP server.

2015-01-13 Thread Lucas Alvares Gomes

Hi Peeyush,

Now, the problem is that external DHCP is not able to send confirmation
 of deployment to Ironic server, which results in timeout for the
 instance. I want to know how Ironic is handling external DHCP, do I need
 to make changes other than putting dhcp_provider=none?


AFAIUI setting dhcp_provider=none should be enough. Now, I don't know what
DHCP confirmation you're saying - assuming you're using a pxe_* driver -
the deployment of the node happens in 2 phases:

1) Ironic create the PXE configurations for that node, set the boot device,
configure the DHCP server (in you're case it's non-op) and power on the
node.

2) The node will boot the deploy ramdisk, expose the local disk as an iSCSI
device and send it to Ironic[1] (is that the confirmation you're talking
about ?). From there Ironic will write the image onto de disk, notify the
ramdisk that the deployment is completed[2] and we are done.

So we don't expect any confirmation from a DHCP server, can you please
paste the error message you are getting?

[1]
https://github.com/openstack/diskimage-builder/blob/master/elements/deploy-ironic/init.d/80-deploy-ironic#L46-L54

[2]
https://github.com/openstack/ironic/blob/master/ironic/drivers/modules/pxe.py#L478

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Kuvaja, Erno

 -Original Message-
 From: Thierry Carrez [mailto:thie...@openstack.org]
 Sent: 13 January 2015 13:02
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Glance] IRC logging

 Kuvaja, Erno wrote:
  [...]
  1) One does not need to express themselves in a way that is for public. (
 Misunderstandings can be corrected on the fly if needed. ) There is no need
 to explain to anyone reading the logs what you actually meant during the
 conversation month ago.
  2) there is level of confidentiality within that defined audience. (
  For example someone not familiar with the processes thinks they have
  found security vulnerability and comes to the IRC-channel to ask
  second opinion. Those details are not public and that bug can still be
  raised and dealt properly. Once the discussion is logged and the logs
  are publicly available the details are publicly available as well. )
  3) That defined audience does not usually limit content. I have no problem
 to throw my e-mail address, phone number etc. into the channel, I would not
 yell them out publicly.
  [...]

 All 3 arguments point to issues you have with *public* channels, not
 *logged* channels.

 Our IRC channels are, in effect, already public. Anyone can join them, anyone
 can log them. An embargoed vulnerability discussed on an IRC channel
 (logged or not) should be considered leaked. I agree that logging makes it
 easier for random people to access that already-public information, but you
 can't consider an IRC channel private (and change your communication style
 or content) because it's not logged by eavesdrop.

 What you seem to be after is a private, invitation-only IRC channel.
 That's an orthogonal issue to the concept of logging.

Nope, what I'm saying is that I'm opposing public logging to the level that I 
will not be part if it will be enabled. If someone start publishing the logs 
they collect from the channel my response is the same I will ask to stop doing 
that and if it's not enough I will just leave.  I do not use tinfoil hat nor 
live in a bubble thinking that information is private but I prefer not to make 
it more obvious. And your private channel would not solve someone logging and 
publishing the logs anyways, any level of privacy in the communication is 
based on trust was it participants, service/venue providers or something else 
so lets not make it more difficult than it is.

- Erno

 --
 Thierry Carrez (ttx)

 __

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

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

Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI

2015-01-13 Thread Asselin, Ramy

Hi Eduard,

Apache logs server address is set here (should probably add some comment/doc 
for that)
https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10

Jenkins will get configured here: 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
Note that you need to restart Jenkins for those changes to take effect. After 
it’s set, you can use the Jenkins UI to ‘test’ the connection.

Jenkins Job Builder publishers are here: 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins_job_builder/config/macros.yaml.erb#L110

Use the publishers as shown here:
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7

Zuul will then use this url when commenting in gerrit: 
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/manifests/master.pp#L18


Ramy

From: Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
Sent: Tuesday, January 13, 2015 2:31 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting 
up CI

Thanks Ramy, i got it now working (the NODEPOOL_SSH_KEY was not set before 
starting first time nodepool, so template got incorrect key)
Next question: where do i configure the apache logs server address? I have a 
separate vm with jenkins account and running apache2 exposing /srv/static/logs, 
but where do i enter its ip address ? (in jenkins, nodepool or... )

Thanks,
Eduard

On Mon, Jan 12, 2015 at 6:09 PM, Asselin, Ramy 
ramy.asse...@hp.commailto:ramy.asse...@hp.com wrote:
You are correct to run nodepoold as nodepool user.
I didn’t see any issues…
Could you double check the public keys listed in .ssh/authorized_keys in the 
template for Ubuntu and Jenkins users match $NODEPOOL_SSH_KEY?
Ramy

From: Eduard Matei 
[mailto:eduard.ma...@cloudfounders.commailto:eduard.ma...@cloudfounders.com]
Sent: Monday, January 12, 2015 5:30 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting 
up CI

Hi,
Regarding the last issue, i fixed it by logging in and manually pip install 
docutils. Image was created successfully.

Now the problem is that nodepool is not able to login into instances created 
from that image.
I have NODEPOOL_SSH_KEY exported in the screen where nodepool is running, and 
also i am able to login to the instance from user nodepool, but nodepoold gives 
error:
2015-01-12 14:19:03,095 DEBUG paramiko.transport: Switch to new keys ...
2015-01-12 14:19:03,109 DEBUG paramiko.transport: Trying key 
c03fbf64440cd0c2ecbc07ce4ed59804 from /home/nodepool/.ssh/id_rsa
2015-01-12 14:19:03,135 DEBUG paramiko.transport: userauth is OK
2015-01-12 14:19:03,162 INFO paramiko.transport: Authentication (publickey) 
failed.
2015-01-12 14:19:03,185 DEBUG paramiko.transport: Trying discovered key 
c03fbf64440cd0c2ecbc07ce4ed59804 in /home/nodepool/.ssh/id_rsa
2015-01-12 14:19:03,187 DEBUG paramiko.transport: userauth is OK
^C2015-01-12 14:19:03,210 INFO paramiko.transport: Authentication (publickey) 
failed.
2015-01-12 14:19:03,253 DEBUG paramiko.transport: EOF in transport thread
2015-01-12 14:19:03,254 INFO nodepool.utils: Password auth exception. Try 
number 4...


echo $NODEPOOL_SSH_KEY
B3NzaC1yc2EDAQABAAABAQC9gP6qui1fmHrj02p6OGvnz7kMTJ2rOC3SBYP/Ij/6yz+SU8rL5rqL6jqT30xzy9t1q0zsdJCNB2jExD4xb+NFbaoGlvjF85m12eFqP4CQenxUOdYAepf5sjV2l8WAO3ylspQ78ipLKec98NeKQwLrHB+xon6QfAHXr6ZJ9NRZbmWw/OdpOgAG9Cab+ELTmkfEYgQz01cZE22xEAMvPXz57KlWPvxtE7YwYWy180Yib97EftylsNkrchbSXCwiqgKUf04qWhTgNrVuRJ9mytil6S82VNDxHzTzeCCxY412CV6dDJNLzJItpf/CXQelj/6wJs1GgFl5GWJnqortMR2v

 cat /home/nodepool/.ssh/id_rsa.pub
ssh-rsa 
B3NzaC1yc2EDAQABAAABAQC9gP6qui1fmHrj02p6OGvnz7kMTJ2rOC3SBYP/Ij/6yz+SU8rL5rqL6jqT30xzy9t1q0zsdJCNB2jExD4xb+NFbaoGlvjF85m12eFqP4CQenxUOdYAepf5sjV2l8WAO3ylspQ78ipLKec98NeKQwLrHB+xon6QfAHXr6ZJ9NRZbmWw/OdpOgAG9Cab+ELTmkfEYgQz01cZE22xEAMvPXz57KlWPvxtE7YwYWy180Yib97EftylsNkrchbSXCwiqgKUf04qWhTgNrVuRJ9mytil6S82VNDxHzTzeCCxY412CV6dDJNLzJItpf/CXQelj/6wJs1GgFl5GWJnqortMR2v
 jenkins@jenkins-cinderci

ssh ubuntu@10.100.128.136mailto:ubuntu@10.100.128.136 -v
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/nodepool/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.100.128.136 [10.100.128.136] port 22.
debug1: Connection established.

debug1: Offering RSA public key: /home/nodepool/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 10.100.128.136 ([10.100.128.136]:22).
...

I was

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
 Why doesn't rally just remove itself from projects.txt, then there
 would be no restrictions on what it adds.

I second this recommendation. If Rally wants to depend on things
which are not part of OpenStack and not required to run or test
OpenStack in an official capacity (and since it's not an official
OpenStack project it's entirely within its rights to want to do
that), then forcing it to comply with the list of requirements for
official OpenStack projects is an unnecessarily restrictive choice.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Glance] IRC logging

2015-01-13 Thread Dave Walker

On 13 January 2015 at 12:32, Kuvaja, Erno kuv...@hp.com wrote:
 I'm heavily against the public logging to the level that I will just leave 
 the channel if that will be enabled. My point is not foul language and I do 
 understand that there could be some benefits out of it. Personally I think we 
 have enough tracked public communication means like ask.openstack.org and the 
 mailing lists. IRC is and has always been real time communications with 
 defined audience.

 I think the major benefits of this defined audience are:
 1) One does not need to express themselves in a way that is for public. ( 
 Misunderstandings can be corrected on the fly if needed. ) There is no need 
 to explain to anyone reading the logs what you actually meant during the 
 conversation month ago.
 2) there is level of confidentiality within that defined audience. ( For 
 example someone not familiar with the processes thinks they have found 
 security vulnerability and comes to the IRC-channel to ask second opinion. 
 Those details are not public and that bug can still be raised and dealt 
 properly. Once the discussion is logged and the logs are publicly available 
 the details are publicly available as well. )
 3) That defined audience does not usually limit content. I have no problem to 
 throw my e-mail address, phone number etc. into the channel, I would not yell 
 them out publicly.

 For me personally the last point is the biggest problem, professionally the 
 second is major concern. I have been using IRC for so long time that I'm not 
 willing to take the risk I can't filter myself on my regular channels. 
 Meetings are different story as there it is defined time and at least I'm on 
 meeting mode that time knowing it will be publicly logged.

 The channels are not locked so anyone can keep a client online and log it for 
 themselves if they feel need for it and lots of people do so. There is just 
 that big barrier having it within the defined group you can see on the 
 channel versus public to anyone.

 As opposed to Cindy's original statement of not wanting to be available 
 off-hours, that's solved already: you can set your client to away or not 
 respond. It's really common on any IRC network that nick is online while user 
 is not or is ignoring that real time outreach by personal preference. No-one 
 will/should take that personally or offensive. Not having bouncer/shell to 
 run your client is as well personal preference, I doubt anyone can claim they 
 could not do it with the options available nowadays.

  - Erno (jokke_) Kuvaja


Hi,

I think these concerns are more based around fear, than any real
merit.  I would suggest that any IRC communication should be treated
as public, and therefore the idea of bouncing around personal contacts
details is pretty poor personal security.  If this is required, then
using private messages would seem to be perfectly suitable.

A user can join any #openstack-* channel, and not necessarily be a
friend of the project.  The concerns about security issues should be
treated as if they have already become public.

It seems that Openstack currently has around 40 non-meeting channels
logged[0] and contrasting with the Ubuntu project, there are some 350
public logged channels[1] - with the logs going back to 2004.  This
has caused little issue over the years.

It would seem logical to introduce project-wide irc logging IMO.  I
*have* found it useful to search through archives of projects, and
find it frustrating when this data is not available.

I really struggle with the idea that contributors of a developer
channel do not consider themselves to be talking in a public forum,
which to me - is the same as being logged.  Without this mindset, the
channel (and project?) merely becomes a cabal developers area.

[0] http://eavesdrop.openstack.org/irclogs/
[1] http://irclogs.ubuntu.com/2015/01/01/

--
Kind Regards,
Dave Walker

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

Re: [openstack-dev] [horizon] static files handling, bower/

2015-01-13 Thread Drew Fisher



On 1/13/15 7:59 AM, Jeremy Stanley wrote:
 On 2015-01-13 08:50:28 +0100 (+0100), Matthias Runge wrote:
 [...]
 But, as far as I understand, node.js will become a development
 requirement (and most probably a requirement for testing), but not for
 deployment.
 [...]
 
 A requirement for testing _is_ a requirement for deployment. If it's
 not tested, it's broken. If you're deploying software on a platform
 where it can't be tested then you're simply _hoping_ that it's not
 broken, and that is almost certainly a false hope.
 

Exactly.  We have to test this code base extensively before we package
it up for Solaris.  Under no circumstances do we just blindly repackage
the releases and push them out to customers.  Node.js is a total
incompatibility for Solaris.  If upstream moves to using Bower we'll be
forced to look for alternatives at managing the JavaScript libraries.

Why were the libraries ripped from the Horizon codebase in the first
place?  It seems to me they belong with the code using it.

-Drew

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

Re: [openstack-dev] [horizon] static files handling, bower/

On 2015-01-13 08:13:41 -0700 (-0700), Drew Fisher wrote:
[...]
 Why were the libraries ripped from the Horizon codebase in the
 first place? It seems to me they belong with the code using it.

I disagree. If those libraries aren't developed as part of Horizon
then they should not be copied into and distributed as part of its
source tree. That's code duplication, plain and simple.

I'm in favor of cleaning out all the vendoring of third-party
libraries in OpenStack projects, but agree that it would be nice to
find a cross-platform/portable mechanism for handling them.
-- 
Jeremy Stanley

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

[openstack-dev] oslo.concurrency 0.4.0 released

2015-01-13 Thread Doug Hellmann

The Oslo team is pleased to announce the release of
oslo.concurrency 0.4.0: oslo.concurrency library

This release removes the use of ConfigFilter when accessing
configuration options, making it possible for applications
to set defaults for the lock path option that refer to other
option values.

This version also adds a new context manager for detecting
long-running operations and logging when they take longer
than expected. See oslo_concurrency.watchdog.

For more details, please see the git log history below and
 http://launchpad.net/oslo.concurrency/+milestone/0.4.0

Please report issues through launchpad:
 http://bugs.launchpad.net/oslo.concurrency



Changes in openstack/oslo.concurrency  0.3.0..0.4.0

3dfefe6 Bump to hacking 0.10
43dc67e Updated from global requirements
df35680 add watchdog module
18bcbe2 Updated from global requirements
234b007 make time format for processutils match lockutils
a414266 Correct the translation domain for loading messages
9066336 Add a reader/writer lock
9dd6d21 Don't use ConfigFilter for lockutils
093ed4f Report import warnings where the import occurs
7c7493f Port processutils to Python 3
2aafe6f Activate pep8 check that _ is imported
32bf940 Drop requirements-py3.txt
deb0152 Updated from global requirements
d59543d Clean up API documentation
5de5c42 Workflow documentation is now in infra-manual
09ab853 Remove noqa from test files
3de55f3 test compatibility for old imports
4fd64cb Fix bug link in README.rst

  diffstat (except docs and test files):

 .gitignore   |   1 -
 CONTRIBUTING.rst |   7 +-
 README.rst   |   2 +-
 oslo/concurrency/__init__.py |   2 +-
 oslo_concurrency/_i18n.py|   2 +-
 oslo_concurrency/lockutils.py| 175 +++-
 oslo_concurrency/opts.py |   2 +-
 oslo_concurrency/processutils.py |  23 +-
 oslo_concurrency/watchdog.py |  66 +
 requirements-py3.txt |  14 -
 requirements.txt |   6 +-
 setup.cfg|   5 +-
 test-requirements.txt|   3 +-
 tests/__init__.py|   2 +-
 tests/test_import.py |  31 +++
 tests/test_lockutils.py  |   4 +-
 tests/test_processutils.py   |  18 +-
 tests/test_warning.py|  32 +++
 tests/test_watchdog.py   |  75 ++
 tox.ini  |   5 -
 31 files changed, 832 insertions(+), 90 deletions(-)

  Requirements updates:

 diff --git a/requirements.txt b/requirements.txt
 index a27b434..fb89633 100644
 --- a/requirements.txt
 +++ b/requirements.txt
 @@ -9 +9 @@ fixtures=0.3.14
 -oslo.config=1.4.0  # Apache-2.0
 +oslo.config=1.6.0  # Apache-2.0
 @@ -11 +11 @@ oslo.i18n=1.0.0  # Apache-2.0
 -oslo.utils=1.0.0   # Apache-2.0
 +oslo.utils=1.2.0   # Apache-2.0
 @@ -14 +14 @@ six=1.7.0
 -retrying=1.2.2,!=1.3.0 # Apache-2.0
 +retrying=1.2.3,!=1.3.0 # Apache-2.0
 diff --git a/test-requirements.txt b/test-requirements.txt
 index c424655..32cdaae 100644
 --- a/test-requirements.txt
 +++ b/test-requirements.txt
 @@ -5 +5 @@
 -hacking=0.9.1,0.10
 +hacking=0.10.0,0.11
 @@ -7,0 +8 @@ coverage=3.6
 +futures=2.1.6

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

[openstack-dev] [oslo] proposed kilo feature freeze date March 12

2015-01-13 Thread Doug Hellmann

During Juno we had a freeze about a week before the application freeze 
deadline. That gave us an opportunity to fix critical bugs, while minimizing 
the chance that we would introduce new issues into the applications.

For Kilo, the general feature freeze date is 19 March, so I propose that we 
freeze Oslo development the week before on 12 March.

Please let me know if you anticipate any issues with this plan.

Thanks,
Doug


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

Re: [openstack-dev] [nova] reckoning time for nova ec2 stack




On 1/9/2015 10:17 AM, Steven Hardy wrote:

On Fri, Jan 09, 2015 at 09:11:50AM -0500, Sean Dague wrote:

boto 2.35.0 just released, and makes hmac-v4 authentication mandatory
for EC2 end points (it has been optionally supported for a long time).

Nova's EC2 implementation does not do this.

The short term approach is to pin boto -
https://review.openstack.org/#/c/146049/, which I think is a fine long
term fix for stable/, but in master not supporting new boto, which
people are likely to deploy, doesn't really seem like an option.

https://bugs.launchpad.net/tempest/+bug/1408987 is the bug.

I don't think shipping an EC2 API in Kilo that doesn't work with recent
boto is a thing Nova should do. Do we have volunteers to step up and fix
this, or do we need to get more aggressive about deprecating this interface?


I'm not stepping up to maintain the EC2 API, but the auth part of it is
very similar to heat's auth (which does support hmac-v4), so I hacked on
the nova API a bit to align with the way heat does things:

https://review.openstack.org/#/c/146124/ (WIP)

This needs some more work, but AFAICS solves the actual auth part which is
quite simply fixed by reusing some code we have in heat's ec2token middleware.

If this is used, we could extract the common parts and/or use a common auth
middleware in future, assuming the EC2 implementation as a whole isn't
deemed unmaintained and removed that is.

Steve

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



Looks like the fix we merged didn't actually fix the problem. I have a 
patch [1] to uncap the boto requirement on master and it's failing the 
ec2 tests in tempest the same as before.


I went back to the nova fix on master and checked patch set 9 which had 
the version uncapped in nova's requirements.txt file, and the tests were 
passing but they were running against boto 2.34 [2].


Unfortunately the cherry pick of the ec2 fix was also backported and 
merged to stable/juno which looks like it was probably a waste of time 
right now since we still have a bug.


Therefore we still probably need to cap boto on stable/juno for now. [3]

[1] https://review.openstack.org/#/c/146592/
[2] 
http://logs.openstack.org/24/146124/9/check/check-tempest-dsvm-full/950581d/logs/pip-freeze.txt.gz

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

--

Thanks,

Matt Riedemann


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

[openstack-dev] Hyper-V Meeting

2015-01-13 Thread Peter Pouliot

Hi All,

Due to internal meeting conflicts we need to cancel the meeting for this week.
Please email members of the hyper-v team with any pressing issues.

p

Peter J. Pouliot CISSP
Microsoft Enterprise Cloud Solutions
C:\OpenStack
New England Research  Development Center
1 Memorial Drive
Cambridge, MA 02142
P: 1.(857).4536436
E: ppoul...@microsoft.commailto:ppoul...@microsoft.com

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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

2015-01-13 Thread Boris Pavlovic

Jeremy, Sean,


First of all because I would like to make a Rally official part of
OpenStack and if I remove
Rally from project.txt this won't happen.

On other side I would like to make OpenStack better. And OpenStack includes
as well
projects on StackForge. That for some reason were rejected. In my opinion
all projects
in equal portion deserver good testing framework.
And I as PTL of Rally would like to adopt it for everybody.


P.S. It's sad that in one thread we are talking about making Big Tenant and
how it is cool
to remove programs. In another we are blocking adding python clients from
projects
that are not Core and suggesting another making incompatible with
OpenStack.


Best regards,
Boris Pavlovic


On Tue, Jan 13, 2015 at 6:01 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
  Why doesn't rally just remove itself from projects.txt, then there
  would be no restrictions on what it adds.

 I second this recommendation. If Rally wants to depend on things
 which are not part of OpenStack and not required to run or test
 OpenStack in an official capacity (and since it's not an official
 OpenStack project it's entirely within its rights to want to do
 that), then forcing it to comply with the list of requirements for
 official OpenStack projects is an unnecessarily restrictive choice.
 --
 Jeremy Stanley

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

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

Re: [openstack-dev] oslo.concurrency 0.4.0 released




On 1/13/2015 9:07 AM, Doug Hellmann wrote:

The Oslo team is pleased to announce the release of
oslo.concurrency 0.4.0: oslo.concurrency library

This release removes the use of ConfigFilter when accessing
configuration options, making it possible for applications
to set defaults for the lock path option that refer to other
option values.

This version also adds a new context manager for detecting
long-running operations and logging when they take longer
than expected. See oslo_concurrency.watchdog.

For more details, please see the git log history below and
  http://launchpad.net/oslo.concurrency/+milestone/0.4.0

Please report issues through launchpad:
  http://bugs.launchpad.net/oslo.concurrency



Changes in openstack/oslo.concurrency  0.3.0..0.4.0

3dfefe6 Bump to hacking 0.10
43dc67e Updated from global requirements
df35680 add watchdog module
18bcbe2 Updated from global requirements
234b007 make time format for processutils match lockutils
a414266 Correct the translation domain for loading messages
9066336 Add a reader/writer lock
9dd6d21 Don't use ConfigFilter for lockutils
093ed4f Report import warnings where the import occurs
7c7493f Port processutils to Python 3
2aafe6f Activate pep8 check that _ is imported
32bf940 Drop requirements-py3.txt
deb0152 Updated from global requirements
d59543d Clean up API documentation
5de5c42 Workflow documentation is now in infra-manual
09ab853 Remove noqa from test files
3de55f3 test compatibility for old imports
4fd64cb Fix bug link in README.rst

   diffstat (except docs and test files):

  .gitignore   |   1 -
  CONTRIBUTING.rst |   7 +-
  README.rst   |   2 +-
  oslo/concurrency/__init__.py |   2 +-
  oslo_concurrency/_i18n.py|   2 +-
  oslo_concurrency/lockutils.py| 175 +++-
  oslo_concurrency/opts.py |   2 +-
  oslo_concurrency/processutils.py |  23 +-
  oslo_concurrency/watchdog.py |  66 +
  requirements-py3.txt |  14 -
  requirements.txt |   6 +-
  setup.cfg|   5 +-
  test-requirements.txt|   3 +-
  tests/__init__.py|   2 +-
  tests/test_import.py |  31 +++
  tests/test_lockutils.py  |   4 +-
  tests/test_processutils.py   |  18 +-
  tests/test_warning.py|  32 +++
  tests/test_watchdog.py   |  75 ++
  tox.ini  |   5 -
  31 files changed, 832 insertions(+), 90 deletions(-)

   Requirements updates:

  diff --git a/requirements.txt b/requirements.txt
  index a27b434..fb89633 100644
  --- a/requirements.txt
  +++ b/requirements.txt
  @@ -9 +9 @@ fixtures=0.3.14
  -oslo.config=1.4.0  # Apache-2.0
  +oslo.config=1.6.0  # Apache-2.0
  @@ -11 +11 @@ oslo.i18n=1.0.0  # Apache-2.0
  -oslo.utils=1.0.0   # Apache-2.0
  +oslo.utils=1.2.0   # Apache-2.0
  @@ -14 +14 @@ six=1.7.0
  -retrying=1.2.2,!=1.3.0 # Apache-2.0
  +retrying=1.2.3,!=1.3.0 # Apache-2.0
  diff --git a/test-requirements.txt b/test-requirements.txt
  index c424655..32cdaae 100644
  --- a/test-requirements.txt
  +++ b/test-requirements.txt
  @@ -5 +5 @@
  -hacking=0.9.1,0.10
  +hacking=0.10.0,0.11
  @@ -7,0 +8 @@ coverage=3.6
  +futures=2.1.6

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



Looks like we probably have a new bug in nova now:

http://goo.gl/i7qa0f

--

Thanks,

Matt Riedemann


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

[openstack-dev] [nova] request spec freeze exception for Add the StorPool volume attach/detach proposal

2015-01-13 Thread Peter Penchev

Hi,

I'd like to request an exception for Add the StorPool volume
attach/detach proposal.
https://review.openstack.org/#/c/115716/

This is a very simple driver that allows Nova virtual machines to use
StorPool distributed volumes (already created in Cinder) as additional
disks.  All that the driver does is pass the attach and detach
requests to the StorPool API; you can see the actual driver code (and
tests) at https://review.openstack.org/#/c/140733/ - it just received
a -2, but only because the spec itself is not approved :)

Thanks in advance for your time and consideration!

G'luck,
Peter

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

Re: [openstack-dev] [tc][python-clients] More freedom for all python clients

On 2015-01-13 19:53:28 +0400 (+0400), Boris Pavlovic wrote:
[...]
 P.S. It's sad that in one thread we are talking about making Big
 Tenant and how it is cool  to remove programs. In another we are
 blocking adding python clients from projects  that are not Core
 and suggesting another making incompatible with OpenStack. 

The big tent proposal is not just a free-for-all, and will entail
most of the same barriers to entry for officialness as you currently
see for programs (aside from addresses similar needs as a current
official team). Quality control and selectiveness of design will
still be extremely important, and I don't see our
openstack/requirements tooling, workflow and choices changing
significantly in the face of that.
-- 
Jeremy Stanley

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

Re: [openstack-dev] oslo.concurrency 0.4.0 released