Re: [openstack-dev] [Neutron] Stale patches
-Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, November 18, 2014 9:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Stale patches +1. I always hesitate to abandon someone's patch because it is so personal. The auto-expire is impersonal and procedural. I agree that 1 week is too soon. Give it at least a month. +1 I am not concentrating on Neutron devs, but I also have the same feeling on the other area devs. I also cannot abandon the other developers' patches even if non-activities against some negative feedback. Thanks Ken'ichi Ohmichi --- Abandoned patches that have some importance shouldn't ever really be lost. They should be linked to bug reports or blueprints to which they're related. So, why do we need to keep them around while there is no activity on them? Carl On Mon, Nov 17, 2014 at 11:45 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: Perhaps we should re-introduce the auto-expiration of patches, albeit on a very leisurely timeframe. Before, it was like 1 week to expire a patch, which was a bit aggressive. Perhaps we could auto-expire patches that haven't been touched in 4 or 6 weeks, to expire patches that have truly been abandoned by authors? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 18/11/14 00:59, Richard Jones wrote: On 17 November 2014 21:54, Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: - Bower in the development environment, - Bower configuration file in two copies, one for global-requirements, and one for the Horizon's local requirements. Plus a gate job that makes sure no new library or version gets included in the Horizon's before getting into the global-requirements, Could you perhaps elaborate on this? How do you see the workflow working here? Basically we would have an additional file in the global-requirements directory, for listing the JavaScript dependencies. Then we would have a check on the Horizon's gate that would check Horizon's Bower configuration against that global-requirements file. This way we keep the same process for JavaScript libraries as we have for Python libraries: first you submit a patch to the global-requirements and have the dependency accepted by the infra team and packagers (checked against licenses, version conflicts, etc.), and then you add it to Horizon's dependencies. Of course you can submit both patches at once, just the Horizon one will fail the gate until the global-requirements one gets merged. Given that Horizon already integrates with xstatic, it would be messy (and potentially confusing) to include something so it *also* integrated with bower. I was envisaging us creating a tool which generates xstatic packages from bower packages. I'm not the first to think along these lines http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html If we use Bower, we don't need to use Xstatic. It would be pure overhead. Bower already takes care of tracking releases and versions, and of bundling the files. All we need is a simple line in the settings.py telling Django where it puts all the files -- we don't really need Xstatic just for that. The packagers can then take those Bower packages and turn them into system packages, and just add/change the paths in settings.py to where they put the files. All in one place. I will be looking into creating such a tool today. The problem is not the work that has to be done for the initial creation of the package. That is one-time effort and as you show, it can be easily automated. The problem is the effort and resources needed to maintain that package. Someone (the author of the package?) has to check for security vulnerabilities, critical bugs, packaging issues, changing licenses, etc. and patch/update the packages accordingly. Also, the more layers of code you have, them more likely you are to have bugs in the. Again, I see no reason to duplicate the effort if the Bower packagers are doing that work for us already (they are, are they?). -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Can't run tests
Hi, You should install mysql-dev for your distro using apt-get or yum. Regards, Vineet Menon On 18 November 2014 09:16, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, I'm trying to run nova's unittests to validate some changes we made for a LibvirtVolumeDriver class, but i only got errors: with virtual env: ... Downloading/unpacking MySQL-python (from -r /opt/stack/nova/test-requirements.txt (line 13)) Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded Running setup.py (path:/opt/stack/nova/.venv/build/MySQL-python/setup.py) egg_info for package MySQL-python sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Complete output from command python setup.py egg_info: sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Cleaning up... Command python setup.py egg_info failed with error code 1 in /opt/stack/nova/.venv/build/MySQL-python Storing debug log for failure in /root/.pip/pip.log Command tools/with_venv.sh pip install --upgrade -r /opt/stack/nova/requirements.txt -r /opt/stack/nova/test-requirements.txt failed. None without virtual env: :/opt/stack/nova# ./run_tests.sh -N Running ` python -m nova.openstack.common.lockutils python setup.py testr --testr-args='--subunit --concurrency 0 '` Non-zero exit code (2) from test listing. error: testr failed (3) Ran 0 tests in 4.792s OK Running flake8 ... **WARNING**: Running flake8 without virtual env may miss OpenStack HACKING detection bash: flake8: command not found nova-manage --version 2014.2.1 Any idea how to fix this? Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ 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] Zero MQ remove central broker. Architecture change.
On 2014/11/17 23:03, Eric Windisch wrote: On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny ipeke...@mirantis.com mailto:ipeke...@mirantis.com wrote: We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. Actual architecture uses uncharacteristic single broker architecture model. In this way we are ignoring the key 0MQ ideas. Lets describe our message in quotes from ZeroMQ documentation: The oslo.messaging driver is not using a single broker. It is designed for a distributed broker model where each host runs a broker. I'm not sure where the confusion comes from that implies this is a single-broker model? All of the points you make around negotiation and security are new concepts introduced after the initial design and implementation of the ZeroMQ driver. It certainly makes sense to investigate what new features are available in ZeroMQ (such as CurveCP) and to see how they might be leveraged. That said, quite a bit of trial-and-error and research went into deciding to use an opposing PUSH-PULL mechanism instead of REQ/REP. Most notably, it's much easier to make PUSH/PULL reliable than REQ/REP. Hi Eric. In our production deployment, We rely on ZeroMQ driver much because we have more than one thousand physical machines to run OpenStack. The distributed nature of ZeroMQ provide more scalable messaging plane than RabbitMQ. However, as you know, the driver codebase is not that mature and stable. The first problem we faced is that we cannot guarantee the status when delivering messages via PULL/PUSH. Because there's no ACK for this model. We are discussing the possibility to change from PULL/PUSH to REQ/REP. But here you said that it is much easier to make PUSH/PULL reliable than REQ/REP. Do you have some idea or concern to improve the reliability of the current model? cheers, Li Ma ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
On 2014/11/17 22:26, Russell Bryant wrote: On 11/17/2014 05:44 AM, Ilya Pekelny wrote: Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. On a related note, have you looked into AMQP 1.0 at all? I have been hopeful about the development to support it because of these same reasons. The AMQP 1.0 driver is now merged. I'd really like to see some work around trying it out with the dispatch router [1]. It seems like using amqp 1.0 + a distributed network of disaptch routers could be a very scalable approach. We still need to actually try it out and do some scale and performance testing, though. [1] http://qpid.apache.org/components/dispatch-router/ The design of dispatch-router is appealing. However I have some concern about qpid and the library. Is it reliable? Is there any success story of large deployment scenario about it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
On 2014/11/17 18:44, Ilya Pekelny wrote: Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. Actual architecture uses uncharacteristic single broker architecture model. In this way we are ignoring the key 0MQ ideas. Lets describe our message in quotes from ZeroMQ documentation: * ZeroMQ has the core technical goals of simplicity and scalability, the core social goal of gathering together the best and brightest minds in distributed computing to build real, lasting solutions, and the political goal of breaking the old hegemony of centralization, as represented by most existing messaging systems prior to ZeroMQ. * The ZeroMQ Message Transport Protocol (ZMTP) is a transport layer protocol for exchanging messages between two peers over a connected transport layer such as TCP. * The two peers agree on the version and security mechanism of the connection by sending each other data and either continuing the discussion, or closing the connection. * The two peers handshake the security mechanism by exchanging zero or more commands. If the security handshake is successful, the peers continue the discussion, otherwise one or both peers closes the connection. * Each peer then sends the other metadata about the connection as a final command. The peers may check the metadata and each peer decides either to continue, or to close the connection. * Each peer is then able to send the other messages. Either peer may at any moment close the connection. From the current code docstring: ZmqBaseReactor(ConsumerBase): A consumer class implementing a centralized casting broker (PULL-PUSH). Hi, Ilya, thanks for raising this topic. Inline you discussed about the ZeroMQ nature, but I still cannot find any directions to how to refactor or redesign the ZeroMQ driver for olso.messaging. :- Could you provide more details about how you think of it? This approach is pretty unusual for ZeroMQ. Fortunately we have a bit of raw developments around the problem. These changes can introduce performance improvement. But to proof it we need to implement all new features, at least at WIP status. So, I need to be sure that the community doesn't avoid such of improvements. For community works, AFAIK, we'd first initialize CI for ZeroMQ. After that, we can work together on how to improve performance, reliability and scalability of ZeroMQ driver. cheers, Li Ma ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
Thank you, Eric, for your descriptions! I'm very new to rpc and oslo.messaging. So I can be wrong in the idea of how it all designed and I can be wrong in a particular formulations. But I'm highly motivated in improvement of the rpc/oslo.messaging knowledge. I'm going to clarify all your descriptions and come back with updated propositions. Thank you, Russell, for your proposition! I'll pay attention to AMQP 1.0 as soon as possible. I'm not sure I can take it all to work but for sure I'll have an understanding about AMQP 1.0 in a nearest future. On Mon, Nov 17, 2014 at 5:03 PM, Eric Windisch e...@windisch.us wrote: On Mon, Nov 17, 2014 at 5:44 AM, Ilya Pekelny ipeke...@mirantis.com wrote: We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. Actual architecture uses uncharacteristic single broker architecture model. In this way we are ignoring the key 0MQ ideas. Lets describe our message in quotes from ZeroMQ documentation: The oslo.messaging driver is not using a single broker. It is designed for a distributed broker model where each host runs a broker. I'm not sure where the confusion comes from that implies this is a single-broker model? All of the points you make around negotiation and security are new concepts introduced after the initial design and implementation of the ZeroMQ driver. It certainly makes sense to investigate what new features are available in ZeroMQ (such as CurveCP) and to see how they might be leveraged. That said, quite a bit of trial-and-error and research went into deciding to use an opposing PUSH-PULL mechanism instead of REQ/REP. Most notably, it's much easier to make PUSH/PULL reliable than REQ/REP. From the current code docstring: ZmqBaseReactor(ConsumerBase): A consumer class implementing a centralized casting broker (PULL-PUSH). This approach is pretty unusual for ZeroMQ. Fortunately we have a bit of raw developments around the problem. These changes can introduce performance improvement. But to proof it we need to implement all new features, at least at WIP status. So, I need to be sure that the community doesn't avoid such of improvements. Again, the design implemented expects a broker running per machine (the zmq-receiver process). Each machine might have multiple workers all pulling messages from queues. Initially, the driver was designed such that each topic was mapped to its own ip:port, but this was not friendly to having arbitrary consumers of the library and required a port mapping file be distributed with the application. Plus, it's valid to have multiple consumers of a topic on a given host, something that is only possible with a distributed broker. As I left the driver, long review queues prevented me from merging a pile of changes to improve performance and increase reliability. I believe the architecture is still sound, even if much of the code itself is bad. What this driver needs is major cleanup, refactoring, and better testing. Regards, Eric Windisch ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Can't run tests
Thanks Vineet. Indeed missing packages was the problem, for completeness here are the packages i needed in order to get virtual env running on Ubuntu 14.04.1 LTS - libmysqlclient-dev - pkg-config - libvirt-dev Maybe they can be included in the script that sets up the virtual env. Thanks, Eduard On Tue, Nov 18, 2014 at 10:27 AM, Vineet Menon mvineetme...@gmail.com wrote: Hi, You should install mysql-dev for your distro using apt-get or yum. Regards, Vineet Menon On 18 November 2014 09:16, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, I'm trying to run nova's unittests to validate some changes we made for a LibvirtVolumeDriver class, but i only got errors: with virtual env: ... Downloading/unpacking MySQL-python (from -r /opt/stack/nova/test-requirements.txt (line 13)) Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded Running setup.py (path:/opt/stack/nova/.venv/build/MySQL-python/setup.py) egg_info for package MySQL-python sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Complete output from command python setup.py egg_info: sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Cleaning up... Command python setup.py egg_info failed with error code 1 in /opt/stack/nova/.venv/build/MySQL-python Storing debug log for failure in /root/.pip/pip.log Command tools/with_venv.sh pip install --upgrade -r /opt/stack/nova/requirements.txt -r /opt/stack/nova/test-requirements.txt failed. None without virtual env: :/opt/stack/nova# ./run_tests.sh -N Running ` python -m nova.openstack.common.lockutils python setup.py testr --testr-args='--subunit --concurrency 0 '` Non-zero exit code (2) from test listing. error: testr failed (3) Ran 0 tests in 4.792s OK Running flake8 ... **WARNING**: Running flake8 without virtual env may miss OpenStack HACKING detection bash: flake8: command not found nova-manage --version 2014.2.1 Any idea how to fix this? Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ 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 -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering
[openstack-dev] [nova] Do we have a meeting this week?
Dear Americans... you're not really going to come to a meeting this week are you? There's that thanks giving thing, right? So... Should we cancel for this week? Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
Thank you, Li Ma! Yes, sure I'm going to provide more detailed mail with a solid propositions list. I need to do some knowledge updates before I provide it. On Tue, Nov 18, 2014 at 10:40 AM, Li Ma skywalker.n...@gmail.com wrote: On 2014/11/17 18:44, Ilya Pekelny wrote: Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. Actual architecture uses uncharacteristic single broker architecture model. In this way we are ignoring the key 0MQ ideas. Lets describe our message in quotes from ZeroMQ documentation: - ZeroMQ has the core technical goals of simplicity and scalability, the core social goal of gathering together the best and brightest minds in distributed computing to build real, lasting solutions, and the political goal of breaking the old hegemony of centralization, as represented by most existing messaging systems prior to ZeroMQ. - The ZeroMQ Message Transport Protocol (ZMTP) is a transport layer protocol for exchanging messages between two peers over a connected transport layer such as TCP. - The two peers agree on the version and security mechanism of the connection by sending each other data and either continuing the discussion, or closing the connection. - The two peers handshake the security mechanism by exchanging zero or more commands. If the security handshake is successful, the peers continue the discussion, otherwise one or both peers closes the connection. - Each peer then sends the other metadata about the connection as a final command. The peers may check the metadata and each peer decides either to continue, or to close the connection. - Each peer is then able to send the other messages. Either peer may at any moment close the connection. From the current code docstring: ZmqBaseReactor(ConsumerBase): A consumer class implementing a centralized casting broker (PULL-PUSH). Hi, Ilya, thanks for raising this topic. Inline you discussed about the ZeroMQ nature, but I still cannot find any directions to how to refactor or redesign the ZeroMQ driver for olso.messaging. :- Could you provide more details about how you think of it? This approach is pretty unusual for ZeroMQ. Fortunately we have a bit of raw developments around the problem. These changes can introduce performance improvement. But to proof it we need to implement all new features, at least at WIP status. So, I need to be sure that the community doesn't avoid such of improvements. For community works, AFAIK, we'd first initialize CI for ZeroMQ. After that, we can work together on how to improve performance, reliability and scalability of ZeroMQ driver. cheers, Li Ma ___ 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] [Ironic] Proposing new meeting times
On 11/18/2014 02:00 AM, Devananda van der Veen wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. +1 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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] [oslo.messaging] ZeroMQ driver maintenance next steps
We should build a simple app using the Oslo libraries that we can place in the oslo.messaging source tree to use for exercising the communication patterns of the library with different drivers. Ideally that would be a single app (or set of apps) that could be used to test all drivers, with tests written against the app rather than the driver. Once we have the app and tests, we can define a new gate job to run those tests just for oslo.messaging, with a different configuration for each driver we support. Doug Provided a blueprint for it https://blueprints.launchpad.net/oslo.messaging/+spec/oslo-functional-testing-apps On 17.11.14 23:53, Doug Hellmann wrote: On Nov 17, 2014, at 3:36 PM, Joshua Harlow harlo...@outlook.com wrote: Doug Hellmann wrote: On Nov 17, 2014, at 10:01 AM, Denis Makogondmako...@mirantis.com wrote: On Mon, Nov 17, 2014 at 4:26 PM, James Pagejames.p...@ubuntu.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Denis On 17/11/14 07:43, Denis Makogon wrote: During Paris Design summit oslo.messaging session was raised good question about maintaining ZeroMQ driver in upstream (see section “dropping ZeroMQ support in oslo.messaging” at [1]) . As we all know, good thoughts are comming always after. I’d like to propose several improvements in process of maintaining and developing of ZeroMQ driver in upstream. Contribution focus. As we all see, that there are enough patches that are trying to address certain problems related to ZeroMQ driver. Few of them trying to add functional tests, which is definitely good, but … there’s always ‘but’, they are not “gate”-able. I'm not sure I understand you statement about them not being gate-able - the functional/unit tests currently proposed for the zmq driver run fine as part of the standard test suite execution - maybe the confusion is over what 'functional' actually means, but in my opinion until we have some level of testing of this driver, we can't effectively make changes and fix bugs. I do agree that there's a confusion what functional testing means. Another thing, what the best solution is? Unit tests are welcome, but they are still remain to be units (they are using mocks, etc.) I'd try to define what 'fuctional testing' means for me. Functional testing in oslo.messaging means that we've been using real service for messaging (in this case - deployed 0mq). So, the simple definition, in term os OpenStack integration, we should be able to run full Tempest test suit for OpenStack services that are using oslo.messaging with enabled zmq driver. Am i right or not? That’s a good goal, but that’s not what I had in mind for in-tree functional tests. We should build a simple app using the Oslo libraries that we can place in the oslo.messaging source tree to use for exercising the communication patterns of the library with different drivers. Ideally that would be a single app (or set of apps) that could be used to test all drivers, with tests written against the app rather than the driver. Once we have the app and tests, we can define a new gate job to run those tests just for oslo.messaging, with a different configuration for each driver we support. Doug An interesting idea that might be useful that taskflow implemented/has done... The examples @ https://github.com/openstack/taskflow/tree/master/taskflow/examples all get tested during unit test runs to ensure they work as expected. This seems close to your 'simple app' (where app is replaced with example), it might be nice to have a similar approach for oslo.messaging that has 'examples' that are these apps that get ran to probe the functionality of oslo.messaging (as well as useful for documentation to show people how to use it, which is the other usage taskflow has for these examples) The hacky example tester could likely be shared (or refactored, since it probably needs it), https://github.com/openstack/taskflow/blob/master/taskflow/tests/test_examples.py#L91 Sure, that would be a good way to do it, too. Doug My proposal for this topic is to change contribution focus from oslo.messaging by itself to OpenStack/Infra project and DevStack (subsequently to devstack-gate too). I guess there would be questions “why?”. I think the answer is pretty obvious: we have driver that is not being tested at all within DevStack and project integration. This was discussed in the oslo.messaging summit session, and re-enabling zeromq support in devstack is definately on my todo list, but I don't think the should block landing of the currently proposed unit tests on oslo.messaging. For example https://review.openstack.org/#/c/128233/ says about adding functional and units. I'm ok with units, but what about functional tests? Which oslo.messaging gate job runs them? Also i’d say that such focus re-orientation would be very useful as source of use cases and bugs eventually. Here’s a list of what we, as team, should do first: 1. Ensure that DevStack can
Re: [openstack-dev] [Ironic] Changing our weekly meeting format
On Mon, Nov 17, 2014 at 8:58 PM, Devananda van der Veen devananda@gmail.com wrote: Lucas, Thanks for bringing this up (both in Paris and here). I'm strongly in favor of these changes as well. We discussed this during the meeting today [1], to which I offer the following summary: - move the status reporting to the etherpad [2] -- take one (1) minute at the start of the meeting for folks to look at the 'pad and raise any concerns. discuss concerns but cap at ten (10) minutes We might not want to cap at fixed time like 10 minutes, if there's something to discuss we can go ahead and discuss it. I like the way you put on the wiki: Review subteam status reports (capped at one minute, unless concerns are raised) -- at the end of the meeting, an email will be sent out containing the status report from the 'pad, plus discussion notes (if needed) - meeting agenda to be frozen two (2) days before the meeting. This also gives time for others to review/research the topic ahead of time. Anyone who has something on the planned agenda should prepare some notes to introduce the topic (or type fast enough that we don't notice that you didn't prepare) so we aren't all waiting on IRC. I'll update the meeting wiki accordingly. Ta much for that, looks great! Lucas -Deva [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html [2] https://etherpad.openstack.org/IronicWhiteBoard On Thu Nov 13 2014 at 8:58:18 AM Chris K nobody...@gmail.com wrote: +1 I think the best use of our time is to discuss new features and functions that may have a api or functional impact for ironic or projects that depend on ironic. Chris Krelle On Thu, Nov 13, 2014 at 8:22 AM, Ghe Rivero g...@debian.org wrote: I agree that a lot of time is missed with the announcement and status reports, but mostly because irc is a slow bandwidth communication channel (like waiting several minutes for a 3 lines announcement to be written) I propose that any announcement and project status must be written in advanced to an etherpad, and during the irc meeting just have a slot for people to discuss anything that need further explanation, only mentioning the topic but not the content. Ghe Rivero On Nov 13, 2014 5:08 PM, Peeyush Gupta gpeey...@linux.vnet.ibm.com wrote: +1 I agree with Lucas. Sounds like a good idea. I guess if we could spare more time for discussing new features and requirements rather than asking for status, that would be helpful for everyone. On 11/13/2014 05:45 PM, Lucas Alvares Gomes wrote: This was discussed in the Contributor Meetup on Friday at the Summit but I think it's important to share on the mail list too so we can get more opnions/suggestions/comments about it. In the Ironic weekly meeting we dedicate a good time of the meeting to do some announcements, reporting bug status, CI status, oslo status, specific drivers status, etc... It's all good information, but I believe that the mail list would be a better place to report it and then we can free some time from our meeting to actually discuss things. Are you guys in favor of it? If so I'd like to propose a new format based on the discussions we had in Paris. For the people doing the status report on the meeting, they would start adding the status to an etherpad and then we would have a responsible person to get this information and send it to the mail list once a week. For the meeting itself we have a wiki page with an agenda[1] which everyone can edit to put the topic they want to discuss in the meeting there, I think that's fine and works. The only change about it would be that we may want freeze the agenda 2 days before the meeting so people can take a look at the topics that will be discussed and prepare for it; With that we can move forward quicker with the discussions because people will be familiar with the topics already. Let me know what you guys think. [1] https://wiki.openstack.org/wiki/Meetings/Ironic Lucas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Peeyush Gupta gpeey...@linux.vnet.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Ironic] Proposing new meeting times
On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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] [Ironic] A mascot for Ironic
lol +1 for the drum set. I'll try to draw something like that soonish. Also, we got some fair amount of names proposed[1] already (thanks y'all). I will wait until tomorrow evening (18:00 UTC) and send out a pool to finally decide how we're going to call the bear :) [1] https://etherpad.openstack.org/p/IronicWhiteBoard (At the bottom) On Mon, Nov 17, 2014 at 9:42 PM, Devananda van der Veen devananda@gmail.com wrote: This whole thread is made of awesome. Adding a drum kit that's built out of servers is just piling on more awesome. Cheers for the great mascot drawings, Lucas! Deva On Mon Nov 17 2014 at 8:20:09 AM Jim Rollenhagen j...@jimrollenhagen.com wrote: On Sun, Nov 16, 2014 at 01:14:13PM +, Lucas Alvares Gomes wrote: Hi Ironickers, I was thinking this weekend: All the cool projects does have a mascot so I thought that we could have one for Ironic too. The idea about what the mascot would be was easy because the RAX guys put bear metal their presentation[1] and that totally rocks! So I drew a bear. It also needed an instrument, at first I thought about a guitar, but drums is actually my favorite instrument so I drew a pair of drumsticks instead. The drawing thing wasn't that hard, the problem was to digitalize it. So I scanned the thing and went to youtube to watch some tutorials about gimp and inkspace to learn how to vectorize it. Magic, it worked! Attached in the email there's the original draw, the vectorized version without colors and the final version of it (with colors). Of course, I know some people does have better skills than I do, so I also attached the inkspace file of the final version in case people want to tweak it :) So, what you guys think about making this little drummer bear the mascot of the Ironic project? Ahh he also needs a name. So please send some suggestions and we can vote on the best name for him. [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90 Lucas +1000, this is awesome. A cool variation would be to put a drum set behind the bear, made out of servers. :) // jim ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposing new meeting times
+1 for Option #2 On Tue, Nov 18, 2014 at 5:56 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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 -- *Intel SSG/STO/BDT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Can't run tests
Le 18/11/2014 10:11, Eduard Matei a écrit : Thanks Vineet. Indeed missing packages was the problem, for completeness here are the packages i needed in order to get virtual env running on Ubuntu 14.04.1 LTS - libmysqlclient-dev - pkg-config - libvirt-dev Maybe they can be included in the script that sets up the virtual env. No, please. This script is distro-agnostic, we don't need to carry all the dependencies issues. Actually, these installation instructions are already documented... http://git.openstack.org/cgit/openstack/nova/tree/doc/source/devref/development.environment.rst -Sylvain Thanks, Eduard On Tue, Nov 18, 2014 at 10:27 AM, Vineet Menon mvineetme...@gmail.com mailto:mvineetme...@gmail.com wrote: Hi, You should install mysql-dev for your distro using apt-get or yum. Regards, Vineet Menon On 18 November 2014 09:16, Eduard Matei eduard.ma...@cloudfounders.com mailto:eduard.ma...@cloudfounders.com wrote: Hi, I'm trying to run nova's unittests to validate some changes we made for a LibvirtVolumeDriver class, but i only got errors: with virtual env: ... Downloading/unpacking MySQL-python (from -r /opt/stack/nova/test-requirements.txt (line 13)) Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded Running setup.py (path:/opt/stack/nova/.venv/build/MySQL-python/setup.py) egg_info for package MySQL-python sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Complete output from command python setup.py egg_info: sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Cleaning up... Command python setup.py egg_info failed with error code 1 in /opt/stack/nova/.venv/build/MySQL-python Storing debug log for failure in /root/.pip/pip.log Command tools/with_venv.sh pip install --upgrade -r /opt/stack/nova/requirements.txt -r /opt/stack/nova/test-requirements.txt failed. None without virtual env: :/opt/stack/nova# ./run_tests.sh -N Running ` python -m nova.openstack.common.lockutils python setup.py testr --testr-args='--subunit --concurrency 0 '` Non-zero exit code (2) from test listing. error: testr failed (3) Ran 0 tests in 4.792s OK Running flake8 ... **WARNING**: Running flake8 without virtual env may miss OpenStack HACKING detection bash: flake8: command not found nova-manage --version 2014.2.1 Any idea how to fix this? Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com http://www.cloudfounders.com/ | eduard.ma...@cloudfounders.com mailto:eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost,
Re: [openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0
Hi Daniele, Sorry for long response, I have a bit busy. As for your problem, the log is looks like that we're talking about the same problem, but at different stages of its manifestation. Anyway, the original ticket is closed, so please pull the latest fuel-main fixes and try again. If you meet some problems - let us know. - Igor On Fri, Nov 14, 2014 at 2:38 PM, Daniele Pizzolli daniele.pizzo...@create-net.org wrote: Igor Kalnitsky ikalnit...@mirantis.com writes: Mat, I've filed a bug [1] and provide you a puppet output inside Nailgun container [2]. If I remove /etc/yum.repos.d/5.1.1_nailgun - the puppet works fine. [1]:https://bugs.launchpad.net/fuel/+bug/1392698 [2]: http://xsnippet.org/360279/raw/ Hello, I guess I asked for a related problem during make iso on #fuel-dev few days ago. The logs seems similar to me: http://paste.openstack.org/show/131837/ Maybe you want to add also this reference to the bug. Best, Daniele ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova]Can't run tests
Aha, didn't catch that. I just wanted to run the tests, didn't look at setting up a development environment. Thanks, Eduard On Tue, Nov 18, 2014 at 12:24 PM, Sylvain Bauza sba...@redhat.com wrote: Le 18/11/2014 10:11, Eduard Matei a écrit : Thanks Vineet. Indeed missing packages was the problem, for completeness here are the packages i needed in order to get virtual env running on Ubuntu 14.04.1 LTS - libmysqlclient-dev - pkg-config - libvirt-dev Maybe they can be included in the script that sets up the virtual env. No, please. This script is distro-agnostic, we don't need to carry all the dependencies issues. Actually, these installation instructions are already documented... http://git.openstack.org/cgit/openstack/nova/tree/doc/source/devref/development.environment.rst -Sylvain Thanks, Eduard On Tue, Nov 18, 2014 at 10:27 AM, Vineet Menon mvineetme...@gmail.com wrote: Hi, You should install mysql-dev for your distro using apt-get or yum. Regards, Vineet Menon On 18 November 2014 09:16, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, I'm trying to run nova's unittests to validate some changes we made for a LibvirtVolumeDriver class, but i only got errors: with virtual env: ... Downloading/unpacking MySQL-python (from -r /opt/stack/nova/test-requirements.txt (line 13)) Downloading MySQL-python-1.2.5.zip (108kB): 108kB downloaded Running setup.py (path:/opt/stack/nova/.venv/build/MySQL-python/setup.py) egg_info for package MySQL-python sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Complete output from command python setup.py egg_info: sh: 1: mysql_config: not found Traceback (most recent call last): File string, line 17, in module File /opt/stack/nova/.venv/build/MySQL-python/setup.py, line 17, in module metadata, options = get_config() File setup_posix.py, line 43, in get_config libs = mysql_config(libs_r) File setup_posix.py, line 25, in mysql_config raise EnvironmentError(%s not found % (mysql_config.path,)) EnvironmentError: mysql_config not found Cleaning up... Command python setup.py egg_info failed with error code 1 in /opt/stack/nova/.venv/build/MySQL-python Storing debug log for failure in /root/.pip/pip.log Command tools/with_venv.sh pip install --upgrade -r /opt/stack/nova/requirements.txt -r /opt/stack/nova/test-requirements.txt failed. None without virtual env: :/opt/stack/nova# ./run_tests.sh -N Running ` python -m nova.openstack.common.lockutils python setup.py testr --testr-args='--subunit --concurrency 0 '` Non-zero exit code (2) from test listing. error: testr failed (3) Ran 0 tests in 4.792s OK Running flake8 ... **WARNING**: Running flake8 without virtual env may miss OpenStack HACKING detection bash: flake8: command not found nova-manage --version 2014.2.1 Any idea how to fix this? Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com eduard.matei@cloudfounder!+s.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Process for program without lead
Kevin L. Mitchell wrote: On Mon, 2014-11-17 at 17:25 +, Hayes, Graham wrote: Quite often people will come forward in a vacuum - people who thought they were not right for the job, or felt that someone else would suit the role better can come forward in a by-election. (I only have anecdotal evidence for this, but it is first hand, based on other voluntary, self organising groups I have been part of, and run elections for over the years). I would suggest when nominations close with no candidates, they re-open immediately for one week, at with point, if there is no candidates I goes to the TC. While I think the point is valid, an alternate process would be for the election coordinator(s) to point out the lack of candidates and issue a reminder for the procedure a certain amount of time prior to the end of the nomination period. Say, if no candidates have been put forward with 3 days left in the nomination period, then the election coordinator would send out the appropriate reminder email. I think this would have the same effect as the one week re-open period without delaying the election process. Also delaying the elections for one week puts additional stress on the design summit organization (the newly-elected PTL is responsible for organizing his program sessions there). Any solution that doesn't delay significantly the determination of the PTL should therefore be preferred. Note that if nobody showed up at the end of the nomination period, *anyone* placing their self-nomination email in the last minute would get automatically elected without an election having to happen. So I don't think it's completely crazy to let the TC take over the orphaned project and seek/encourage someone to fill the PTL shoes if nobody placed their nomination in the time allocated for it. -- 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] [Horizon] the future of angularjs development in Horizon
On 18 November 2014 19:22, Radomir Dopieralski openst...@sheep.art.pl wrote: On 18/11/14 00:59, Richard Jones wrote: On 17 November 2014 21:54, Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: - Bower in the development environment, - Bower configuration file in two copies, one for global-requirements, and one for the Horizon's local requirements. Plus a gate job that makes sure no new library or version gets included in the Horizon's before getting into the global-requirements, Could you perhaps elaborate on this? How do you see the workflow working here? Basically we would have an additional file in the global-requirements directory, for listing the JavaScript dependencies. Then we would have a check on the Horizon's gate that would check Horizon's Bower configuration against that global-requirements file. This way we keep the same process for JavaScript libraries as we have for Python libraries: first you submit a patch to the global-requirements and have the dependency accepted by the infra team and packagers (checked against licenses, version conflicts, etc.), and then you add it to Horizon's dependencies. Of course you can submit both patches at once, just the Horizon one will fail the gate until the global-requirements one gets merged. Given that Horizon already integrates with xstatic, it would be messy (and potentially confusing) to include something so it *also* integrated with bower. I was envisaging us creating a tool which generates xstatic packages from bower packages. I'm not the first to think along these lines http://lists.openstack.org/pipermail/openstack-dev/2014-March/031042.html If we use Bower, we don't need to use Xstatic. It would be pure overhead. Bower already takes care of tracking releases and versions, and of bundling the files. All we need is a simple line in the settings.py telling Django where it puts all the files -- we don't really need Xstatic just for that. The packagers can then take those Bower packages and turn them into system packages, and just add/change the paths in settings.py to where they put the files. All in one place. I guess I got the message that turning bower packages into system packages was something that the Linux packagers were not keen on. Did I get the message wrong there? If so, *and* we can get the bower stuff through #infra and global-requirements then yes, we should totally try to avoid adding the xstatic layer :) Richard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute
Dolph Mathews wrote: As someone who has spent quite a bit of time triaging bugs, I'd be hugely in favor of this. I'd probably be willing to pitch in on additional projects, as well. Is there already tooling for this built around Launchpad, or do we have to roll our own? You'll have to roll your own, but it shouldn't be very difficult. You can see [1] for a base example of listing bugs in Launchpad: [1] http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py With storyboard.openstack.org http://storyboard.openstack.org looming on the horizon, should such an effort be put on the back burner for now? I don't expect integrated projects to be able to switch to storyboard for bug tracking just yet. Our current goal is to have it ready for infrastructure dogfooding now (actually, yesterday), ready for feature tracking (and bugs tracking replacement for willing non-integrated guinea pigs) in 6 months, and ready for everyone in 12 months. -- 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] [all] fix latency on requirements breakage
Christopher Yeoh wrote: On Tue, Nov 18, 2014 at 9:32 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: waiting extra long for valid test results. People don't realize their code can't pass and just keep pushing patches up consuming resources which means that parts of the project that could pass tests, is backed up behind 100% guarunteed failing parts. All in all, not a great system. Maybe a MOTD at the top of http://review.openstack.org could help here? Have a button that the QA/infra people can hit when everything is broken that puts up a message there asking people to stop rechecking/submitting patches. We can already ask statusbot (http://ci.openstack.org/irc.html#statusbot) to show up messages on status.openstack.org and log them to https://wiki.openstack.org/wiki/Infrastructure_Status It's just not used as much as it used to for CI breakage those days. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] Contributing to Solum
Hi, I am not even sure that I'm posting this in the right place, but the official Solum website was rather sparse on info regarding where to start. As a compact intro, my name is Keyvan, I've been an active OSS developer/admin https://github.com/keyvan-m-sadeghi since 2011, mainly working on the OpenCog project https://github.com/opencog/opencog. I am planning to create a cloud platform, in the long-term. We are a team of 4 ppl, right now we're most interested in Solum, as it'd make a strong ground for our ideas. We all have strong Python skills and the team is willing to set aside around 10 hrs / week for Solum development, initially. I've read the wiki and there doesn't seem to be an 'Ideas' page where I could see a list of projects to be done, best thing I've found so far was the bugs page https://bugs.launchpad.net/solum, but I'm not sure on where to start. We really appreciate if someone could define a small-sized project for us to undertake; that serves both for the purpose of getting to know Solum code more in depth and also set a start for our contribution. Regards, Keyvan -- Keyvan Mir Mohammad Sadeghi MSc AI One has to pay dearly for immortality; one has to die several times while one is still alive. -- Friedrich Nietzsche ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
Sean Dague wrote: As we're dealing with the fact that testtools 1.4.0 apparently broke something with attribute additions to tests (needed by tempest for filtering), it raises an interesting problem. Our current policy on requirements is to leave them open ended, this lets us take upstream fixes. It also breaks us a lot. But our max version of dependencies happens with 0 code review or testing. However, fixing these things takes a bunch of debug, code review, and test time. Seen by the fact that the testtools 1.2.0 block didn't even manage to fully merge this weekend. This is an asymetric break/fix path, which I think we need a better plan for. If fixing is more expensive than breaking, then you'll tend to be in a broken state quite a bit. We really actually want the other asymetry if we can get it. +1 There are a couple of things we could try here: == Cap all requirements, require code reviews to bump maximums == Benefits, protected from upstream breaks. Down sides, requires active energy to move forward. The SQLA 0.8 transition took forever. I think all projects which do manual dep bumps just end up not keeping up with the state of the world over time. It's just too much pain to bump them, introduce risk for so little gain for the party involved (you just created an externality). You would only bump stuff when you need a new feature/fix from a new version of the library, which would (1) make those bumps more costly for the poor soul that will end up needing the new version and (2) go stale on everything else, not getting free bugfixes from library authors and generally making the distributions lives more miserable. This is totally doable (and desirable imho) on stable branches though, and we plan to just do that there. == Provide Requirements core push authority == For blocks on bad versions, if we had a fast path to just merge know breaks, we could right ourselves quicker. It would have reasonably strict rules, like could only be used to block individual versions. Probably that should also come with sending email to the dev list any time such a thing happened. Benefits, fast to fix Down sides, bypasses our testing infrastructure. Though realistically the break bypassed it as well. That doesn't sound completely crazy. Currently we give the upstream projects the ability to directly break us, without giving our own requirements-core the ability to directly fix the breakage. -- 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] [all] Scale out bug-triage by making it easier for people to contribute
On Tue, Nov 18, 2014 at 11:42:19AM +0100, Thierry Carrez wrote: Dolph Mathews wrote: As someone who has spent quite a bit of time triaging bugs, I'd be hugely in favor of this. I'd probably be willing to pitch in on additional projects, as well. Is there already tooling for this built around Launchpad, or do we have to roll our own? FWIW, I find the CLI querying in Launchpad a bit lacking compared to Bugzilla. A while ago, Thierry pointed me to 'lp-tools'[1] which has a bunch of CLI scripts to interface with Launchpad I use it sometimes to check new Nova bugs: $ python new-nova-lp-bugs.py | tee new-nova-lp-bugs-18NOV2014.txt Couple of other resources I try to use[2][3] when I triage bugs: [1] https://launchpad.net/lptools [2] Notes from Sean Dague from Nova bug triaging -- http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html [3] https://wiki.openstack.org/wiki/BugFilingRecommendations You'll have to roll your own, but it shouldn't be very difficult. You can see [1] for a base example of listing bugs in Launchpad: [1] http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py With storyboard.openstack.org http://storyboard.openstack.org looming on the horizon, should such an effort be put on the back burner for now? I don't expect integrated projects to be able to switch to storyboard for bug tracking just yet. Our current goal is to have it ready for infrastructure dogfooding now (actually, yesterday), ready for feature tracking (and bugs tracking replacement for willing non-integrated guinea pigs) in 6 months, and ready for everyone in 12 months. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] discussion of an implementation detail for boot from network feature
Hi Daniel, referring to this discussion we had some weeks ago, there is a blueprint and spec up for review now, describing the boot device prioritization feature you proposed: https://blueprints.launchpad.net/nova/+spec/boot-order-for-instance https://review.openstack.org/#/c/133254/ It would be great if you could have a look and add your comments. Regards, Ondrej On 10/02/2014 11:56 AM, Daniel P. Berrange wrote: When booting from the network there is potentially a choice of multiple NICs from which todo PXE. With KVM you are not restricted to saying disk or network as exclusive choices, but rather you can setup arbitrary prioritization of boot order across devices, whether disk, nic or PCI assigned device. So we should really consider this broader problem of boot device prioritization not merely a PXE flag. IOW, we should extend the Nova boot command so that the --block-device-mapping and --nic args both allow for an integer boot priority value to be specified per device. bootindex=NNN And likewise allow it to be set for PCI assigned devices. Hypervisors that don't support such fine grained ordering, can simply ignore anything except the device with bootindex=1. Regards, Daniel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
On Mon, Nov 17, 2014 at 09:32:21PM -0600, Matt Riedemann wrote: I think this idea has come up before, the problem is knowing how to distinguish the sky is falling type bugs from other race bugs we know about. Thinking out loud it could be severity of the bug in launchpad but we have a lot of high/critical race bugs that have been around for a long time and they are obviously not breaking the world. We could tag bugs (I'm assuming I could get bug tags from the launchpad API) but we'd have to be pretty strict about not abusing the tag just to get attention on a bug. Other ideas? I think just having something like a 'blocks-gate' tag would be fine. I'm not sure it could be badly abused. I'm envisioning elastic recheck giving a message along the lines of: This failure has been tagged as a gate blocking bug, please avoid rechecking until it has been addressed. This should inform people that they shouldn't blindly recheck that patchset and it has limited scope for abuse. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do we have a meeting this week?
On 11/18/2014 04:23 AM, Michael Still wrote: Dear Americans... you're not really going to come to a meeting this week are you? There's that thanks giving thing, right? So... Should we cancel for this week? Michael Our feast of Turkey is actually next week (27th). -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
On 11/18/2014 06:21 AM, Louis Taylor wrote: On Mon, Nov 17, 2014 at 09:32:21PM -0600, Matt Riedemann wrote: I think this idea has come up before, the problem is knowing how to distinguish the sky is falling type bugs from other race bugs we know about. Thinking out loud it could be severity of the bug in launchpad but we have a lot of high/critical race bugs that have been around for a long time and they are obviously not breaking the world. We could tag bugs (I'm assuming I could get bug tags from the launchpad API) but we'd have to be pretty strict about not abusing the tag just to get attention on a bug. Other ideas? I think just having something like a 'blocks-gate' tag would be fine. I'm not sure it could be badly abused. I'm envisioning elastic recheck giving a message along the lines of: This failure has been tagged as a gate blocking bug, please avoid rechecking until it has been addressed. This should inform people that they shouldn't blindly recheck that patchset and it has limited scope for abuse. Realistically it's also saying that folks fixing things have *another* thing to keep up on. Both the people fixing the bug, and the 1000 people contributing to OpenStack. So it's more work for everyone, and it doesn't actually make the fixes come any faster. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote: I guess I got the message that turning bower packages into system packages was something that the Linux packagers were not keen on. Did I get the message wrong there? If so, *and* we can get the bower stuff through #infra and global-requirements then yes, we should totally try to avoid adding the xstatic layer :) For me, it's more work to turn packages into bower, or to translate bower packages to system packages. But that is purely because we don't have bower packaged currently in Fedora. I would vote for the cleaner way (whatever that is). XStatic is obviously not the cleanest way, but a good compromise in most situations. Matthias -- Matthias Runge mru...@redhat.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] policy on old / virtually abandoned patches
Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] policy on old / virtually abandoned patches
2014-11-18 21:06 GMT+09:00 Sean Dague s...@dague.net: Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. thanks Sean, +1 for doing this. Thanks Ken Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] policy on old / virtually abandoned patches
On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. Yep, purging anything that's older than 4 weeks with negative karma seems like a good idea. It'll make it easier for us to identify those patches which are still maintained and target them for review. That said, there's some edge cases - for example I've got some patches up for review that have a -2 on them, becase we're waiting for blueprint approval. IIRC, previously we would post a warning about pending auto- abandon a week before, and thus give the author the chance to add a comment to prevent auto-abandon taking place. It would be neccessary to have this ability to deal with the case where we're just temporarily blocked on other work. Also sometimes when you have a large patch series, you might have some patches later in the series which (temporarily) fail the jenkins jobs. It often isn't worth fixing those failures until you have dealt with review earlier in the patch series. So I think we should not auto-expire patches which are in the middle of a patch series, unless the preceeding patches in the series are to be expired too. Yes this isn't something you can figure out with a single gerrit query - you'd have to query gerrit for patches and then look at the parent change references. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] policy on old / virtually abandoned patches
On 11/18/2014 07:29 AM, Daniel P. Berrange wrote: On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. Yep, purging anything that's older than 4 weeks with negative karma seems like a good idea. It'll make it easier for us to identify those patches which are still maintained and target them for review. That said, there's some edge cases - for example I've got some patches up for review that have a -2 on them, becase we're waiting for blueprint approval. IIRC, previously we would post a warning about pending auto- abandon a week before, and thus give the author the chance to add a comment to prevent auto-abandon taking place. It would be neccessary to have this ability to deal with the case where we're just temporarily blocked on other work. Also sometimes when you have a large patch series, you might have some patches later in the series which (temporarily) fail the jenkins jobs. It often isn't worth fixing those failures until you have dealt with review earlier in the patch series. So I think we should not auto-expire patches which are in the middle of a patch series, unless the preceeding patches in the series are to be expired too. Yes this isn't something you can figure out with a single gerrit query - you'd have to query gerrit for patches and then look at the parent change references. Or just abandon and let people restore. I think handling the logic / policy for the edge cases isn't worth it when the author can very easily hit the restore button to get their patch back (and fresh for another 4w). If it was a large patch series, this wouldn't happen anyway, because every rebase would make it fresh. 4w is really 4w of nothing changing. -Sean -- Sean Dague http://dague.net signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.db 1.1.0 released
Matt, This is really weird. Victor and I will take a closer look. Thanks, Roman On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/oslo.db ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev And...the nova postgresql opportunistic DB tests are failing quite frequently due to some race introduced by the new library version [1]. [1] https://bugs.launchpad.net/oslo.db/+bug/1393633 -- Thanks, Matt Riedemann ___ 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] [all] Scale out bug-triage by making it easier for people to contribute
On 18/11/14 11:42 +0100, Thierry Carrez wrote: Dolph Mathews wrote: As someone who has spent quite a bit of time triaging bugs, I'd be hugely in favor of this. I'd probably be willing to pitch in on additional projects, as well. Is there already tooling for this built around Launchpad, or do we have to roll our own? You'll have to roll your own, but it shouldn't be very difficult. You can see [1] for a base example of listing bugs in Launchpad: [1] http://git.openstack.org/cgit/openstack-infra/release-tools/tree/process_bugs.py If Infra agrees that we can have a bot that runs a script weekly, I'm happy to help with the script itself. With storyboard.openstack.org http://storyboard.openstack.org looming on the horizon, should such an effort be put on the back burner for now? I don't expect integrated projects to be able to switch to storyboard for bug tracking just yet. Our current goal is to have it ready for infrastructure dogfooding now (actually, yesterday), ready for feature tracking (and bugs tracking replacement for willing non-integrated guinea pigs) in 6 months, and ready for everyone in 12 months. Is it in a good enough state that would a low smaller projects - zaqar - to jump in and help testing the storyboard? I'm happy to give it a try. Cheers, Flavio -- @flaper87 Flavio Percoco pgpIegOxUfxSz.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] policy on old / virtually abandoned patches
On 11/18/2014 07:29 AM, Daniel P. Berrange wrote: On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. Yep, purging anything that's older than 4 weeks with negative karma seems like a good idea. It'll make it easier for us to identify those patches which are still maintained and target them for review. That said, there's some edge cases - for example I've got some patches up for review that have a -2 on them, becase we're waiting for blueprint approval. IIRC, previously we would post a warning about pending auto- abandon a week before, and thus give the author the chance to add a comment to prevent auto-abandon taking place. It would be neccessary to have this ability to deal with the case where we're just temporarily blocked on other work. Yes, this is indeed an issue. However, couldn't we just say Add a -Workflow label to avoid auto-abandon and then have the script simply ignore patches with -Workflow? As you note below, it's not a simple thing to determine all of the patches in a series that may happen to have a -Workflow at the tail of the patch series, but it's probably doable with a little script-fu. Best, -jay Also sometimes when you have a large patch series, you might have some patches later in the series which (temporarily) fail the jenkins jobs. It often isn't worth fixing those failures until you have dealt with review earlier in the patch series. So I think we should not auto-expire patches which are in the middle of a patch series, unless the preceeding patches in the series are to be expired too. Yes this isn't something you can figure out with a single gerrit query - you'd have to query gerrit for patches and then look at the parent change references. Regards, Daniel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Failed upgrade chain - 5.1 - 5.1.1 - 6.0
Igor Kalnitsky ikalnit...@mirantis.com writes: Hi Daniele, Sorry for long response, I have a bit busy. As for your problem, the log is looks like that we're talking about the same problem, but at different stages of its manifestation. Anyway, the original ticket is closed, so please pull the latest fuel-main fixes and try again. If you meet some problems - let us know. Hello Igor, thanks. I tried with the latest stable/5.1 and still get the error. I filed the bug here: https://bugs.launchpad.net/fuel/+bug/1393777 I also make made a try by cherry picking the commits mentioned in https://bugs.launchpad.net/fuel/+bug/1392698 with no success. The build from the master works. Thanks, Daniele ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging] ZeroMQ driver maintenance next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/11/14 00:55, Denis Makogon wrote: So if zmq driver support in devstack is fixed, we can easily add a new job to run them in the same way. Btw this is a good question. I will take look at current state of zmq in devstack. I don't think its that far off and its broken rather than missing - the rpc backend code needs updating to use oslo.messaging rather than project specific copies of the rpc common codebase (pre oslo). Devstack should be able to run with the local matchmaker in most scenarios but it looks like there was support for the redis matchmaker as well. If you could take some time to fixup that would be awesome! - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIbBAEBCAAGBQJUa03HAAoJEL/srsug59jDdZQP+IeEvXAcfxNs2Tgvt5trnjgg cnTrJPLbr6i/uIXKjRvNDSkJEdv//EjL/IRVRIf0ld09FpRnyKzUDMPq1CzFJqdo 45RqFWwJ46NVA4ApLZVugJvKc4tlouZQvizqCBzDKA6yUsUoGmRpYFAQ3rN6Gs9h Q/8XSAmHQF1nyTarxvylZgnqhqWX0p8n1+fckQeq2y7s3D3WxfM71ftiLrmQCWir aPkH7/0qvW+XiOtBXVTXDb/7pocNZg+jtBkUcokORXbJCmiCN36DBXv9LPIYgfhe /cC/wQFH4RUSkoj7SYPAafX4J2lTMjAd+GwdV6ppKy4DbPZdNty8c9cbG29KUK40 TSCz8U3tUcaFGDQdBB5Kg85c1aYri6dmLxJlk7d8pOXLTb0bfnzdl+b6UsLkhXqB P4Uc+IaV9vxoqmYZAzuqyWm9QriYlcYeaIJ9Ma5fN+CqxnIaCS7UbSxHj0yzTaUb 4XgmcQBwHe22ouwBmk2RGzLc1Rv8EzMLbbrGhtTu459WnAZCrXOTPOCn54PoIgZD bK/Om+nmTxepWD1lExHIYk3BXyZObxPO00UJHdxvSAIh45ROlh8jW8hQA9lJ9QVu Cz775xVlh4DRYgenN34c2afOrhhdq4V1OmjYUBf5M4gS6iKa20LsMjp7NqT0jzzB tRDFb67u28jxnIXR16g= =+k0M -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 11/17/2014 03:22 PM, Matthias Runge wrote: On 17/11/14 02:07, Richard Jones wrote: Except that selenium is non-free: it's in the non-free repository of Debian, because it contains a pre-built .xpi plugin for firefox, which itself contains pre-built .so and .dll files. Hasn't this issue already been addressed? Horizon currently uses Selenium-based integration tests. For Fedora, we found, that simply removing bundled .dll and .xpi files still leaves selenium intact. And then, does selenium continues to work for testing Horizon? If so, then the solution could be to send the .dll and .xpi files in non-free, and remove them from Selenium in main. Cheers, Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] New Policy Administration Service
Hi all, In Paris, on the last day, we listed the new features that we would like to see in the next release of Keystone. The top 3 were chosen as high priority. Further down the list was a policy administration service that will collect policies from all the Openstack services and allow the Keystone administrator to ask the question what role do I need to assign to a user to give access to these services? and will allow users to ask the question what can I access with my roles?. We have now started to design and build this service. An important design decision is should this service be integrated with Keystone or be a separated standalone Openstack service? What does the Keystone group think? If policy administration should be a separate service, what is the process to register blueprints, apis and code reviews? Regards, Ioram and David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
On 18/11/14 18:51, Thierry Carrez wrote: Christopher Yeoh wrote: On Tue, Nov 18, 2014 at 9:32 AM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: waiting extra long for valid test results. People don't realize their code can't pass and just keep pushing patches up consuming resources which means that parts of the project that could pass tests, is backed up behind 100% guarunteed failing parts. All in all, not a great system. Maybe a MOTD at the top of http://review.openstack.org could help here? Have a button that the QA/infra people can hit when everything is broken that puts up a message there asking people to stop rechecking/submitting patches. We can already ask statusbot (http://ci.openstack.org/irc.html#statusbot) to show up messages on status.openstack.org and log them to https://wiki.openstack.org/wiki/Infrastructure_Status It's just not used as much as it used to for CI breakage those days. I have to say, extending statusbot to do MOTD on http://review.openstack.org sounds like a great idea to me. It also sounds like one of those changes to gerrit that might actually be in the 'achievable' bucket :D Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Ilya On 18/11/14 02:45, Ilya Pekelny wrote: Thank you, Eric, for your descriptions! I'm very new to rpc and oslo.messaging. So I can be wrong in the idea of how it all designed and I can be wrong in a particular formulations. But I'm highly motivated in improvement of the rpc/oslo.messaging knowledge. I'm going to clarify all your descriptions and come back with updated propositions. Thank you, Russell, for your proposition! I'll pay attention to AMQP 1.0 as soon as possible. I'm not sure I can take it all to work but for sure I'll have an understanding about AMQP 1.0 in a nearest future. As Eric detailed, the zmq driver does not implement a centralized broker design. I put together this diagram: https://docs.google.com/drawings/d/1A3PyBbZArzxRa2s4gGMIu1VYhsmc1FXWYbniSkA5_TU/edit?usp=sharing when my team reviewed the existing design with Pieter Hintjens (ZeroMQ upstream) in September to articulate how the driver functions with the zmq-reciever and openstack processes. I have an action item to document that within the oslo.messaging codebase so its a bit more accessible and with the actual code. I think that the design is sound but there are a number of optimizations and features that we did discuss as improvements: 1) Outbound messaging connection re-use - right now every outbound messaging creates and consumes a tcp connection - this approach scales badly when neutron does large fanout casts. 2) PUSH/PULL tcp sockets - Pieter suggested we look at ROUTER/DEALER as an option once 1) is resolved - this socket type pairing has some interesting features which would help with resilience and availability including heartbeating. 3) Security options including encryption; this would require some distribution work in Ubuntu right now as zeromq is not built with this feature enabled. I think for this cycle we really do need to focus on consolidating and testing the existing driver design and fixing up the biggest deficiency (1) before we consider moving forward with lots of new features. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUa1GuAAoJEL/srsug59jDrOcP/isK148CV+wHwoue12f/oFQb Ri7SjP8NfPhkX9izRbLC1PyrMZvFcnf5qTJaC9PZJbREmD5IYawDBP5Vs68aHFO+ s2t/FtuVrrdxqWuFF181XPfdB6pf6dRCjRp3NCIQL+x1wIJ0n828T1fhhAg419ki 17ccBhpoVpFPnqyaTbLsvYzumuLXXTSJWn523gQ6mOsYyRUONbP4LudFmzj/AVCd XzzS/Aq3YM0HeBqTMgiLlqzDqFptim/P+LZctOeUzkq+VNBAwLV8yBUQ5xQmDhrC 38LDLaMOzmXiQPvizUx9duV/TKxaBJf1Uqf+IlZStm2GSwnRbw3YK00L0tPR5t1n IJjsgZz6KZDpWhZ6u5GwL9tNKtMiaAnVcSQ6DJmxLOao5VMEPhY/442hmrSU1MHl MsE8FyN8uTQM9Byo+Wfg1+A52+3Gr2pH489XhhA8ROqCMIA3bRizEMcI14kb+GbA wA+q7hFvFrwaUC18YeCN2tDibMmq6PeT9cUSMNB45MhSd130kCMUy6DrhagW5mU/ UXr/25cMvbVqF+0UjssPzom1fJ8KYK7tgbNqc+sExMqZFbJMG1yMCm7Zp7ei+xMc tEs5O58BsMEu2tx7y3UjEJwFuQPUc0FkYKGXyx6ZT9iyfMrFSdY2CSp3Cl5gXc2Z g4FCigKTr7IXew6bdzxi =MUSc -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Summit Recap: Notification Schema
https://etherpad.openstack.org/p/kilo-crossproject-notifications The big takeaways: 1. We want the schema to be external so other languages can utilize them. 2. JSON-Schema seems fine, but AVRO has traction in the Big Data world and should be considered. 3. The challenge of have text-file based schema's is how to make them available for CI and deployments. Packaging problems. There is no simple pip install for text files. Talked about the possibility of making them available by the service API itself or exposing their location via a Service Catalog entry. 4. There are a lot of other services that need a solution to this problem. Monasca needs to define a message bus schema. Nova Objects has its own for RPC calls. It would be nice to solve this problem once. 5. The CADF group is very open to making changes to the spec to accommodate our needs. Regardless, we need a way to transform existing notifications to whatever the new format is. So, we not only need schema definition grammar, but we will need a transformation grammar out of the gate for backwards compatibility. 6. Like Nova Objects, it would be nice to make a single smart schema object that can read a schema file and become that object with proper setters and getters (and validation, version up-conversion/down-conversion, etc) 7. If we can nail down the schema grammar, the transformation grammar and perhaps the schema object in Kilo we can start to promote it for adoption in L-release. 8. People should be freed up to work on this around Kilo-2 (new year) Lots of other details in the etherpad. It would be good to arrange a meeting soon to discuss the schema grammar again. And how to distribute the schemas in test and prod env's. Perhaps come up with some concrete recommendations. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] policy on old / virtually abandoned patches
On Tue, Nov 18, 2014 at 07:33:54AM -0500, Sean Dague wrote: On 11/18/2014 07:29 AM, Daniel P. Berrange wrote: On Tue, Nov 18, 2014 at 07:06:59AM -0500, Sean Dague wrote: Nova currently has 197 patches that have seen no activity in the last 4 weeks (project:openstack/nova age:4weeks status:open). Of these * 108 are currently Jenkins -1 (project:openstack/nova age:4weeks status:open label:Verified=-1,jenkins) * 60 are -2 by a core team member (project:openstack/nova age:4weeks status:open label:Code-Review=-2) (note, those 2 groups sometimes overlap) Regardless, the fact that Nova currently has 792 open reviews, and 1/4 of them seem dead, seems like a cleanup thing we could do. I'd like to propose that we implement our own auto abandon mechanism based on reviews that are either held by a -2, or Jenkins -1 after 4 weeks time. I can write a quick script to abandon with a friendly message about why we are doing it, and to restore it if work is continuing. Yep, purging anything that's older than 4 weeks with negative karma seems like a good idea. It'll make it easier for us to identify those patches which are still maintained and target them for review. That said, there's some edge cases - for example I've got some patches up for review that have a -2 on them, becase we're waiting for blueprint approval. IIRC, previously we would post a warning about pending auto- abandon a week before, and thus give the author the chance to add a comment to prevent auto-abandon taking place. It would be neccessary to have this ability to deal with the case where we're just temporarily blocked on other work. Also sometimes when you have a large patch series, you might have some patches later in the series which (temporarily) fail the jenkins jobs. It often isn't worth fixing those failures until you have dealt with review earlier in the patch series. So I think we should not auto-expire patches which are in the middle of a patch series, unless the preceeding patches in the series are to be expired too. Yes this isn't something you can figure out with a single gerrit query - you'd have to query gerrit for patches and then look at the parent change references. Or just abandon and let people restore. I think handling the logic / policy for the edge cases isn't worth it when the author can very easily hit the restore button to get their patch back (and fresh for another 4w). If it was a large patch series, this wouldn't happen anyway, because every rebase would make it fresh. 4w is really 4w of nothing changing. Ok, that makes sense and is workable I reckon. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa][tempest][rally] Seems like Tempest breaks Rally gates
Hi stackers, As far as you maybe know Rally has rally verify command that simplifies usage of tempest. We are testing this functionality in our gates on every patch (for about month). Everything was fine until today when it started failing. We are running 2 different tempest sets (image and smoke). And smoke one started failing. I thought that something is wrong with Rally Tempst integration, and tried to run on fresh DevStack node just smoke tests from tempest via next command: ./run_tempest.sh -s I got next result: Ran 0 tests in 4.499s OK stack@akurilin-virt-0:~/tempest$ git log -1 commit 9556987fbfc906f386939b3903253aa8ff17d91d Merge: aee83e2 cd4a51e Author: Jenkins jenk...@review.openstack.org Date: Tue Nov 18 12:42:41 2014 + Merge Add internal methods for setting compute clients Any thoughts? Best regards, Boris Pavlovic ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stale patches
On 2014-11-18 05:55:55 + (+), Kenichi Oomichi wrote: I am not concentrating on Neutron devs, but I also have the same feeling on the other area devs. I also cannot abandon the other developers' patches even if non-activities against some negative feedback. This has come up before... if you don't want to see stale patches you can use Gerrit queries or custom dashboards to only show you patches with recent activity. If all patches older than some specific date get abandoned, then that impacts the view of these patches for every reviewer. Selectively abandoning patches because they're no longer relevant makes sense, but just automatically abandoning them because _some_ reviewers don't want to see old changes is a disservice to other reviewers who don't have the same personal preference. I'd rather our infrastructure empowered reviewers to look at the changes they *want* to see, not tell them which changes they're *supposed* to review. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][tempest][rally] Seems like Tempest breaks Rally gates
On Tue, Nov 18, 2014 at 06:29:55PM +0400, Boris Pavlovic wrote: Hi stackers, As far as you maybe know Rally has rally verify command that simplifies usage of tempest. We are testing this functionality in our gates on every patch (for about month). Everything was fine until today when it started failing. We are running 2 different tempest sets (image and smoke). And smoke one started failing. I thought that something is wrong with Rally Tempst integration, and tried to run on fresh DevStack node just smoke tests from tempest via next command: ./run_tempest.sh -s I got next result: Ran 0 tests in 4.499s OK stack@akurilin-virt-0:~/tempest$ git log -1 commit 9556987fbfc906f386939b3903253aa8ff17d91d Merge: aee83e2 cd4a51e Author: Jenkins jenk...@review.openstack.org Date: Tue Nov 18 12:42:41 2014 + Merge Add internal methods for setting compute clients Any thoughts? This is actually an issue that the entire gate was hitting yesterday, not just Rally. With the release of testtools 1.4.0, attrs in tempest broke, (which is probably a unittest2 bug being exposed) this caused the regex filters on attributes to stop working which broke a bunch of jobs. In the short term we've landed global requirements changes to exclude that testtools version, you probably just need to do the same on Rally to avoid the version which doesn't work. There is also tempest-side fix in progress here: https://review.openstack.org/#/c/135115/ But, that will take a bit longer to land. -Matt Treinish pgpfXXn8YKJUs.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][tempest][rally] Seems like Tempest breaks Rally gates
Matthew, Thanks for quick reply! Best regards, Boris Pavlovic On Tue, Nov 18, 2014 at 6:46 PM, Matthew Treinish mtrein...@kortar.org wrote: On Tue, Nov 18, 2014 at 06:29:55PM +0400, Boris Pavlovic wrote: Hi stackers, As far as you maybe know Rally has rally verify command that simplifies usage of tempest. We are testing this functionality in our gates on every patch (for about month). Everything was fine until today when it started failing. We are running 2 different tempest sets (image and smoke). And smoke one started failing. I thought that something is wrong with Rally Tempst integration, and tried to run on fresh DevStack node just smoke tests from tempest via next command: ./run_tempest.sh -s I got next result: Ran 0 tests in 4.499s OK stack@akurilin-virt-0:~/tempest$ git log -1 commit 9556987fbfc906f386939b3903253aa8ff17d91d Merge: aee83e2 cd4a51e Author: Jenkins jenk...@review.openstack.org Date: Tue Nov 18 12:42:41 2014 + Merge Add internal methods for setting compute clients Any thoughts? This is actually an issue that the entire gate was hitting yesterday, not just Rally. With the release of testtools 1.4.0, attrs in tempest broke, (which is probably a unittest2 bug being exposed) this caused the regex filters on attributes to stop working which broke a bunch of jobs. In the short term we've landed global requirements changes to exclude that testtools version, you probably just need to do the same on Rally to avoid the version which doesn't work. There is also tempest-side fix in progress here: https://review.openstack.org/#/c/135115/ But, that will take a bit longer to land. -Matt Treinish ___ 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] WSME 0.6.2 released
The WSME development team has released version 0.6.2, which includes several bug fixes. $ git log --oneline --no-merges 0.6.1..0.6.2 2bb9362 Fix passing Dict/Array based UserType as params ea9f71d Document next version changes 4e68f96 Allow non-auto-registered complex type 292c556 Make the flask adapter working with flask.ext.restful c833702 Avoid Sphinx 1.3x in the tests 6cb0180 Doc: status= - status_code= 4441ca7 Minor documentation edits 2c29787 Fix tox configuration. 26a6acd Add support for manually specifying supported content types in @wsmeexpose. 7cee58b Fix broken sphinx tests. baa816c fix errors/warnings in tests 2e1863d Use APIPATH_MAXLEN from the right module Please report issues through launchpad https://launchpad.net/wsme or the #wsme channel on IRC. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Contributing to Solum
Hi Keyvan, Great to hear that your team is interested in contributing to Solum. While there is no 'Ideas' page, there is this: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap The team is currently working on the Juno-3 milestone. In coming weeks we will be discussing the next milestone. If you get a chance, please join us today in the team meeting. It will be at 10.00am CDT in #openstack-meeting-alt channel on chat.freenode.net. At other times you can find us in the solum irc channel (#solum on chat.freenode.net) as well. Cheers, Devdatta From: Keyvan Mir Mohammad Sadeghi [keyvan.m.sade...@gmail.com] Sent: Tuesday, November 18, 2014 4:51 AM To: openstack-dev@lists.openstack.org Cc: Amirhossein Nourani Zadeh; Mehdi Balouchi; Ramin Barati Subject: [openstack-dev] [Solum] Contributing to Solum Hi, I am not even sure that I'm posting this in the right place, but the official Solum website was rather sparse on info regarding where to start. As a compact intro, my name is Keyvan, I've been an active OSS developer/adminhttps://github.com/keyvan-m-sadeghi since 2011, mainly working on the OpenCog projecthttps://github.com/opencog/opencog. I am planning to create a cloud platform, in the long-term. We are a team of 4 ppl, right now we're most interested in Solum, as it'd make a strong ground for our ideas. We all have strong Python skills and the team is willing to set aside around 10 hrs / week for Solum development, initially. I've read the wiki and there doesn't seem to be an 'Ideas' page where I could see a list of projects to be done, best thing I've found so far was the bugs pagehttps://bugs.launchpad.net/solum, but I'm not sure on where to start. We really appreciate if someone could define a small-sized project for us to undertake; that serves both for the purpose of getting to know Solum code more in depth and also set a start for our contribution. Regards, Keyvan -- Keyvan Mir Mohammad Sadeghi MSc AI One has to pay dearly for immortality; one has to die several times while one is still alive. -- Friedrich Nietzsche ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.db 1.1.0 released
Not sure if relevant but some tests on changes to requirements where failing today too on the postgres job Endre Karlson Matt, This is really weird. Victor and I will take a closer look. Thanks, Roman On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/oslo.db ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev And...the nova postgresql opportunistic DB tests are failing quite frequently due to some race introduced by the new library version [1]. [1] https://bugs.launchpad.net/oslo.db/+bug/1393633 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stale patches
-Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: 18 November 2014 14:40 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Stale patches On 2014-11-18 05:55:55 + (+), Kenichi Oomichi wrote: I am not concentrating on Neutron devs, but I also have the same feeling on the other area devs. I also cannot abandon the other developers' patches even if non-activities against some negative feedback. This has come up before... if you don't want to see stale patches you can use Gerrit queries or custom dashboards to only show you patches with recent activity. If all patches older than some specific date get abandoned, then that impacts the view of these patches for every reviewer. Selectively abandoning patches because they're no longer relevant makes sense, but just automatically abandoning them because _some_ reviewers don't want to see old changes is a disservice to other reviewers who don't have the same personal preference. I'd rather our infrastructure empowered reviewers to look at the changes they *want* to see, not tell them which changes they're *supposed* to review. I saw mail targeted towards nova earlier that Sean Dague was going to write an auto-abandon script to abandon patches with negative feedback for nova. Perhaps that script could be reused by other projects that see value in it. This was also brought up for the tripleo projects before, where I think the idea was mainly positively thought of (I am definitely an advocate for it). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thanks, Jon-Paul Sullivan ☺ Cloud Services - @hpcloud Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, Galway. Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's Quay, Dublin 2. Registered Number: 361933 The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated, you should consider this message and attachments as HP CONFIDENTIAL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Dynamic VM Consolidation Agent as part of Nova
Hi, I would like to bring Dynamic VM Consolidation capability into Nova. That is I would like to check compute nodes status periodically (let's say every 15 minutes) and consolidate VMs if there is any opportunity to turn off some compute nodes. Any hints on how to get into this development process as part of nova? Thanks, Mehdi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposing new meeting times
I would vote +1 for option #2, While I may not make many of the 0500 meetings, I could. So I see this as the best option. Chris On Tue, Nov 18, 2014 at 2:11 AM, Zhongyue Luo zhongyue@intel.com wrote: +1 for Option #2 On Tue, Nov 18, 2014 at 5:56 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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 -- *Intel SSG/STO/BDT* 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China +862161166500 ___ 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] oslo.db 1.1.0 released
On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/oslo.db ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev And...heat pep8 is failing because of changes to the config options which is generated in heat.conf.sample automatically in the pep8 runs, so that's also busted [1]. This is why nova removed auto-generation of nova.conf.sample, other libraries were constantly doing releases with changes to config options and breaking the gate for nova. [1] https://bugs.launchpad.net/heat/+bug/1393836 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses
Hello Community, When a network subnet runs out of IP addresses a request to create a VM on that network fails with the Error message: No valid host was found. There are not enough hosts available. In the nova logs the error message is: NoMoreFixedIps: No fixed IP addresses available for network: Obviously, this is not the desirable behavior, is there any work in progress to change it or I should open a bug to properly propagate the right error message. Thanks, Edgar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] the future of angularjs development in Horizon
On 18/11/14 12:54, Matthias Runge wrote:
On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote:
I guess I got the message that turning bower packages into system packages
was something that the Linux packagers were not keen on. Did I get the
message wrong there? If so, *and* we can get the bower stuff through #infra
and global-requirements then yes, we should totally try to avoid adding the
xstatic layer :)
For me, it's more work to turn packages into bower, or to translate
bower packages to system packages.
But that is purely because we don't have bower packaged currently in Fedora.
I would vote for the cleaner way (whatever that is).
XStatic is obviously not the cleanest way, but a good compromise in most
situations.
The way I thought about it, we would simply replace the Bower packages
with the corresponding system packages, by just changing the path in the
settings.py file.
Maybe an example would help illustrate it.
Currently we have something like this:
STATICFILES_DIRS = [
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular).base_dir),
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular_cookies).base_dir),
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular_mock).base_dir),
('horizon/lib/bootstrap_datepicker',
xstatic.main.XStatic(xstatic.pkg.bootstrap_datepicker).base_dir),
('bootstrap',
xstatic.main.XStatic(xstatic.pkg.bootstrap_scss).base_dir),
...
]
We would replace that with:
STATICFILES_DIRS = [
('horizon/lib/angular',
os.path.join(BASE_DIR, 'bower_modules/angular'),
...
]
or wherever bower puts the files. Now, the packagers would replace those
lines with:
STATICFILES_DIRS = [
('horizon/lib/angular',
'/usr/lib/javascript/angular'),
...
]
or whatever the packages in their distribution use. It's less work than
having to make a whole xstatic package just to put that single path in
there. The horizon system package would already depend on all the
javascript library packages, so we are sure the files are there.
--
Radomir Dopieralski
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.db 1.1.0 released
Matt, As for race in Nova - it caused by deprecated is_backend_avail() function, which calls _ensure_backenv_available() method, which creates a SQLAlchemy engine and opens a test connection, but doesn't call engine.dispose(). Depending on Python interpreter version, this connection may remain open for some time. So there are such ways to fix Nova: - wait for oslo.db 1.1.1 which will include fix for this method - see patch [1] - remove is_backend_avail() helper usage in Nova - patch [2] refactor Nova opportunistic DB tests and remove that method. [1] https://review.openstack.org/#/c/135293/ [2] https://review.openstack.org/#/c/103920/ On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/ oslo.db ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev And...the nova postgresql opportunistic DB tests are failing quite frequently due to some race introduced by the new library version [1]. [1] https://bugs.launchpad.net/oslo.db/+bug/1393633 -- Thanks, Matt Riedemann ___ 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] oslo.db 1.1.0 released
Is there a more minimal version of https://review.openstack.org/#/c/103920/ that *just* fixes this issue. So we can evaluate the refactor on it's own, but get the bug fixed more immediately. Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism so that warnings are emitted when this method is used. I didn't find anything in our unit tests logs. It would be helpful to keep us ahead of this in the future. It is odd that it exposed after the release (and not before), any idea which oslo.db change impacted this? -Sean On 11/18/2014 11:17 AM, Victor Sergeyev wrote: Matt, As for race in Nova - it caused by deprecated is_backend_avail() function, which calls _ensure_backenv_available() method, which creates a SQLAlchemy engine and opens a test connection, but doesn't call engine.dispose(). Depending on Python interpreter version, this connection may remain open for some time. So there are such ways to fix Nova: - wait for oslo.db 1.1.1 which will include fix for this method - see patch [1] - remove is_backend_avail() helper usage in Nova - patch [2] refactor Nova opportunistic DB tests and remove that method. [1] https://review.openstack.org/#/c/135293/ [2] https://review.openstack.org/#/c/103920/ On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/__oslo.db https://bugs.launchpad.net/oslo.db _ 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev And...the nova postgresql opportunistic DB tests are failing quite frequently due to some race introduced by the new library version [1]. [1] https://bugs.launchpad.net/__oslo.db/+bug/1393633 https://bugs.launchpad.net/oslo.db/+bug/1393633 -- Thanks, Matt Riedemann _ 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
On 18/11/14 16:33 +0800, Li Ma wrote: On 2014/11/17 22:26, Russell Bryant wrote: On 11/17/2014 05:44 AM, Ilya Pekelny wrote: Hi, all! We want to discuss opportunity of implementation of the p-2-p messaging model in oslo.messaging for ZeroMQ driver. On a related note, have you looked into AMQP 1.0 at all? I have been hopeful about the development to support it because of these same reasons. The AMQP 1.0 driver is now merged. I'd really like to see some work around trying it out with the dispatch router [1]. It seems like using amqp 1.0 + a distributed network of disaptch routers could be a very scalable approach. We still need to actually try it out and do some scale and performance testing, though. [1] http://qpid.apache.org/components/dispatch-router/ The design of dispatch-router is appealing. However I have some concern about qpid and the library. Is it reliable? Is there any success story of large deployment scenario about it? I hope this doesn't sound pedantic but for the sake of clarity, I'd like note that Qpid[0] is a set of messaging tools that include brokers[1], a message router[2], a messaging library[2], a protocol engine[4], among other things. The reason I make this distinction is because in order to use the recently landed amqp driver you don't depend on qpidd - the broker -, in fact, any broker with full support for amqp 1.0 could be used. This is one of the reasons why this driver was made *protocol* oriented instead of *technology* oriented. However, the driver landed in oslo.messaging during Juno, it's unlike to have a success story just yet. Pyngus is a lightweight framework for messaging and it uses the protocol engine[4] part of proton - which implements amqp's 1.0 standard. Hope this helps, Flavio [0] http://qpid.apache.org/ [1] http://qpid.apache.org/components/cpp-broker/index.html [2] http://qpid.apache.org/components/dispatch-router/index.html [3] http://qpid.apache.org/components/messenger/index.html [4] http://qpid.apache.org/components/protocol-engine/index.html -- @flaper87 Flavio Percoco pgpZKlDHkeZRA.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Contributing to Solum
Hi Keyvan, good to know of your interest in contributing to project Solum. If useful, Adrian and myself are available for a call with you to better understand your motivation around Solum and help you with getting plugged in a meaningful way. From: Keyvan Mir Mohammad Sadeghi [mailto:keyvan.m.sade...@gmail.com] Sent: Tuesday, November 18, 2014 4:52 AM To: openstack-dev@lists.openstack.org Cc: Amirhossein Nourani Zadeh; Mehdi Balouchi; Ramin Barati Subject: [openstack-dev] [Solum] Contributing to Solum Hi, I am not even sure that I'm posting this in the right place, but the official Solum website was rather sparse on info regarding where to start. As a compact intro, my name is Keyvan, I've been an active OSS developer/adminhttps://github.com/keyvan-m-sadeghi since 2011, mainly working on the OpenCog projecthttps://github.com/opencog/opencog. I am planning to create a cloud platform, in the long-term. We are a team of 4 ppl, right now we're most interested in Solum, as it'd make a strong ground for our ideas. We all have strong Python skills and the team is willing to set aside around 10 hrs / week for Solum development, initially. I've read the wiki and there doesn't seem to be an 'Ideas' page where I could see a list of projects to be done, best thing I've found so far was the bugs pagehttps://bugs.launchpad.net/solum, but I'm not sure on where to start. We really appreciate if someone could define a small-sized project for us to undertake; that serves both for the purpose of getting to know Solum code more in depth and also set a start for our contribution. Regards, Keyvan -- Keyvan Mir Mohammad Sadeghi MSc AI One has to pay dearly for immortality; one has to die several times while one is still alive. -- Friedrich Nietzsche ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Proposing new meeting times
On Tue, Nov 18, 2014 at 01:00:04AM +, Devananda van der Veen wrote: Hi all, As discussed in Paris and at today's IRC meeting [1] we are going to be alternating the time of the weekly IRC meetings to accommodate our contributors in EMEA better. No time will be perfect for everyone, but as it stands, we rarely (if ever) see our Indian, Chinese, and Japanese contributors -- and it's quite hard for any of the AU / NZ folks to attend. I'm proposing two sets of times below. Please respond with a -1 vote to an option if that option would cause you to miss ALL meetings, or a +1 vote if you can magically attend ALL the meetings. If you can attend, without significant disruption, at least one of the time slots in a proposal, please do not vote either for or against it. This way we can identify a proposal which allows everyone to attend at a minimum 50% of the meetings, and preferentially weight towards one that allows more contributors to attend two meetings. This link shows the local times in some major coutries / timezones around the world (and you can customize it to add your own). http://www.timeanddate.com/worldclock/meetingtime.html?iso=20141125p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 For reference, the current meeting time is 1900 UTC. Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 Option #2: alternate between Monday 1700 UTC Tuesday 0500 UTC. I like this because it shifts the current slot two hours earlier, making it easier for eastern EU to attend without excluding the western US, and while 0500 UTC is not so late that US west coast contributors can't attend (it's 9PM for us), it is harder for western EU folks to attend. There's really no one in the middle here, but there is at least a chance for US west coast and EMEA to overlap, which we don't have at any other time. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=17min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1, I probably won't make all of the 0500 meetings, but will make some. // jim I'll collate all the responses to this thread during the week, ahead of next week's regularly-scheduled meeting. -Devananda [1] http://eavesdrop.openstack.org/meetings/ironic/2014/ironic.2014-11-17-19.00.log.html ___ 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] [all] OpenStack Bootstrapping Hour: Debugging in the Gate - Friday Nov 21st 20:00 UTC (15:00 Americas/New_York)
This Friday's Bootstrapping Hour will be on Debugging in the Gate - https://wiki.openstack.org/wiki/BootstrappingHour/Debugging_Gate#Debugging_in_the_Gate The etherpad has the discussions notes I'll be using for it - https://etherpad.openstack.org/p/obh-debugging-openstack-gate For folks that can't make the event synchronously, it will be recorded and posted on youtube shortly after the event. Also, feel free to add to the Questions section at the end of the etherpad (with name please in case I want to get clarification prior to the broadcast). Will make sure to try to answer all questions written down during the broadcast. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work was identified for the L2 agent. We had a discussion in the Neutron meeting today about bootstrapping that work. The first order of business will be to generate a blueprint specification for the work similar, in purpose, to the one that is under discussion for the L3 agent [3]. I personally am at or over capacity for BP writing this cycle. We need a volunteer to take this on coordinating with others who have been identified on the etherpad for L2 agent work (you know who you are) and other volunteers who have yet to be identified. This task force will use the weekly Neutron meeting, the ML, and IRC to coordinate efforts. But first, we need to bootstrap the task force. If you plan to participate, please reply to this email and describe how you will contribute, especially if you are willing to be the lead author of a BP. I will reconcile this with the etherpad to see where gaps have been left. I am planning to contribute as a core reviewer of blueprints and code submissions only. Carl [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt [2] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html [3] https://review.openstack.org/#/c/131535/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic] Cleaning up spec review queue.
Hi all, In an effort to keep the Ironic specs review queue as up to date as possible, I have identified several specs that were proposed in the Juno cycle and have not been updated to reflect the changes to the current Kilo cycle. I would like to set a deadline to either update them to reflect the Kilo cycle or abandon them if they are no longer relevant. If there are no objections I will abandon any specs on the list below that have not been updated to reflect the Kilo cycle after the end of the next Ironic meeting (Nov. 24th 2014). Below is the list of specs I have identified that would be affected: https://review.openstack.org/#/c/107344 - *Generic Hardware Discovery Bits* https://review.openstack.org/#/c/102557 - *Driver for NetApp storage arrays* https://review.openstack.org/#/c/108324 - *DRAC hardware discovery* https://review.openstack.org/#/c/103065 - *Design spec for iLO driver for firmware settings* https://review.openstack.org/#/c/108646 - *Add HTTP GET support for vendor_passthru API* https://review.openstack.org/#/c/94923 - *Make the REST API fully asynchronous* https://review.openstack.org/#/c/103760 - *iLO Management Driver for firmware update* https://review.openstack.org/#/c/110217 - *Cisco UCS Driver* https://review.openstack.org/#/c/96538 - *Add console log support* https://review.openstack.org/#/c/100729 - *Add metric reporting spec.* https://review.openstack.org/#/c/101122 - *Firmware setting design spec.* https://review.openstack.org/#/c/96545 - *Reset service processor* *This list may also be found on this ether pad: https://etherpad.openstack.org/p/ironic-juno-specs-to-be-removed https://etherpad.openstack.org/p/ironic-juno-specs-to-be-removed* If you believe one of the above specs should not be abandoned please update the spec to reflect the current Kilo cycle, or let us know that a update is forth coming. Please feel free to reply to this email, I will also bring this topic up at the next meeting to ensure we have as much visibility as possible before abandoning the old specs. Thank you, Chris Krelle IRC: NobodyCam ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] oslo.db 1.1.0 released
Well, we can re-define is_backend_avail() in Nova code and use it instead of oslo.db's function. it looks a bit ugly but it will be fast Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism so that warnings are emitted when this method is used. I didn't find anything in our unit tests logs. It ok, will suggest It is odd that it exposed after the release (and not before), any idea which oslo.db change impacted this? This bug depends fro python version so we haven't catch it locally :( On Tue, Nov 18, 2014 at 6:47 PM, Sean Dague s...@dague.net wrote: Is there a more minimal version of https://review.openstack.org/#/c/103920/ that *just* fixes this issue. So we can evaluate the refactor on it's own, but get the bug fixed more immediately. Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism so that warnings are emitted when this method is used. I didn't find anything in our unit tests logs. It would be helpful to keep us ahead of this in the future. It is odd that it exposed after the release (and not before), any idea which oslo.db change impacted this? -Sean On 11/18/2014 11:17 AM, Victor Sergeyev wrote: Matt, As for race in Nova - it caused by deprecated is_backend_avail() function, which calls _ensure_backenv_available() method, which creates a SQLAlchemy engine and opens a test connection, but doesn't call engine.dispose(). Depending on Python interpreter version, this connection may remain open for some time. So there are such ways to fix Nova: - wait for oslo.db 1.1.1 which will include fix for this method - see patch [1] - remove is_backend_avail() helper usage in Nova - patch [2] refactor Nova opportunistic DB tests and remove that method. [1] https://review.openstack.org/#/c/135293/ [2] https://review.openstack.org/#/c/103920/ On Tue, Nov 18, 2014 at 5:22 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: On 11/17/2014 9:36 AM, Victor Sergeyev wrote: Hello All! Oslo team is pleased to announce the new release of Oslo database handling library - oslo.db 1.1.0 List of changes: $ git log --oneline --no-merges 1.0.2..master 1b0c2b1 Imported Translations from Transifex 9aa02f4 Updated from global requirements 766ff5e Activate pep8 check that _ is imported f99e1b5 Assert exceptions based on API, not string messages 490f644 Updated from global requirements 8bb12c0 Updated from global requirements 4e19870 Reorganize DbTestCase to use provisioning completely 2a6dbcd Set utf8 encoding for mysql and postgresql 1b41056 ModelsMigrationsSync: Add check for foreign keys 8fb696e Updated from global requirements ba4a881 Remove extraneous vim editor configuration comments 33011a5 Remove utils.drop_unique_constraint() 64f6062 Improve error reporting for backend import failures 01a54cc Ensure create_engine() retries the initial connection test 26ec2fc Imported Translations from Transifex 9129545 Use fixture from oslo.config instead of oslo-incubator 2285310 Move begin ping listener to a connect listener 7f9f4f1 Create a nested helper function that will work on py3.x b42d8f1 Imported Translations from Transifex 4fa3350 Start adding a environment for py34/py33 b09ee9a Explicitly depend on six in requirements file 7a3e091 Unwrap DialectFunctionDispatcher from itself. 0928d73 Updated from global requirements 696f3c1 Use six.wraps instead of functools.wraps 8fac4c7 Update help string to use database fc8eb62 Use __qualname__ if we can 6a664b9 Add description for test_models_sync function 8bc1fb7 Use the six provided iterator mix-in 436dfdc ModelsMigrationsSync:add correct server_default check for Enum 2075074 Add history/changelog to docs c9e5fdf Add run_cross_tests.sh script Thanks Andreas Jaeger, Ann Kamyshnikova, Christian Berendt, Davanum Srinivas, Doug Hellmann, Ihar Hrachyshka, James Carey, Joshua Harlow, Mike Bayer, Oleksii Chuprykov, Roman Podoliaka for contributing to this release. Please report issues to the bug tracker: https://bugs.launchpad.net/__oslo.db https://bugs.launchpad.net/oslo.db _ 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
Re: [openstack-dev] oslo.db 1.1.0 released
On Nov 18, 2014, at 11:47 AM, Sean Dague s...@dague.net wrote: Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism so that warnings are emitted when this method is used. +1 for DeprecationWarnings, I noticed oslo.db doesn’t seem to use these ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stale patches
On Tue, Nov 18, 2014 at 7:39 AM, Jeremy Stanley fu...@yuggoth.org wrote: This has come up before... if you don't want to see stale patches you can use Gerrit queries or custom dashboards to only show you patches with recent activity. If all patches older than some specific date get abandoned, then that impacts the view of these patches for every reviewer. Selectively abandoning patches because they're no longer relevant makes sense, but just automatically abandoning them because _some_ reviewers don't want to see old changes is a disservice to other reviewers who don't have the same personal preference. I'd rather our infrastructure empowered reviewers to look at the changes they *want* to see, not tell them which changes they're *supposed* to review. I see your point here. We're all going to have our own customizations, of course but the fact that Salvatore took his time -- which is precious to the project -- to go through and abandon stale patches and his effort was met with applause and congratulations says something to me. It says that, as a project, we want this. If I'm speaking out of turn, please speak up and let me know. I personally don't enjoy customizing my own view more than I have to. I see it as kind of an annoyance. I'd rather not have to and be free to focus on other project issues. Carl ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance][stable] Review request
Hi All, Greetings!!! Can anyone please review this patch [1]. It requires one more +2 to get merged in stable/juno. We want to use stable/juno in production environment and this patch will fix the blocker bug [1] for restrict download image feature. Please do the needful. [1] https://review.openstack.org/#/c/133858/ [2] https://bugs.launchpad.net/glance/+bug/1387973 Thank You in advance. Abhishek Kekane __ Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute
Flavio Percoco wrote: On 18/11/14 11:42 +0100, Thierry Carrez wrote: With storyboard.openstack.org http://storyboard.openstack.org looming on the horizon, should such an effort be put on the back burner for now? I don't expect integrated projects to be able to switch to storyboard for bug tracking just yet. Our current goal is to have it ready for infrastructure dogfooding now (actually, yesterday), ready for feature tracking (and bugs tracking replacement for willing non-integrated guinea pigs) in 6 months, and ready for everyone in 12 months. Is it in a good enough state that would a low smaller projects - zaqar - to jump in and help testing the storyboard? I'm happy to give it a try. The trick is that it's missing some features that would make it a pain, even for an incubated project (think: no private security bugs). Also we'd like to switch all integrated projects at the same time, so that release management doesn't have to play with two tools in parallel. Also, nothing in storyboard actually makes triaging less painful :) -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Zero MQ remove central broker. Architecture change.
I think for this cycle we really do need to focus on consolidating and testing the existing driver design and fixing up the biggest deficiency (1) before we consider moving forward with lots of new +1 1) Outbound messaging connection re-use - right now every outbound messaging creates and consumes a tcp connection - this approach scales badly when neutron does large fanout casts. I'm glad you are looking at this and by doing so, will understand the system better. I hope the following will give some insight into, at least, why I made the decisions I made: This was an intentional design trade-off. I saw three choices here: build a fully decentralized solution, build a fully-connected network, or use centralized brokerage. I wrote off centralized brokerage immediately. The problem with a fully connected system is that active TCP connections are required between all of the nodes. I didn't think that would scale and would be brittle against floods (intentional or otherwise). IMHO, I always felt the right solution for large fanout casts was to use multicast. When the driver was written, Neutron didn't exist and there was no use-case for large fanout casts, so I didn't implement multicast, but knew it as an option if it became necessary. It isn't the right solution for everyone, of course. For connection reuse, you could manage a pool of connections and keep those connections around for a configurable amount of time, after which they'd expire and be re-opened. This would keep the most actively used connections alive. One problem is that it would make the service more brittle by making it far more susceptible to running out of file descriptors by keeping connections around significantly longer. However, this wouldn't be as brittle as fully-connecting the nodes nor as poorly scalable. If OpenStack and oslo.messaging were designed specifically around this message pattern, I might suggest that the library and its applications be aware of high-traffic topics and persist the connections for those topics, while keeping others ephemeral. A good example for Nova would be api-scheduler traffic would be persistent, whereas scheduler-compute_node would be ephemeral. Perhaps this is something that could still be added to the library. 2) PUSH/PULL tcp sockets - Pieter suggested we look at ROUTER/DEALER as an option once 1) is resolved - this socket type pairing has some interesting features which would help with resilience and availability including heartbeating. Using PUSH/PULL does not eliminate the possibility of being fully connected, nor is it incompatible with persistent connections. If you're not going to be fully-connected, there isn't much advantage to long-lived persistent connections and without those persistent connections, you're not benefitting from features such as heartbeating. I'm not saying ROUTER/DEALER cannot be used, but use them with care. They're designed for long-lived channels between hosts and not for the ephemeral-type connections used in a peer-to-peer system. Dealing with how to manage timeouts on the client and the server and the swelling number of active file descriptions that you'll get by using ROUTER/DEALER is not trivial, assuming you can get past the management of all of those synchronous sockets (hidden away by tons of eventlet greenthreads)... Extra anecdote: During a conversation at the OpenStack summit, someone told me about their experiences using ZeroMQ and the pain of using REQ/REP sockets and how they felt it was a mistake they used them. We discussed a bit about some other problems such as the fact it's impossible to avoid TCP fragmentation unless you force all frames to 552 bytes or have a well-managed network where you know the MTUs of all the devices you'll pass through. Suggestions were made to make ZeroMQ better, until we realized we had just described TCP-over-ZeroMQ-over-TCP, finished our beers, and quickly changed topics. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] NTP settings.
Yes, it does. On Sat, Nov 15, 2014 at 3:15 AM, Rick Jones rick.jon...@hp.com wrote: On 11/14/2014 04:01 PM, Dmitry Borodaenko wrote: If NTP server is not reachable on the first boot of the master node, it should be disabled by bootstrap_admin_node, that eliminates the possibility of it spontaneously coming to life and changing the clock for fuel master node and all target nodes in the middle of a deployment. Then all Nailgun needs to do is pop a warning notification that no NTP server is configured on the master node, and it should be fixed manually before starting any deployments. No need to block deployment altogether: if the user doesn't need need global time at all (e.g. in an off-the-grid bunker 2 miles beneath Fort Knox), synchronizing clocks on all environments just to the Fuel master will still work. I thought NTP (well ntpd) had an option to tell it to only ever slew the clock, never step it? Or is that only some implementations of NTP? rick jones ___ 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] [neutron][stable] Review request
Neutron cores: I submitted a bug fix a bit over a month ago which is waiting for one more core (+2) review. The changes are rather simple which affects the ovs/ofa code. Could a core person take the time to review? Here are the pointers to the changes: https://review.openstack.org/127654 https://bugs.launchpad.net/neutron/+bug/1367697 Carol [http://wwwin.cisco.com/marketing/corporate/brand/intelbrand/brandstrat/signature/none] Carol Bouchard TECHNICAL LEADER.ENGINEERING cabou...@cisco.commailto:cabou...@cisco.com WebEx Social profilehttp://iwe.cisco.com/web/caboucha Phone: +1 978 936 2124 Cisco.comhttp://www.cisco.com [Description: Think before you print.]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] Alternative federation mapping
We started an etherpad to gather requirements etc: https://etherpad.openstack.org/p/mapping-engine-enhancements ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework to make the agent code more modular, avoid code replication across multiple L2 agents, and to make adding new features and writing new agents (if/when necessary) easier. I will be happy to take a stab at writing the blueprint/spec based on that work and what is specified in the etherpad [1]. I had to take a few weeks off from work and therefore had to miss the Summit; This happened right around the time that paying our technical debts was becoming a common phrase in Neutron (for good reasons) and from what I can gather from the etherpad [1] the scope for this effort may have expanded and there are others who have volunteered to work on various aspects of this effort. So, if there are others who want to start the task force by writing this blueprint/spec, that is perfectly fine with me. If not, I will be happy to get that started. Best, Mohammad (banix) From: Carl Baldwin c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 11/18/2014 12:19 PM Subject:[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work was identified for the L2 agent. We had a discussion in the Neutron meeting today about bootstrapping that work. The first order of business will be to generate a blueprint specification for the work similar, in purpose, to the one that is under discussion for the L3 agent [3]. I personally am at or over capacity for BP writing this cycle. We need a volunteer to take this on coordinating with others who have been identified on the etherpad for L2 agent work (you know who you are) and other volunteers who have yet to be identified. This task force will use the weekly Neutron meeting, the ML, and IRC to coordinate efforts. But first, we need to bootstrap the task force. If you plan to participate, please reply to this email and describe how you will contribute, especially if you are willing to be the lead author of a BP. I will reconcile this with the etherpad to see where gaps have been left. I am planning to contribute as a core reviewer of blueprints and code submissions only. Carl [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt [2] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html [3] https://review.openstack.org/#/c/131535/ ___ 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] DB: transaction isolation and related questions
Hi neutron folks,
There is an ongoing effort to refactor some neutron DB logic to be
compatible with galera/mysql which doesn't support locking
(with_lockmode('update')).
Some code paths that used locking in the past were rewritten to retry the
operation if they detect that an object was modified concurrently.
The problem here is that all DB operations (CRUD) are performed in the
scope of some transaction that makes complex operations to be executed in
atomic manner.
For mysql the default transaction isolation level is 'REPEATABLE READ'
which means that once the code issue a query within a transaction, this
query will return the same result while in this transaction (e.g. the
snapshot is taken by the DB during the first query and then reused for the
same query).
In other words, the retry logic like the following will not work:
def allocate_obj():
with session.begin(subtrans=True):
for i in xrange(n_retries):
obj = session.query(Model).filter_by(filters)
count =
session.query(Model).filter_by(id=obj.id).update({'allocated':
True})
if count:
return obj
since usually methods like allocate_obj() is called from within another
transaction, we can't simply put transaction under 'for' loop to fix the
issue.
The particular issue here is https://bugs.launchpad.net/neutron/+bug/1382064
with the proposed fix:
https://review.openstack.org/#/c/129288
So far the solution proven by tests is to change transaction isolation
level for mysql to be 'READ COMMITTED'.
The patch suggests changing the level for particular transaction where
issue occurs (per sqlalchemy, it will be reverted to engine default once
transaction is committed)
This isolation level allows the code above to see different result in each
iteration.
At the same time, any code that relies that repeated query under same
transaction gives the same result may potentially break.
So the question is: what do you think about changing the default isolation
level to READ COMMITTED for mysql project-wise?
It is already so for postgress, however we don't have much concurrent test
coverage to guarantee that it's safe to move to a weaker isolation level.
Your feedback is appreciated.
Thanks,
Eugene.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Poll for change in weekly meeting time.
We've had a few responses to this poll however, they do not seem to cover the entire set of developers including many of the cores and developers who are going to be actively working on the features this cycle. Based on the responses received, I'd like to propose a (unified - no alternating) time of 14:30UTC on Thursdays (channel(s) TBD). This change will help the vast majority of developers who prefer the current earlier time slot as well as reduce the no-shows in the later one. If you'r not happy with the proposal please vote and (or) please reach out before this week's meeting on Thursday. Please let me know if you've any concerns. Thanks, -Nikhil From: Nikhil Komawar Sent: Friday, October 31, 2014 4:41 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Glance] Poll for change in weekly meeting time. Hi all, It was noticed in the past few meetings that the participation in the alternating time-slot of Thursday at 20 UTC (or called as later time slot) was low. With the growing interest in Glance of developers from eastern latitudes and their involvement in meetings, please find this email as a proposal to move all meetings to an earlier time-slot. Here's a poll [0] to find what time-slots work best for everyone as well as for the interest to remove the alternating time-slot aspect in the schedule. Please be empathetic in your votes, try to suggest all possible options that would work for you and note the changes in your timezone due to day-light savings ending. Please let me know if you've any more questions. [0] http://doodle.com/nwc26k8satuyvvmz Thanks, -Nikhil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Requesting opinion/guideline on IDs vs hrefs
The discussion about whether flavors should exist as-is or be decomposed is
useful and should continue. It is, however, somewhat orthogonal to the
discussion I was hoping to have on this thread :)
So coming back to the original question (now generalized away from flavors):
how should resource representations refer to other resources?
a) Using an {resource}_id property whose value is a naked ID (e.g. 12345,
1ef1cf90-6f53-11e4-9803-0800200c9a66”), or
b) Using a {resource}_ref property whose value is the URI for the referenced
resource, (e.g. {base}/{resource}/12345), or
c) Using a links property whose value is an array of links, one of which has
an object like { rel: {resource}, href: {base}/{resource}/12345 }, or
d) Similar to c) but using HAL instead, or
e) A combination of a) and c), or
f) A combination of a) and d), or
g) Something else?
So far I've heard two opinions on the above:
- Using a) primarily, but possibly e) for convenience
- Not using c), d), e) or f) since links or _links in JSON+HAL aren't
intended for this purpose
Are there any other opinions on this issue of referencing? If not, I'm thinking
of going with a).
Thank you,
Shaunak
On Nov 17, 2014, at 3:33 PM, Amit Gandhi amit.gan...@rackspace.com wrote:
Agreed it helps with billing. It also allows the customer to make a
choice based on the features offered in a flavor. At the end of the day,
the API works the same way regardless of the flavor selected. The flavor
selection merely gives the customer the experience they are looking for.
I see flavors working this way:
Nova - choosing a flavor that represents the type of compute power you
need. Many combinations could exist.
Zaqar - choosing a flavor that represents the type of messaging you need
(performance, durability, ha, or any combinations of them)
Poppy - choosing a flavor that represents the type of cdn you need
(performance, regionality, cost, or any combination of them)
…and so on…
Within each ‘feature’ there could be multiple options.
Hence I struggle to see how ‘features’ could be exposed directly by the
api’s if that only limits it to one driver of each feature (i.e. There
could be multiple drivers that meet the performance feature for example).
The flavor concept allows operators to package together some of these
features, and offer it to customers - who can then select that flavor via
the API.
In terms of inter-operable clouds, since the API functionality works the
same regardless of flavor, I don’t think it breaks interoperability.
Since operators can define their flavor names themselves and what drives
those flavors, then there is work on the dev to refer to the new flavor at
the new operator’s cloud. But inverting that argument - will every cloud
operator always offer the same flavors? Will some operators prefer to
offer certain flavors only? How do you define flavors (or their features)
in a generic way that allows for the gray area’s in between, and multiple
permutations of the same benefit?
I am curious to explore the idea of not using flavors and replacing the
concept with something more generic (with concrete examples with some of
the existing API’s). It sounds great to me, I just can’t (at this time)
think of how it would work.
Thanks.
Amit.
On 11/17/14, 5:38 PM, Ed Leafe e...@leafe.com wrote:
On Nov 17, 2014, at 3:46 PM, Amit Gandhi amit.gan...@rackspace.com
wrote:
I can see where this makes a lot of sense in API¹s such as Nova¹s where
flavors represent some combination of memory, disk, and cpu performance.
For Nova, flavors emerged more as a billing convenience than anything
technical regarding creating a VM with certain characteristics.
In the case of CDN, the flavor represents a list of CDN providers.
So... you could have a flavor representing a region of the world
(America¹s) consisting of one or more CDN providers with a strong
presence
in those regions.
Or a flavor could represent performance or features offered (number of
edge nodes, speed, etc). And it is up to the operator to define those
flavors and assign one or more appropriate CDN providers to those
flavors.
Again, this seems like the sort of packaging you would need to charge
customers for different levels of service, and not something that you
would need to make a working CDN API.
-- Ed Leafe
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] New Policy Administration Service
Based on the thread entitled [all][policy][keystone] Better Policy Model and Representing Capabilites from October 20, I wrote some code to pull a policy.json file into Congress and figure out what roles are necessary to give access to a specific API call. So if bundling this kind of functionality into Congress is a reasonable way forward, it seems doable technically. We’re happy to help in any case, so let us know! Tim -- Forwarded message -- From: Ioram Schechtman Sette i...@cin.ufpe.brmailto:i...@cin.ufpe.br Date: Tue, Nov 18, 2014 at 5:52 AM Subject: [openstack-dev] [Keystone] New Policy Administration Service To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Hi all, In Paris, on the last day, we listed the new features that we would like to see in the next release of Keystone. The top 3 were chosen as high priority. Further down the list was a policy administration service that will collect policies from all the Openstack services and allow the Keystone administrator to ask the question what role do I need to assign to a user to give access to these services? and will allow users to ask the question what can I access with my roles?. We have now started to design and build this service. An important design decision is should this service be integrated with Keystone or be a separated standalone Openstack service? What does the Keystone group think? If policy administration should be a separate service, what is the process to register blueprints, apis and code reviews? Regards, Ioram and David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute
Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800: Greetings, Regardless of how big/small bugs backlog is for each project, I believe this is a common, annoying and difficult problem. At the oslo meeting today, we're talking about how to address our bug triage process and I proposed something that I've seen done in other communities (rust-language [0]) that I consider useful and a good option for OpenStack too. The process consist in a bot that sends an email to every *volunteer* with 10 bugs to review/triage for the week. Each volunteer follows the triage standards, applies tags and provides information on whether the bug is still valid or not. The volunteer doesn't have to fix the bug, just triage it. In openstack, we could have a job that does this and then have people from each team volunteer to help with triage. The benefits I see are: * Interested folks don't have to go through the list and filter the bugs they want to triage. The bot should be smart enough to pick the oldest, most critical, etc. * It's a totally opt-in process and volunteers can obviously ignore emails if they don't have time that week. * It helps scaling out the triage process without poking people around and without having to do a call for volunteers every meeting/cycle/etc The above doesn't solve the problme completely but just like reviews, it'd be an optional, completely opt-in process that people can sign up for. My experience in Ubuntu, where we encouraged non-developers to triage bugs, was that non-developers often ask the wrong questions and sometimes even harm the process by putting something in the wrong priority or state because of a lack of deep understanding. Triage in a hospital is done by experienced nurses and doctors working together, not triagers. This is because it may not always be obvious to somebody just how important a problem is. We have the same set of problems. The most important thing is that developers see it as an important task and take part. New volunteers should be getting involved at every level, not just bug triage. I think the best approach to this, like reviews, is to have a place where users can go to drive the triage workload to 0. For instance, the ubuntu server team had this report for triage: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html Sadly, it looks like they're overwhelmed or have abandoned the effort (I hope this doesn't say something about Ubuntu server itself..), but the basic process was to move bugs off these lists. I'm sure if we ask nice the author of that code will share it with us and we could adapt it for OpenStack projects. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Quota management and enforcement across projects
On Nov 17, 2014, at 7:18 PM, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Mon, 2014-11-17 at 18:48 -0500, Doug Hellmann wrote: I’ve spent a bit of time thinking about the resource ownership issue. The challenge there is we don’t currently have any libraries that define tables in the schema of an application. I think that’s a good pattern to maintain, since it avoids introducing a lot of tricky issues like how to manage migrations for the library, how to ensure they are run by the application, etc. The fact that this common quota thing needs to store some data in a schema that it controls says to me that it is really an app and not a library. Making the quota manager an app solves the API definition issue, too, since we can describe a generic way to configure quotas and other applications can then use that API to define specific rules using the quota manager’s API. I don’t know if we need a new application or if it would make sense to, as with policy, add quota management features to keystone. A single well-defined app has some appeal, but there’s also a certain amount of extra ramp-up time needed to go that route that we wouldn’t need if we added the features directly to keystone. I'll also point out that it was largely because of the storage needs that I chose to propose Boson[1] as a separate app, rather than as a library. Further, the dimensions over which quota-covered resources needed to be tracked seemed to me to be complicated enough that it would be better to define a new app and make it support that one domain well, which is why I didn't propose it as something to add to Keystone. Consider: nova has quotas that are applied by user, other quotas that are applied by tenant, and even some quotas on what could be considered sub-resources—a limit on the number of security group rules per security group, for instance. My current feeling is that, if we can figure out a way to make the quota problem into an acceptable library, that will work; it would probably have to maintain its own database separate from the client app and have features for automatically managing the schema, since we couldn't necessarily rely on the client app to invoke the proper juju there. If, on the other hand, that ends up failing, then the best route is probably to begin by developing a separate app, like Boson, as a PoC; then, after we have some idea of just how difficult it is to actually solve the problem, we can evaluate whether it makes sense to actually fold it into a service like Keystone, or whether it should stand on its own. (Personally, I think Boson should be created and should stand on its own, but I also envision using it for purposes outside of OpenStack…) Thanks for mentioning Boson again. I’m embarrassed that I completely forgot about the fact that you mentioned this at the summit. I’ll have to look at the proposal more closely before I comment in any detail, but I take it as a good sign that we’re coming back around to the idea of solving this with an app instead of a library. Doug Just my $.02… [1] https://wiki.openstack.org/wiki/Boson -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ 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] [Horizon] the future of angularjs development in Horizon
On 19 November 2014 03:14, Radomir Dopieralski openst...@sheep.art.pl
wrote:
On 18/11/14 12:54, Matthias Runge wrote:
On Tue, Nov 18, 2014 at 09:36:00PM +1100, Richard Jones wrote:
I guess I got the message that turning bower packages into system
packages
was something that the Linux packagers were not keen on. Did I get the
message wrong there? If so, *and* we can get the bower stuff through
#infra
and global-requirements then yes, we should totally try to avoid adding
the
xstatic layer :)
For me, it's more work to turn packages into bower, or to translate
bower packages to system packages.
But that is purely because we don't have bower packaged currently in
Fedora.
I would vote for the cleaner way (whatever that is).
XStatic is obviously not the cleanest way, but a good compromise in most
situations.
The way I thought about it, we would simply replace the Bower packages
with the corresponding system packages, by just changing the path in the
settings.py file.
Maybe an example would help illustrate it.
Currently we have something like this:
STATICFILES_DIRS = [
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular).base_dir),
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular_cookies).base_dir),
('horizon/lib/angular',
xstatic.main.XStatic(xstatic.pkg.angular_mock).base_dir),
('horizon/lib/bootstrap_datepicker',
xstatic.main.XStatic(xstatic.pkg.bootstrap_datepicker).base_dir),
('bootstrap',
xstatic.main.XStatic(xstatic.pkg.bootstrap_scss).base_dir),
...
]
We would replace that with:
STATICFILES_DIRS = [
('horizon/lib/angular',
os.path.join(BASE_DIR, 'bower_modules/angular'),
...
]
or wherever bower puts the files. Now, the packagers would replace those
lines with:
STATICFILES_DIRS = [
('horizon/lib/angular',
'/usr/lib/javascript/angular'),
...
]
or whatever the packages in their distribution use. It's less work than
having to make a whole xstatic package just to put that single path in
there. The horizon system package would already depend on all the
javascript library packages, so we are sure the files are there.
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+1 to all that, except I'd recommend using django-bower to handle the
static collection stuff. It's not documented but django-bower has a setting
BOWER_COMPONENTS_ROOT which would make the above transition much simpler.
You leave it alone for local dev, and packagers setup BOWER_COMPONENTS_ROOT
to '/usr/lib/javascript/' or wherever.
bower also has a concept of entry points - there a main value in the
bower.json which identifies the Javascript, CSS, font and other files to
include in the index.html to have the library loaded into your application.
Saves a bunch of manual editing to get things right when you include the
library. Sadly, the current django-bower plugin doesn't use any of that,
though it does handle the collectstatic stuff.
Richard
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] A mascot for Ironic
On 11/16/2014 10:51 AM, David Shrewsbury wrote: On Nov 16, 2014, at 8:57 AM, Chris K nobody...@gmail.com mailto:nobody...@gmail.com wrote: How cute. maybe we could call him bear-thoven. Chris I like Blaze Bearly, lead singer for Ironic Maiden. :) https://en.wikipedia.org/wiki/Blaze_Bayley Good call! I never thought I'd see a Blaze Bayley reference on this list. :) Just watch out for imposters... http://en.wikipedia.org/wiki/Slow_Riot_for_New_Zer%C3%B8_Kanada#BBF3 On Sun, Nov 16, 2014 at 5:14 AM, Lucas Alvares Gomes lucasago...@gmail.com mailto:lucasago...@gmail.com wrote: Hi Ironickers, I was thinking this weekend: All the cool projects does have a mascot so I thought that we could have one for Ironic too. The idea about what the mascot would be was easy because the RAX guys put bear metal their presentation[1] and that totally rocks! So I drew a bear. It also needed an instrument, at first I thought about a guitar, but drums is actually my favorite instrument so I drew a pair of drumsticks instead. The drawing thing wasn't that hard, the problem was to digitalize it. So I scanned the thing and went to youtube to watch some tutorials about gimp and inkspace to learn how to vectorize it. Magic, it worked! Attached in the email there's the original draw, the vectorized version without colors and the final version of it (with colors). Of course, I know some people does have better skills than I do, so I also attached the inkspace file of the final version in case people want to tweak it :) So, what you guys think about making this little drummer bear the mascot of the Ironic project? Ahh he also needs a name. So please send some suggestions and we can vote on the best name for him. [1] http://www.youtube.com/watch?v=2Oi2T2pSGDU#t=90 Lucas ___ 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 ___ 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] oslo.db 1.1.0 released
On Nov 18, 2014, at 12:26 PM, Mike Bayer mba...@redhat.com wrote: On Nov 18, 2014, at 11:47 AM, Sean Dague s...@dague.net wrote: Also can I request that when deprecating methods in oslo libraries we use a standard deprecation mechanism so that warnings are emitted when this method is used. +1 for DeprecationWarnings, I noticed oslo.db doesn’t seem to use these We have some in-house deprecation stuff that indicates when features are going to be removed, too. http://git.openstack.org/cgit/openstack/oslo-incubator/tree/openstack/common/versionutils.py ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystyone] Mid-Cycle Meetup Planning
I'm very much interested in this new Keystyone thing. Is the name still open to debeate? On Wed, Nov 12, 2014 at 9:26 AM, Brad Topol bto...@us.ibm.com wrote: I have filled out the form and very much look forward to attending!!! Brad Topol, Ph.D. IBM Distinguished Engineer OpenStack (919) 543-0646 Internet: bto...@us.ibm.com Assistant: Kendra Witherspoon (919) 254-0680 From:Morgan Fainberg morgan.fainb...@gmail.com To:OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date:11/11/2014 08:20 PM Subject:[openstack-dev] [Keystyone] Mid-Cycle Meetup Planning -- I am trying to pin down a location for our mid-cycle meetup, I need to get an idea of who will be joining us at the Keystone meetup. I’ve included a couple questions relating to Barbican in the case we can double-up and have a day of overlap like the Juno meetup. I apologize for the delay, this should have been sent out by the end of the summit or earlier. As details are available I’ll provide updates. Due to timing (so that people can get visas, get travel approval, etc as soon as possible), I will be making a final call on dates by the end of this week and location as soon as the space is confirmed, so your prompt responses are super important! *http://goo.gl/forms/4W7xVM9x49* http://goo.gl/forms/4W7xVM9x49 Cheers, Morgan___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Keystone] Mid-Cycle Meetup Dates/Time/Location
I am happy to announce a bunch of the information for the Keystone mid-cycle meetup. The selection of dates, location, etc is based upon the great feedback I received from the earlier poll. Currently the only thing left up in the air is the specific venue and recommended hotel(s). Location: San Antonio, TX Dates: January 19, 20, 21 (~2 weeks prior to Kilo Milestone 2). Venue: TBD (we have a couple options in San Antonio, and will provide an update as soon as it’s all confirmed) Recommended Hotels: TBD (we are also working to get a Hotel discount again like last time, the recommended hotel will be based upon the final venue). I will be keeping the following page: https://www.morganfainberg.com/blog/2014/11/18/keystone-hackathon-kilo/ https://www.morganfainberg.com/blog/2014/11/18/keystone-hackathon-kilo/ up-to-date with hotel recommendations, venue specific details, etc. I expect to have the Venue and Hotel recommendations ready shortly (full RSVP form will be sent out as well once the venue and hotel are confirmed). I look forward to seeing everyone in January! Cheers, Morgan Fainberg___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Contributing to Solum
Hi Devdatta, Hi Keyvan, Great to hear that your team is interested in contributing to Solum. While there is no 'Ideas' page, there is this: https://wiki.openstack.org/wiki/Solum/HighLevelRoadmap Hmmm, surely this is a good breakdown of the milestones, but not understandable from a noob/outsider's POV. I meant something along the lines of http://wiki.opencog.org/w/Ideas The team is currently working on the Juno-3 milestone. In coming weeks we will be discussing the next milestone. If you get a chance, please join us today in the team meeting. It will be at 10.00am CDT in #openstack-meeting-alt channel on chat.freenode.net. At other times you can find us in the solum irc channel (#solum on chat.freenode.net) as well. Nice, thanks. I am personally more of an ancient email-driven guy, but if that's how to connect, I could certainly adapt. Cheers, Keyvan On Tue, Nov 18, 2014 at 2:21 PM, Keyvan Mir Mohammad Sadeghi keyvan.m.sade...@gmail.com wrote: Hi, I am not even sure that I'm posting this in the right place, but the official Solum website was rather sparse on info regarding where to start. As a compact intro, my name is Keyvan, I've been an active OSS developer/admin https://github.com/keyvan-m-sadeghi since 2011, mainly working on the OpenCog project https://github.com/opencog/opencog. I am planning to create a cloud platform, in the long-term. We are a team of 4 ppl, right now we're most interested in Solum, as it'd make a strong ground for our ideas. We all have strong Python skills and the team is willing to set aside around 10 hrs / week for Solum development, initially. I've read the wiki and there doesn't seem to be an 'Ideas' page where I could see a list of projects to be done, best thing I've found so far was the bugs page https://bugs.launchpad.net/solum, but I'm not sure on where to start. We really appreciate if someone could define a small-sized project for us to undertake; that serves both for the purpose of getting to know Solum code more in depth and also set a start for our contribution. Regards, Keyvan -- Keyvan Mir Mohammad Sadeghi MSc AI One has to pay dearly for immortality; one has to die several times while one is still alive. -- Friedrich Nietzsche ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [barbican] Secret store API validation
It seems we need to add some validation to the process Yes, we are planning to add some validation checks in Kilo. I would submit a bug report for this. The big part of the issue is that we need to be clearer about the expected input types to the API as well as the SecretStores. This was a big topic of discussion at the summit. I hope to have a spec out soon, I hope, that will address this issue. -Nate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-dev][Nova] Migration stuck - resize/migrating
Migrate/resize uses scp to copy files back and forth with the libvirt driver. This shouldn’t be necessary with shared storage, but it may still need ssh configured between the user that nova is running as in order to complete the migration. It is also possible that there is a bug in the code path dealing with shared storage, although I would have expected you to see a traceback somewhere. Vish On Nov 11, 2014, at 1:10 AM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, I'm testing our cinder volume driver in the following setup: - 2 nodes, ubuntu, devstack juno (2014.2.1) - shared storage (common backend), our custom software solution + cinder volume on shared storage - 1 instance running on node 1, /instances directory on shared storage - kvm, libvirt (with live migration flags) Live migration of instance between nodes works perfectly. Migrate simply blocks. The instance in in status Resize/Migrate, no errors in n-cpu or n-sch, and it stays like that for over 8 hours (all night). I thought it was copying the disk, but it's a 20GB sparse file with approx. 200 mb of data, and the nodes have 1Gbps link, so it should be a couple of seconds. Any difference between live migration and migration? As i said, we use a shared filesystem-like storage solution so the volume files and the instance files are visible on both nodes, so no data needs copying. I know it's tricky to debug since we use a custom cinder driver, but anyone has any ideas where to start looking? Thanks, Eduard -- Eduard Biceri Matei, Senior Software Developer www.cloudfounders.com | eduard.ma...@cloudfounders.com CloudFounders, The Private Cloud Software Company Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
I think we should also get rid of some nonsenses in the way events are processed by the l2 agent. Carl did something similar for the l3 agent. In the past release cycle I put some patches to avoid event starvation or to prevent the same event to be processed multiple times, but I did not address the root cause of the issue. This is probably already in the etherpad under the bullet ovsdb monitor improvements. It seems the current assignee is Terry, but I guess nobody would mind If I submit a spec for it just to assess what are the point of conflicts with other tasks, and then maybe either I or Terry do the actual work. Regarding the modular l2 agent, I think that was the one item for which the consensus was to defer. Not because it wasn't deemed important. I think the concern here was that it was a major refactoring which pretty much would have blocked all other activities. But I am happy to reconsider or find a strategy to ensure the modular l2 agent could fit into kilo plans. Salvatore On 18 November 2014 19:32, Mohammad Banikazemi m...@us.ibm.com wrote: I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework to make the agent code more modular, avoid code replication across multiple L2 agents, and to make adding new features and writing new agents (if/when necessary) easier. I will be happy to take a stab at writing the blueprint/spec based on that work and what is specified in the etherpad [1]. I had to take a few weeks off from work and therefore had to miss the Summit; This happened right around the time that paying our technical debts was becoming a common phrase in Neutron (for good reasons) and from what I can gather from the etherpad [1] the scope for this effort may have expanded and there are others who have volunteered to work on various aspects of this effort. So, if there are others who want to start the task force by writing this blueprint/spec, that is perfectly fine with me. If not, I will be happy to get that started. Best, Mohammad (banix) [image: Inactive hide details for Carl Baldwin ---11/18/2014 12:19:00 PM---At the recent summit, we held a session about debt repayment]Carl Baldwin ---11/18/2014 12:19:00 PM---At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work w From: Carl Baldwin c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 11/18/2014 12:19 PM Subject: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force -- At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work was identified for the L2 agent. We had a discussion in the Neutron meeting today about bootstrapping that work. The first order of business will be to generate a blueprint specification for the work similar, in purpose, to the one that is under discussion for the L3 agent [3]. I personally am at or over capacity for BP writing this cycle. We need a volunteer to take this on coordinating with others who have been identified on the etherpad for L2 agent work (you know who you are) and other volunteers who have yet to be identified. This task force will use the weekly Neutron meeting, the ML, and IRC to coordinate efforts. But first, we need to bootstrap the task force. If you plan to participate, please reply to this email and describe how you will contribute, especially if you are willing to be the lead author of a BP. I will reconcile this with the etherpad to see where gaps have been left. I am planning to contribute as a core reviewer of blueprints and code submissions only. Carl [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt [2] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html [3] https://review.openstack.org/#/c/131535/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?
AFAIK they are relics. Vish On Nov 13, 2014, at 7:20 AM, Matthew Booth mbo...@redhat.com wrote: There are 3 db apis relating to ProviderFirewallRule: provider_fw_rule_create, provider_fw_rule_get_all, and provider_fw_rule_destroy. Of these, only provider_fw_rule_get_all seems to be used. i.e. It seems they can be queried, but not created. InstanceGroupPolicy doesn't seem to be used anywhere at all. _validate_instance_group_policy() in compute manager seems to be doing something else. Are these undead relics in need of a final stake through the heart, or is something else going on here? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning
Excerpts from Gregory Haynes's message of 2014-10-09 20:32:26 +: Hello TripleO-ers, Last time around there was a lot of feedback that we should plan our mid-cycle metup a lot sooner, so lets do that! I've created a (mostly bare) etherpad here: https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup Note that there are currently no possible venues listed. If you are able to provide a possible venue (Thank you!) please reply and/or add it to the etherpad. I have also listed a few possible Mon-Fri meetup dates. Do not take this as any indication that Mon-Fri is an ideal meetup length or time of week, and feel free to add feedback / combinations of your own. Personally, I felt pretty burned out by Friday last time so maybe Mon-Wed is a better size? A bit of a status update: We are in the works of getting approval for a Seattle location to host our mid-cycle sprint. If you havent already (which is most everyone at this point) please add your preferences to the list of dates at the bottom of the etherpad. More updates to come! Cheers, Greg ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
Hi Carl, Thanks for kicking this off. I am also willing to help as a core reviewer of blueprints and code submissions only. As for the ML2 agent, we all know that for historic reasons Neutron has grown to be not only a networking orchestration project but also a reference implementation that is resembling what some might call an SDN controller. I think that most of the Neutron folks realize that we need to move away from this model and rely on a strong open source SDN alternative; for these reasons, I don't think that pursuing an ML2 agent would be a path we should go down to anymore. It's time and energy that could be more effectively spent elsewhere, especially on the refactoring. Now if the refactoring effort ends up being labelled ML2 Agent, I would be okay with it, but my gut feeling tells me that any attempt at consolidating code to embrace more than one agent logic at once is gonna derail the major goal of paying down the so called agent debt. My 2c Armando ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force
Salvatore Orlando sorla...@nicira.com wrote on 11/18/2014 04:15:35 PM: From: Salvatore Orlando sorla...@nicira.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 11/18/2014 04:19 PM Subject: Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force I think we should also get rid of some nonsenses in the way events are processed by the l2 agent. Carl did something similar for the l3 agent. In the past release cycle I put some patches to avoid event starvation or to prevent the same event to be processed multiple times, but I did not address the root cause of the issue. This is probably already in the etherpad under the bullet ovsdb monitor improvements. It seems the current assignee is Terry, but I guess nobody would mind If I submit a spec for it just to assess what are the point of conflicts with other tasks, and then maybe either I or Terry do the actual work. Regarding the modular l2 agent, I think that was the one item for which the consensus was to defer. Not because it wasn't deemed important. I think the concern here was that it was a major refactoring which pretty much would have blocked all other activities. But I am happy to reconsider or find a strategy to ensure the modular l2 agent could fit into kilo plans. I was not aware of this development regarding Modular L2 Agent. It wasn't obvious from the etherpad but that is understandable. There is so much you can capture in an etherpad. Thanks for clarifying it promptly. Salvatore On 18 November 2014 19:32, Mohammad Banikazemi m...@us.ibm.com wrote: I had done some work on looking at L2 agents and identifying how we may want to go about creating a Modular L2 Agent framework to make the agent code more modular, avoid code replication across multiple L2 agents, and to make adding new features and writing new agents (if/when necessary) easier. I will be happy to take a stab at writing the blueprint/spec based on that work and what is specified in the etherpad [1]. I had to take a few weeks off from work and therefore had to miss the Summit; This happened right around the time that paying our technical debts was becoming a common phrase in Neutron (for good reasons) and from what I can gather from the etherpad [1] the scope for this effort may have expanded and there are others who have volunteered to work on various aspects of this effort. So, if there are others who want to start the task force by writing this blueprint/spec, that is perfectly fine with me. If not, I will be happy to get that started. Best, Mohammad (banix) [image removed] Carl Baldwin ---11/18/2014 12:19:00 PM---At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work w From: Carl Baldwin c...@ecbaldwin.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 11/18/2014 12:19 PM Subject: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force At the recent summit, we held a session about debt repayment in the Neutron agents [1]. Some work was identified for the L2 agent. We had a discussion in the Neutron meeting today about bootstrapping that work. The first order of business will be to generate a blueprint specification for the work similar, in purpose, to the one that is under discussion for the L3 agent [3]. I personally am at or over capacity for BP writing this cycle. We need a volunteer to take this on coordinating with others who have been identified on the etherpad for L2 agent work (you know who you are) and other volunteers who have yet to be identified. This task force will use the weekly Neutron meeting, the ML, and IRC to coordinate efforts. But first, we need to bootstrap the task force. If you plan to participate, please reply to this email and describe how you will contribute, especially if you are willing to be the lead author of a BP. I will reconcile this with the etherpad to see where gaps have been left. I am planning to contribute as a core reviewer of blueprints and code submissions only. Carl [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt [2] http://eavesdrop.openstack.org/meetings/networking/2014/ networking.2014-11-18-14.02.html [3] https://review.openstack.org/#/c/131535/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [Ironic] Proposing new meeting times
On Tue, Nov 18, 2014 at 8:26 PM, Lucas Alvares Gomes lucasago...@gmail.com wrote: On Tue, Nov 18, 2014 at 1:00 AM, Devananda van der Veen devananda@gmail.com wrote: Option #1: alternate between Monday 1900 UTC Tuesday 0900 UTC. I like this because 1900 UTC spans all of US and western EU, while 0900 combines EU and EMEA. Folks in western EU are in the middle and can attend all meetings. http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=24hour=19min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014month=11day=25hour=9min=0sec=0p1=224p2=179p3=78p4=367p5=44p6=33p7=248p8=5 +1 +1 for Option 1. That's far more preferable for me :) -- Michael Davies mich...@the-davies.net Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Undead DB objects: ProviderFirewallRule and InstanceGroupPolicy?
On 11/18/2014 3:28 PM, Vishvananda Ishaya wrote: AFAIK they are relics. Vish On Nov 13, 2014, at 7:20 AM, Matthew Booth mbo...@redhat.com wrote: There are 3 db apis relating to ProviderFirewallRule: provider_fw_rule_create, provider_fw_rule_get_all, and provider_fw_rule_destroy. Of these, only provider_fw_rule_get_all seems to be used. i.e. It seems they can be queried, but not created. InstanceGroupPolicy doesn't seem to be used anywhere at all. _validate_instance_group_policy() in compute manager seems to be doing something else. Are these undead relics in need of a final stake through the heart, or is something else going on here? Thanks, Matt -- Matthew Booth Red Hat Engineering, Virtualisation Team Phone: +442070094448 (UK) GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 ___ 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 If they aren't used/exposed we should remove them. Looks like they were added back in Diablo and hooked in via the ec2 API, some related commits: https://github.com/openstack/nova/commit/d4e7eb818c9f4ec51fd3a88a0e92d557867511d4 https://github.com/openstack/nova/commit/c58a8edb5c282f661d5be361ce68131516c741ba https://github.com/openstack/nova/commit/ed3914eafa7d076fdcc03ee958f77528bcf20603 -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] neutron-drivers meeting moved by 30 minutes
Due to a scheduling conflict, I moved the meeting. It's now from 1530-1630 UTC on Wednesdays [1]. Thanks! Kyle [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] proposal: alternating weekly meeting time [doodle poll created]
Thanks everyone who has responded. I'm going to leave the poll open until the weekend to allow for stragglers to get their times in, and then close it and we can see what the results are. The poll is at https://doodle.com/47h3f35nad62ncnf scroll to the far right to set your timezone. Richard On 12 November 2014 12:45, Richard Jones r1chardj0...@gmail.com wrote: I have set up a doodle poll to let folk enter their preferred times. It's in UTC/GMT (/London time, because doodle) so use something like http://everytimezone.com/ to figure that out :) https://doodle.com/47h3f35nad62ncnf Richard On 11 November 2014 18:46, Matthias Runge mru...@redhat.com wrote: On 11/11/14 08:09, Richard Jones wrote: Hi all, At the summit meetup last week I proposed that the Horizon weekly meeting time alternate between the current time and something more suitable for those of us closer to UTC+10. I'd like to get an indication of the interest in this, and I'll look into getting a second meeting time booked for alternating weeks based on your feedback. As a starting point, I'd like to suggest the times alternate between UTC and 1600 (the current time). Sadly, both times don't work for me. I would propose something like 8 UTC, which should work for most folks located in EU and east, or 18 UTC. Matthias ___ 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
