Re: [openstack-dev] [api] Forming the API Working Group

2014-10-11 Thread Jay Pipes

Thanks for getting this going, Everett! Comments inline...

On 10/08/2014 07:05 PM, Everett Toews wrote:

https://wiki.openstack.org/wiki/API_Working_Group

This is the start of the API Working Group (API WG).


yay! :)


To avoid bike shedding over the name of the working group, I decided
to title the wiki page API Working Group. Simple, to the point, and
avoids loaded terms like standards, best practices, guidelines,
conventions, etc.


Yup, ++


The point isn’t what we name it. The point is what action we take
about it. I propose the deliverables in the API WG wiki page.

Speaking of the wiki page, I wrote it very matter-of-factly. As if
this is the way things are. They’re not. The wiki page is just a
starting point. If something was missed, add it. If something can be
improved, improve it. Let’s try to keep it simple though.


The wiki content looks fine, with the exception that I really do feel 
the working group needs to have some ability to review and enforce 
consistency within proposed REST APIs. The wording right now is:


The API WG is focused on creating guidelines for the APIs

which of course is fine, but I think that the Technical Committee should 
essentially grant the working group the power to enforce guidelines and 
consistency for proposed new REST APIs -- whether it's a new REST API 
version in an existing project or a REST APi for a newly-proposed 
OpenStack server project.



I invite everyone who chimed in on the original thread [1] that
kicked this off to add themselves as a member committed to making the
OpenStack APIs better. I’ve Cc’d everyone who asked to be kept in the
loop.

I already see some cross project summit topics [2] on APIs. But
frankly, with the number of people committed to this topic, I’d
expect there to be more. I encourage everyone to submit more API
related sessions with better descriptions and goals about what you
want to achieve in those sessions.


Will do.

Best,
-jay


Regards, Everett

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046850.html
[2] https://etherpad.openstack.org/p/kilo-crossproject-summit-topics


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


[openstack-dev] [Heat][Trove][Horizon][Glance] New Juno RCs available

2014-10-11 Thread Thierry Carrez
Hello everyone,

Due to various issues discovered in the published 2014.2 release
candidates, we regenerated new Juno release candidates for Heat, Trove,
Horizon and Glance. You can find the list of bugfixes in these RCs and
links to source tarballs at:

https://launchpad.net/heat/juno/juno-rc3
https://launchpad.net/trove/juno/juno-rc2
https://launchpad.net/horizon/juno/juno-rc2
https://launchpad.net/glance/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, these RCs will be formally released as the 2014.2
final version on October 16. You are therefore strongly encouraged to
test and validate these tarballs ! Please pay extra attention to Glance
RC2, which went through a large number of changes for an RC this late in
the cycle.

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/heat/tree/proposed/juno
https://github.com/openstack/trove/tree/proposed/juno
https://github.com/openstack/horizon/tree/proposed/juno
https://github.com/openstack/glance/tree/proposed/juno

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

https://bugs.launchpad.net/heat/+filebug
https://bugs.launchpad.net/trove/+filebug
https://bugs.launchpad.net/horizon/+filebug
https://bugs.launchpad.net/glance/+filebug

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

Regards,

-- 
Thierry Carrez (ttx)

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


[openstack-dev] Starting iSCSI initiator service iscsid failed while installing Devstack

2014-10-11 Thread Nitika
Hi,

I'm trying to install devstack on Ubuntu but getting the following error :
Please note that I'm not using any proxy to access the internet.


After this operation, 0 B of additional disk space will be used.
Setting up open-iscsi (2.0.871-0ubuntu9.12.04.2) ...
update-rc.d: warning: open-iscsi stop runlevel arguments (0 1 6) do not
match LSB Default-Stop values (0 6)
 * Starting iSCSI initiator service
iscsid[fail]
 * Setting up iSCSI
