Re: [openstack-dev] [oslo] zeromq work for kilo
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
[openstack-dev] [neutron] Can Neutron VPNaaS work with strongswan? (Openswan removed from Debian)
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] [api] Forming the API Working Group
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 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] "Starting iSCSI initiator service iscsid" failed while installing Devstack
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
[openstack-dev] [Heat][Trove][Horizon][Glance] New Juno RCs available
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
Re: [openstack-dev] [api] Forming the API Working Group
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
