date:20140620

[openstack-dev] [Congress] Error running scripts/run_api_server

2014-06-20 Thread Madhu Mohan Nelemane

Hi,

I recently cloned the latest Congress source code and tried to run
unit-tests on my Ubuntu PC. Using *scripts/run_api_server*, I found this
following error:


*Jun 20 11:28:11|0|__main__|INFO|Starting congress server*
*Traceback (most recent call last):*
*  File /usr/lib/python2.7/dist-packages/eventlet/greenpool.py, line 80,
in _spawn_n_impl*
*func(*args, **kwargs)*
*  File server.py, line 82, in ad_update_thread*
*ad_model.update_from_ad()  # XXX: blocks eventlet*
*  File /home/madhu/Project/policyFW/congress/congress/server/ad_sync.py,
line 72, in update_from_ad*
*l.simple_bind_s(BIND_USER, BIND_PW)*
*  File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 206, in
simple_bind_s*
*msgid = self.simple_bind(who,cred,serverctrls,clientctrls)*
*  File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 200, in
simple_bind*
*return
self._ldap_call(self._l.simple_bind,who,cred,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls))*
*  File /usr/lib/python2.7/dist-packages/ldap/ldapobject.py, line 96, in
_ldap_call*
*result = func(*args,**kwargs)*
*SERVER_DOWN: {'desc': Can't contact LDAP server}*
*(5065) wsgi starting up on http://0.0.0.0:8080/ http://0.0.0.0:8080/*

Does other guys face this error too ?
Am i missing any prerequisite to run the congress unit-test ?

make was successful and had no issues.

Please suggest a way to proceed further.

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

Re: [openstack-dev] [Mistral] Start task, and support for 'requires' / reverse workflow.

2014-06-20 Thread Renat Akhmerov

Just a clarification: “reverse” flow is what I usually call “dependency based 
flow” when we specify dependencies between tasks rather then direct transitions 
(do this then on success do that).

 * Put it off till the engine refactoring, factor the requirement of 
 supporting two modes into the refactoring. It will be easy to do, but takes 
 the longest. 


I personally would prefer this latest option since I don’t see any rush with 
refactoring the current API/impl to have two separate workflow types right now.

Renat Akhmerov
@ Mirantis Inc.



On 20 Jun 2014, at 12:33, Dmitri Zimine dzim...@stackstorm.com wrote:

 https://review.openstack.org/#/c/100390/
 
 Angus asked: 
 Why do we even need start: start-task?
 Can't we parse the workbook and figure out what to run? Tasks at the bottom 
 of the tree have no on-{fail,success} and then 
 follow upwards until you find a task that is not referenced by anything.
 
 Yes we can do this (patch almost ready). And It makes a perfect behavior for 
 a direct flow [1]: all the top-level tasks begin to execute in parallel, and 
 dependent tasks scheduled as dependencies resolve. No need to specify . 
 Parallel execution is a default, unless explicitly constrained by 
 on-success/on-error/on-finish. 
 
 But for Reversed flow [2] it’s a BIG change of behavior. Instead of running 
 only a subflow to satisfy a target task, it will run all the tasks 
 (respecting dependencies). This is not practical. 
 
 Eventually we want to support both direct and reverse as two types of 
 workflow, without mixing the two syntaxes within the same workflow. This will 
 require big refactoring (already planned). On the Atlanta summit we agreed to 
 temporarily drop reversed workflow and re-introduce it later. [3] The start 
 task in the API is a big pain for a direct flow. 
 
 How should we proceed? Options I can think of: 
 
 * Drop ‘reverse flow’ right now, stabilize ‘direct flow', reintroduce 
 ‘reverse flow’ later (next cycle).
 This will give us a clean final API on a good set of functionality, [almost] 
 immediately. 
 
 * Introduce two workflow types and correspondent API changes/additions on the 
 current code base, before refactoring. 
 
 * Put it off till the engine refactoring, factor the requirement of 
 supporting two modes into the refactoring. It will be easy to do, but takes 
 the longest. 
 
 Other options? Opinions? Requests?
 
 DZ  
 
 
 [1] Direct flow has dependencies expressed by on-success/on-error/on-finish 
 keyword on an upstream task
 [2] Reverse flow is where dependencies are expressed by requires keyword on a 
 downstream, dependent task
 [3] https://etherpad.openstack.org/p/mistral-post-POC-questions
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Cinder] request to review bug 1307491

2014-06-20 Thread Harshada Kakad

HI All,
Could someone please, review the bug
https://bugs.launchpad.net/cinder/+bug/1307491


Fixes cinder quota-update with wrong tenant-id