targets   [ OK ]
invoke-rc.d: initscript open-iscsi, action start failed.
dpkg: error processing open-iscsi (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 open-iscsi
E: Sub-process /usr/bin/dpkg returned an error code (1)
+ exit_trap
+ local r=100
++ jobs -p
+ jobs=
+ [[ -n '' ]]
+ kill_spinner
+ '[' '!' -z '' ']'
+ [[ 100 -ne 0 ]]
+ echo 'Error on exit'
Error on exit
+ [[ -z '' ]]
+ /home/user21/devstack/tools/worlddump.py
World dumping... see ./worlddump-2014-10-11-171333.txt for details
+ exit 100



See the output of worlddump.py file :


File System Summary
===

Filesystem  Size  Used Avail Use% Mounted on
/dev/simfs   10G  1.9G  8.2G  19% /
none 52M  1.1M   51M   2% /run
none5.0M 0  5.0M   0% /run/lock
none256M 0  256M   0% /run/shm


Process Listing
===

USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.3  24164  2084 ?Ss   May22   0:00 init
root 2  0.0  0.0  0 0 ?SMay22   0:00
[kthreadd/14143]
root 3  0.0  0.0  0 0 ?SMay22   0:00
[khelper/14143]
mongodb297  0.2  2.8 984652 14964 ?Ssl  May22 607:00
/usr/bin/mongod --config /etc/mongodb.conf
bind   454  0.0  6.3 1321880 33296 ?   Ssl  May22   3:27
/usr/sbin/named -u bind
root 17882  0.0  0.5  49996  2952 ?Ss   07:05   0:00
/usr/sbin/sshd -D
root 18276  0.0  0.1  19072  1044 ?Ss   Sep25   0:01 cron
root 18283  0.0  0.0  17192   524 ?SSep25   0:00
upstart-udev-bridge --daemon
root 18287  0.0  0.1  15148   604 ?SSep25   0:00
upstart-socket-bridge --daemon
root 18296  0.0  0.2  21556  1324 ?Ss   Sep25   0:00
/sbin/udevd --daemon
101  18297  0.0  0.2  23776  1284 ?Ss   Sep25   0:00
dbus-daemon --system --fork --activation=upstart
mysql18309  0.0  8.0 523244 41948 ?Ssl  Sep25   4:26
/usr/sbin/mysqld
syslog   19719  0.0  0.1  12712   864 ?Ss   Sep26   0:03
/sbin/syslogd -u syslog
root 21277  0.0  0.6  73400  3632 ?Ss   21:12   0:00 sshd:
user21 [priv]
user2121289  0.0  0.3  73400  1660 ?S21:12   0:00 sshd:
user21@pts/0
user2121290  0.0  0.4  18176  2200 pts/0Ss   21:12   0:00 -bash
user2121305  0.6  1.0  12920  5292 pts/0S+   21:12   0:00 bash
./stack.sh
user2121409  0.0  0.3  10648  1888 pts/0S+   21:12   0:00 bash
./stack.sh
user2121410  0.0  1.2  34532  6632 pts/0S+   21:12   0:00 python
/home/user21/work/devstack/tools/outfilter.py -v
user2122030  0.0  1.2  34540  6624 pts/0S+   21:13   0:00 python
/home/user21/work/devstack/tools/worlddump.py
user2122033  0.0  0.1   4360   636 pts/0S+   21:13   0:00 sh -c ps
auxw
user2122034  0.0  0.2  15236  1140 pts/0R+   21:13   0:00 ps auxw




I didn't find any best possible solution to resolve this issue.

Please help me resolve this issue.


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


Re: [openstack-dev] [api] Forming the API Working Group

2014-10-11 Thread Preston L. Bannister
Tricky. First, I am new to OpenStack, and as such tend to want to shut-up
and listen.

Second, I have done APIs for distributed systems for over 30 years. Yes, I
got in very early. As such I am guilty of or saw lots of bad examples. Also
I found patterns that worked very well.

That said, the approach to APIs and versioning in OpenStack ... does not
make sense, to me. Seems a mess. Maybe I am wrong. Or not.

The notion of a group that offers living advice to the various OpenStack
projects on APIs is - I think - a good notion. Written guidelines are good,
to a point, but only that. Interpreting static documents has limits.

My current impression is the folk offering APIs need help. So if this
offering evaluates in the end as help, this is a good idea. :)



On Fri, Oct 10, 2014 at 9:09 AM, Jay Pipes jaypi...@gmail.com wrote:

 Thanks for getting this going, Everett! Comments inline...

 On 10/08/2014 07:05 PM, Everett Toews wrote:

 https://wiki.openstack.org/wiki/API_Working_Group

 This is the start of the API Working Group (API WG).


 yay! :)

  To avoid bike shedding over the name of the working group, I decided
 to title the wiki page API Working Group. Simple, to the point, and
 avoids loaded terms like standards, best practices, guidelines,
 conventions, etc.


 Yup, ++

  The point isn’t what we name it. The point is what action we take
 about it. I propose the deliverables in the API WG wiki page.

 Speaking of the wiki page, I wrote it very matter-of-factly. As if
 this is the way things are. They’re not. The wiki page is just a
 starting point. If something was missed, add it. If something can be
 improved, improve it. Let’s try to keep it simple though.


 The wiki content looks fine, with the exception that I really do feel the
 working group needs to have some ability to review and enforce consistency
 within proposed REST APIs. The wording right now is:

 The API WG is focused on creating guidelines for the APIs

 which of course is fine, but I think that the Technical Committee should
 essentially grant the working group the power to enforce guidelines and
 consistency for proposed new REST APIs -- whether it's a new REST API
 version in an existing project or a REST APi for a newly-proposed OpenStack
 server project.

  I invite everyone who chimed in on the original thread [1] that
 kicked this off to add themselves as a member committed to making the
 OpenStack APIs better. I’ve Cc’d everyone who asked to be kept in the
 loop.

 I already see some cross project summit topics [2] on APIs. But
 frankly, with the number of people committed to this topic, I’d
 expect there to be more. I encourage everyone to submit more API
 related sessions with better descriptions and goals about what you
 want to achieve in those sessions.


 Will do.

 Best,
 -jay


  Regards, Everett

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-
 September/046850.html
 [2] https://etherpad.openstack.org/p/kilo-crossproject-summit-topics


 ___
 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] [neutron] Can Neutron VPNaaS work with strongswan? (Openswan removed from Debian)

2014-10-11 Thread Thomas Goirand
Hi,

As you may know, OpenSwan has been largely unmaintained in Debian, and
then was removed from Testing, and then Sid last summer. OpenSwan had
some unaddressed security issues, and removing it from Debian was IMO
the correct thing to do. Ubuntu followed, and Utopic doesn't have
OpenSwan anymore either.

Though there's StrongSwan, which is apparently an alternative. But can
Neutron work with it? If not, how much work would it be to make Neutron
use StrongSwan instead of OpenSwan, and could the maintainers of the
VPNaaS people do this be worked on for Kilo? BTW, why not using
something as popular as OpenVPN, which has more chances to be well
maintained?

Cheers,

Thomas Goirand (zigo)

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


Re: [openstack-dev] [oslo] zeromq work for kilo

2014-10-11 Thread Li Ma


On 2014/9/17 22:34, Doug Hellmann wrote:


The documentation in the oslo.messaging repository [2] would be a good place to 
start for that. If we decide deployers/operators need the information we can 
either refer to it from the guides managed by the documentation team or we can 
move/copy the information. How about if you start a new drivers subdirectory 
there, and add information about zmq. We can have other driver authors provide 
similar detail about their drivers in the same directory.

[2] http://git.openstack.org/cgit/openstack/oslo.messaging/tree/doc/source
Hi all, I wrote a deployment guide of ZeroMQ for oslo.messaging, which 
is located at


https://github.com/li-ma/zmq-for-oslo

Do I need to issue a bug or propose a blueprint to trace and merge it to 
oslo.messaging doc tree?



3) an analysis of what it would take to be able to run functional
tests for zeromq on our CI infrastructure, not necessarily the full
tempest run or devstack-gate job, probably functional tests we place
in the tree with the driver (we will be doing this for all of the
drivers) + besides writing new functional tests, we need to bring the
unit tests for zeromq into the oslo.messaging repository

Kapil Thangavelu started work on both functional tests for the ZMQ
driver last week; the output from the sprint is here:

https://github.com/ostack-musketeers/oslo.messaging

it covers the ZMQ driver (including messaging through the zmq-receiver
proxy) and the associated MatchMakers (local, ring, redis) at a
varying levels of coverage, but I feel it moves things in the right
direction - Kapil's going to raise a review for this in the next
couple of days.

Doug - has any structure been agreed within the oslo.messaging tree
for unit/functional test splits? Right now we have them all in one place.

I think we will want them split up, but we don’t have an agreed existing 
structure for that. I would like to see a test framework of some sort that 
defines the tests in a way that can be used to run the same functional for all 
of the drivers as separate jobs (with appropriate hooks for ensuring the needed 
services are running, etc.). Setting that up warrants its own spec, because 
there are going to be quite a few details to work out. We will also need to 
participate in the larger conversation about how to set up those functional 
test jobs to be consistent with the other projects.
That's good to hear someone working on the test stuff. I suggest to deal 
with the unit tests first for ZeroMQ.


Anyway, are there any sessions related to this topic in the summit?

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