quota-update returns 200 (OK) even though specified tenant-id
does not exist.
  cinder quota-update wrong-tenant --gigabytes 2
The fix has been applied so that quota-update with wrong tenant-id will
display an error with TenantID not found


Here is the link for review: https://review.openstack.org/#/c/95464/


--
*Regards,*
*Harshada Kakad*
**
*Sr. Software Engineer*
*C3/101, Saudamini Complex, Right Bhusari Colony, Paud Road, Pune – 411013,
India*
*Mobile-9689187388*
*Email-Id : harshada.ka...@izeltech.com harshada.ka...@izeltech.com*
*website : www.izeltech.com http://www.izeltech.com*

-- 
*Disclaimer*
The information contained in this e-mail and any attachment(s) to this 
message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information of Izel 
Technologies Pvt. Ltd. If you are not the intended recipient, you are 
notified that any review, use, any form of reproduction, dissemination, 
copying, disclosure, modification, distribution and/or publication of this 
e-mail message, contents or its attachment(s) is strictly prohibited and 
you are requested to notify us the same immediately by e-mail and delete 
this mail immediately. Izel Technologies Pvt. Ltd accepts no liability for 
virus infected e-mail or errors or omissions or consequences which may 
arise as a result of this e-mail transmission.
*End of Disclaimer*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Octavia] PTL and core team members

2014-06-20 Thread Mark McLoughlin

On Thu, 2014-06-19 at 20:36 -0700, Dustin Lundquist wrote:
 Dolph,
 
 
 I appreciate the suggestion. In the mean time how does the review
 process work without core developers to approve gerrit submissions?

If you're just getting started, have a small number (possibly just 1 to
begin with) of developers collaborate closely, with the minimum possible
process and then use that list of developers as your core review team
when you gradually start adopting some process. Aim to get from zero to
bootstrapped with that core team in a small number of weeks at most.

Minimum possible process could mean a git repo anywhere that those
initial developers have direct push access to. You could use stackforge
from the beginning and the developers just approve their own changes,
but that's a bit annoying.

Mark.



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

[openstack-dev] [all] Juno setup

2014-06-20 Thread Yogesh Prasad

Hi All

I want to create a juno setup.

Please guide me through any links or processes that needs to be followed to
have this setup.

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

Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed

2014-06-20 Thread Sergii Golovatiuk

+1 for #2.

~Sergii


On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin ada...@mirantis.com wrote:

 +1 to Mike. Let the user provide actual credentials and use them in place.


 On Fri, Jun 20, 2014 at 2:01 AM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 I'm in favor of #2. I think users might not want to have their password
 stored in Fuel Master node.
 And if so, then it actually means we should not save it when user
 provides it on HealthCheck tab.


 On Thu, Jun 19, 2014 at 8:05 PM, Vitaly Kramskikh 
 vkramsk...@mirantis.com wrote:

 Hi folks,

 We have a bug https://bugs.launchpad.net/fuel/+bug/1281838 which
 prevents OSTF from working if user changes a password which was using for
 the initial installation. I skimmed through the comments and it seems there
 are 2 viable options:

1. Create a separate user just for OSTF during OpenStack installation
2. Provide a field for a password in UI so user could provide actual
password in case it was changed

 What do you guys think? Which options is better?

 --
 Vitaly Kramskikh,
 Software Engineer,
 Mirantis, Inc.

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




 --
 Mike Scherbakov
 #mihgen


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




 --
 Andrey Danin
 ada...@mirantis.com
 skype: gcon.monolake

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


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

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-06-20 Thread loy wolfe

GP should support applying policy on exist openstack deployment, so neither
implicit mapping nor intercepting works well.

maybe the explicit associating model is best: associate EPG with exist
neutron network object (policy automatically applied to all ports on it),
or with single port object (policy applied only on this port). By this way
GP will be more loosely coupled with Neutron core than the spec sample:
boot vm from a grand-new EP object, which need rewrite nova vif-plug, and
only support new deployment. It is suitable to put GP in orchestration
layer, etc, Heat, without bothering nova code. Boot vm from EPG can be
interpreted by ochestration with: 1) create port from network associated
with EGP; 2) boot nova from port. In the future we may also need a unified
abstract policy template across compute/stroage/network.

And, it's not a good idea to intercept neutron port create api for
implicitly EP binding(I don't know if this has been removed now), for it
severely break the hierarchy relationship between GP and neutron core. the
link from GP wiki to an ODL page clearly shows that GP should be layered on
top of both neutron and ODL(1st graph).

http://webcache.googleusercontent.com/search?q=cache:https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin#Relationship_with_OpenStack.2FNeutron_Policy_Model
(this link has hidden all picture from this week so I have to give the
google cache)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

96 matches

Mail list logo