Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
On 07/03/2015 06:32 AM, Sylvain Bauza wrote: Le 02/07/2015 21:40, Jay Pipes a écrit : On 07/01/2015 12:23 AM, ChangBo Guo wrote: thanks Dan and Jay, we don't need add new scheduler for that :-), what about provide cpu frequency to api /os-hypervisors, that means we can report this value automatically, the value can be used in high level mange tools. Meh, I'm not too big of a fan of the os-hypervisors extension. Actually, one might say I despise that extension :) That said, I suppose it should be possible to include the output of the CPU frequency in the cpu_info field there... Well, IMHO I don't like to have the Hypervisors API to be a Nagios-like view of the hypervisors world and I don't really much benefits of pusing the metrics up to the API. On the other hand, those monitor metrics are already sent as notifications on the bus [1] so a 3rd party tool can easily fetch them without necessarly needing to extend the API. Yeah, the difference here is that CPU frequency really isn't a metric... it's a static thing that doesn't change over time. Which is why I think it's OK to put it in cpu_info. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Liberty FFE Request - Dynamic Policies
Hi Thierry, Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask for. Rectifying: On behalf of the team working on the Dynamic Policies subject, I would like to ask for a *Spec Freeze Exception* in Liberty for it. Thanks, Samuel de Medeiros Queiroz Thierry Carrez wrote: samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] Quobyte Cinder Driver revert?
Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015 + Merge Revert First version of Cinder driver for Quobyte Is this part of some restructuring work, etc. that i did miss? I could not find a gerrit review for this and had no prior information? I did not see any related information when i did my weekly checks of the cinder weekly meeting logs and am confused to find this commit. We're still working on the CI issues discussed on the CI mailing list and am fully aware that we've to get this stably reporting. This is not a removal because of the CI issues? Best regards Silvan Kaiser -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- -- *Quobyte* GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
On 2015-07-03 13:09:08 +0100 (+0100), Neil Jerram wrote: Would you mind checking whether there were still any such errors for my domain, for the second half of yesterday (2nd July) UK time? My admins here think they've fixed something, but I think I'm still missing some Gerrit notification emails, so I'm not convinced myself. Out of 30 delivery attempts from Gerrit to your domain in yesterday's log we saw 7 rejections from your MTA (the most recent at 21:21:38 UTC). So far of the 2 delivery attempts to your domain today both have succeeded, so while I don't see errors I'm afraid the sample size is thus far too small to be confident it's resolved. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?
On 2015-07-03 10:31 AM, Silvan Kaiser wrote: Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.org mailto:jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015 + Merge Revert First version of Cinder driver for Quobyte Is this part of some restructuring work, etc. that i did miss? I could not find a gerrit review for this and had no prior information? I did not see any related information when i did my weekly checks of the cinder weekly meeting logs and am confused to find this commit. I'm not involved in any way with the revert but found those relevant information: http://lists.openstack.org/pipermail/third-party-announce/2015-June/000200.html https://review.openstack.org/#/c/191192/2 -- Mathieu __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] virtual mid-cycle planning
On 2015-07-03 10:07:05 +0100 (+0100), Chris Dent wrote: The Ceilometer virtual mid-cycle will be held next week, the 9th and 10th of July. [...] Annoying but friendly reminder to please add it at https://wiki.openstack.org/wiki/VirtualSprints when you get a moment! -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Network issue with libvirt-xen driver, iptables race
On Fri, Jul 03, 2015 at 03:55:37PM +0100, Anthony PERARD wrote:
On Wed, Jul 01, 2015 at 02:45:13PM +0100, Daniel P. Berrange wrote:
On Tue, Jun 30, 2015 at 03:02:54PM +0100, Anthony PERARD wrote:
Hi all,
We have an issue with the driver libvirt-xen. When a guest is started by
Nova, nova-network is going to do some network setup and call
iptables-{save,restore}, and the Xen toolstack is going to setup the
vif of the guest, via a script, which also update the iptables.
The Xen script is simply calling those commands:
ip link set dev ${dev} down
ip link set dev ${dev} address fe:ff:ff:ff:ff:ff
ip address flush dev ${dev}
brctl addif ${bridge} ${dev}
ip link set dev ${dev} up
iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-in $dev
-j ACCEPT
iptables -I FORWARD -m physdev --physdev-is-bridged --physdev-out
$dev -j ACCEPT
$dev been by default vif$domid.$devid.
Only the call to iptables is an issue and fail fairly often when it looses
the race against iptables-{save,restore}.
It is possible to have Nova asking to run a different script that would
not
call iptables. But that script would need to be store somewhere, in the
nova repo would be best.
Any though on that?
Is `iptables` call necessary for the vif with OpenStack?
If so, can nova-network do the update? Or the script called by the Xen
toolstack could take an OpenStack lock before calling iptables?
Bug report: https://bugs.launchpad.net/nova/+bug/1461642
IIRC, the iptables physdev matches are to deal with the fact that the
kernel default sends all bridge traffic via the net filter layer. This
is arguably a layering violation, because if you're bridging guests at
the network layer, you generally don't expect traffic to be filtered
at the IP layer. Some distros override this kernel default by setting
some sysctls:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
At which point I think the iptables rules you quote should be
redundant.
Thanks for the explanation.
In terms of locking, libvirt uses the '-w' flag when calling iptables
which prevents concurrent execution of iptables. I'm not sure whether
adding -w would be sufficient to deal with your particular case.
Regardless, any time nova invokes iptables, it should use -w
The --wait flag would not work because the call might append between an
OpenStack iptable-{save,restore} calls.
Also, the flag can not be accepted upstream as it is too recent, some
distribution that we care about does not have it.
FYI, libvirt checks to see if the -w flag is available before using
it, and any use in Nova should do the same
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Show attribute is a collection of other attributes or not?
I want to implement this task
3 июля 2015 г. 15:00 пользователь Sergey Kraynev skray...@mirantis.com
написал:
Thank everyone for the good feedback.
If summarize all suggestions:
- I will continue add show as raw output (similar on clients show command
output)
- Also we decided to implement additional functional for get_attr
function, when it get only resource name and returns map with all
attributes (except show).
About second one need volunteer :)
Regards,
Sergey.
On 3 July 2015 at 00:04, Steven Hardy sha...@redhat.com wrote:
On Fri, Jul 03, 2015 at 07:35:18AM +1200, Steve Baker wrote:
On 03/07/15 06:03, Randall Burt wrote:
Maybe use all for all attributes in the schema and use show for
the raw output from the service (as is done today for server and neutron
stuff).
Instead of all, how about allowing a special form of {get_attr:
[resource_name]} with no extra arguments to return a dict of all
attributes?
This would be consistent with how extra arguments traverse attribute
data.
+1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] [infra] issues with beaker/centos7 job
On 07/02/2015 07:23 PM, Colleen Murphy wrote: On Thu, Jul 2, 2015 at 11:40 AM, Jeremy Stanley fu...@yuggoth.org mailto:fu...@yuggoth.org wrote: On 2015-07-02 16:02:32 +0200 (+0200), Alan Pevec wrote: After having a closer look, I see that image has requests 2.7 installed from pypi which overwrites python-requests RPM installation and wreaks havoc when trying to upgrade RPM. I'm not sure why and where is pypi used during the image build but it should not be installed system-wide on RPM system. If really needed, install it in venv. After some deep digging, I think https://review.openstack.org/198082 will solve this (I'll fire up manual image updates once it merges). -- Jeremy Stanley It looks like things are starting to work again. Thanks Ian and Jeremy for your tremendous help. Thanks *a lot* Ian, Jeremy, Alan and Gilles. Packaging issues have been quite a pain for us lately. You help is really appreciated. Colleen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] virtual mid-cycle planning
On Fri, 3 Jul 2015, Jeremy Stanley wrote: On 2015-07-03 10:07:05 +0100 (+0100), Chris Dent wrote: The Ceilometer virtual mid-cycle will be held next week, the 9th and 10th of July. [...] Annoying but friendly reminder to please add it at https://wiki.openstack.org/wiki/VirtualSprints when you get a moment! Does a virtual mid-cycle count? This one is not quite a sprint. It's a bunch of meetings, held on google hangouts (falling back to other things if it is junk), schedule over a two day period with a strict agenda (forthcoming). We won't be using #openstack-sprint nor will we be focusing for a short period of time on a subset of code, bugs, and reviews. However [e]veryone is encouraged to participate. I'm happy to put it on there if it fits, but it's not clear that it does. We have talked about having some related sprints, but those plans haven't solidified yet. And please, if this is what you call annoying, feel free to annoy me any time. The more redundant sharing of info on these kinds of processes the better. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?
Hello again! Ok, now i did find the review [1], sorry i did not earlier. We will solve the CI issues asap in order to provide the requirements to recommit the Quobyte driver. We've been trying to solve the CIs networking issue i wrote about since then but were unable to nail it down completely as we're only a small company and restricted in resources. After the mail from Mike Perez regarding missing reports [2] i had brief contact with him directly via email [3] and once more on the third party mailing list [4]. As i did not receive a message after the replies i did not expect there to be a defined deadline and I did not see information about the impending revert on gerrit, and thus was unable to comment on that. My apologies for that. We're focusing on this with all the team now. Silvan Kaiser [1] https://review.openstack.org/#/c/191192/ [2] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000200.html [3] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000213.html [4] http://lists.openstack.org/pipermail/third-party-announce/2015-June/000214.html 2015-07-03 16:31 GMT+02:00 Silvan Kaiser sil...@quobyte.com: Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015 + Merge Revert First version of Cinder driver for Quobyte Is this part of some restructuring work, etc. that i did miss? I could not find a gerrit review for this and had no prior information? I did not see any related information when i did my weekly checks of the cinder weekly meeting logs and am confused to find this commit. We're still working on the CI issues discussed on the CI mailing list and am fully aware that we've to get this stably reporting. This is not a removal because of the CI issues? Best regards Silvan Kaiser -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- -- *Quobyte* GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules
Kolla Devs as well as the Technical Committee, I wanted to get the TC’s thoughts on this plan of action as we intend to apply for big tent once our Ansible code has completed implementation. If the approach outlined in this email seems like a blocker and we should just start with #4 instead, it would be immensely helpful to know now. The problem: A whole slew of OpenStack modules exist upstream in the Ansible core directory. Kolla wants to use these modules. These files are licensed under the GPLv3. They will be released with Ansible 2.0 but Ansible 2.0 is not yet available. In the meantime we need these modules to execute our system. The repo in question is: https://github.com/ansible/ansible-modules-core The possible solutions: 1. Mordred suggested just merging the code in our repo, but I thought this might trigger license contamination so I am not hot on this idea. 2. Relicense the upstream modules in ASL short term. Mordred tried this but thinks its not possible because of the varied contributors. 3. Fork the repo In question, remove everything except cloud/openstack directory and turn this into a pip installable library. 4. Make a hacky solution that doesn’t use any upstream modules but gets the job done. For the moment we have settled on #3, that is creating a repo here: https://github.com/sdake/kolla-pre-ansible-2-openstack/ And installing these in the deployment system. Once Ansible 2.0 is available, we would deprecate this model, and rely on Ansible 2.0 exclusively. Thoughts or concerns on this approach? Thanks -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] virtual mid-cycle planning
On 2015-07-03 14:54:28 +0100 (+0100), Chris Dent wrote: Does a virtual mid-cycle count? This one is not quite a sprint. It's a bunch of meetings, held on google hangouts (falling back to other things if it is junk), schedule over a two day period with a strict agenda (forthcoming). [...] Given that meatspace mid-cycle events are listed at https://wiki.openstack.org/wiki/Sprints#Liberty_sprints and the VirtualSprints article is linked from the top of that page, it seems entirely appropriate. Though you might still consider use of the #openstack-sprint channel if it's not already overbooked. It's a way to separate the tasks specific to your mid-cycle from the normal goings-on of #openstack-dev or your team channel and could lead to better focus. Entirely optional though! I don't expect the features of a virtual sprint as they're listed on that page are intended to be proscriptive, just descriptive of the virtual sprints we've had so far as a community. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Quobyte Cinder Driver revert?
It was discussed on the mailing list, and at the weekly meeting. Mike had had no response on the issue from the listed contact email, and the CI was reporting failure for every patch for two months On 3 Jul 2015 17:33, Silvan Kaiser sil...@quobyte.com wrote: Hello! I just found the following commit in the cinder log: commit a3f4eed52efce50c2eb1176725bc578272949d7b Merge: 6939b4a e896ae2 Author: Jenkins jenk...@review.openstack.org Date: Thu Jul 2 23:14:39 2015 + Merge Revert First version of Cinder driver for Quobyte Is this part of some restructuring work, etc. that i did miss? I could not find a gerrit review for this and had no prior information? I did not see any related information when i did my weekly checks of the cinder weekly meeting logs and am confused to find this commit. We're still working on the CI issues discussed on the CI mailing list and am fully aware that we've to get this stably reporting. This is not a removal because of the CI issues? Best regards Silvan Kaiser -- Dr. Silvan Kaiser Quobyte GmbH Boyenstr. 41 - 10115 Berlin-Mitte - Germany +49-30-814 591 800 - www.quobyte.comhttp://www.quobyte.com/ Amtsgericht Berlin-Charlottenburg, HRB 149012B Management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender -- *Quobyte* GmbH Hardenbergplatz 2 - 10623 Berlin - Germany +49-30-814 591 800 - www.quobyte.com Amtsgericht Berlin-Charlottenburg, HRB 149012B management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security][Bandit] Bandit gate usage
On 03/07/2015 09:39, Gorka Eguileor gegui...@redhat.com wrote: On Thu, Jul 02, 2015 at 07:09:41PM +, Kelsey, Timothy John wrote: Hello Stackers, A few intrepid projects have started adopting Bandit, an automatic security linter built by the security project, into their gate tests. This is very rewarding to see for those of us who have worked on the project and people with an interest in securing the OpenStack codebase. The list of (known) adopters so far: - Keystone - Keystone-client - Barbican - Anchor - Sahara - Magnum If you know of, or are involved in a project that¹s using Bandit and isn¹t on our list then please let us know, it would be great to hear your feedback. If you would like to begin using it then check out our wiki for instructions here [1]. If you have no idea what this Bandit thing is then perhaps this presentation from the Vancouver summit might be interesting to you [2]. A Bandit gate job can be configured either as an experimental or none-voting job, so if your interested in trying it out you can give it a go and decide if its a good fit for your project before fully committing. Hi, At Cinder we are adding [1] basic bandit configuration for high and medium severity results as a tox option, but not running it by default for now. Cheers, Gorka Thanks for letting us know Gorka, I¹m pleased bandit is on the Cinder radar. I hope it¹s working out for you, please reach out if you have any suggestions or concerns with the tool. [1]: https://review.openstack.org/#/c/179568/ Bandit is regularly discussed in the Security Project IRC meetings and feedback is very welcome. If you have questions or suggestions then feel free to drop in or reply here. [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit [2] https://www.youtube.com/watch?v=hxbbpdUdU_k Many thanks -- Tim Kelsey OpenStack Security member _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Requirements][Routes][Senlin] Which version of Routes to use now?
The recent change to global-requirements is excluding both 2.0 and 2.1 version of Routes. That is forcing us to use Routes 1.13. However, Routes 1.13 cannot pass py34 tests due to errors like this: /home/jenkins/workspace/gate-senlin-python34/.tox/py34/lib/python3.4/site-packages/routes/route.py, line 101, in _setup_route for key, val in self.reqs.iteritems(): AttributeError: 'dict' object has no attribute 'iteritems' Any suggestions on a workaround? Thanks. Regards, Qiming __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?
Hi Oslo and Neutron folks, Why is policy_dirs option deprecated in oslo.policy? In Neutron we have multiple repositories which consist of Neutron services and we would like to maintain policy.json separately. policy_dirs option looks useful for this purpose. == Detail == Neutron project now consists of several repositories and they are imported when neutron-server runs. There are cases where it makes sense that each repository manages its policy.json and the neutron-server wants to load all related policy.json files. - advanced services have separate repositories and they evolve their API independently - vendor plugins/drivers in separate repositories (can) have vendor-specific extension API. (It is not a good thing from the point of the current API discussion, but we have now.) An easy way is to put all related policy.json into a single directory lile /etc/neutron/policy.d and specify this to policy_dirs option. Looking at oslo.policy (oslo_policy/opts), we have a comment policy_dirs option will be removed in M cycle. I read the commit message where this message was added but I am not sure why it is a problem. I would like to know the reason of the deprecation and discuss how we can handle our use cases. Thanks, Akihiro __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Requirements][Routes][Senlin] Which version of Routes to use now?
Yes. Use environment markers to specify= 2 for portion 2.7 and uncapped for 3.4. On 4 Jul 2015 2:19 pm, Qiming Teng teng...@linux.vnet.ibm.com wrote: The recent change to global-requirements is excluding both 2.0 and 2.1 version of Routes. That is forcing us to use Routes 1.13. However, Routes 1.13 cannot pass py34 tests due to errors like this: /home/jenkins/workspace/gate-senlin-python34/.tox/py34/lib/python3.4/site-packages/routes/route.py, line 101, in _setup_route for key, val in self.reqs.iteritems(): AttributeError: 'dict' object has no attribute 'iteritems' Any suggestions on a workaround? Thanks. Regards, Qiming __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Friday 1900UTC etherpad.openstack.org downtime for DB maintenance
On Tue, Jun 30, 2015, at 04:16 PM, Clark Boylan wrote: Hello, The Infra team will be taking etherpad.openstack.org offline this Friday (July 3rd) at 1900UTC to upgrade the database instance that backs this service. This upgrade will allow us to convert the utf8 character set in the db to one supporting 4 byte characters fixing a major bug discovered during the last summit. Expect total downtime to be about half an hour. This work has been completed and the etherpad.openstack.org service is up and running once again. Total downtime was ~45 minutes. Let us know if you notice any new and exciting odd behavior from etherpad.openstack.org. Thank you, Clark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Kolla] Essential to sign by July 9th - Kolla-Palooza midcycle event!!
Please note a correction, the dinner is the night of July 28th at 7pm, not July 27th. My apologies. Regards -steve From: Steven Dake std...@cisco.commailto:std...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, July 2, 2015 at 6:39 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Kolla] Essential to sign by July 9th - Kolla-Palooza midcycle event!! Hey community folks! The Kolla team is having a mid-cycle event in San Jose, CA. Coffee is provided throughout the day (I believe, but not certain on this point), and lunch, soda, water are provided at lunch time. An RSVP dinner is provided the night of July 27th at 7 PM so food costs should be minimal. If you plan to attend in person, please book your hotel and flight reservations quickly. Silicon Valley prices are quickly increasing and many companies have a 14 day window (July 13th) for booking travel arrangements. We can handle folks that walk in at the last moment, but for the RSVP dinner, please RSVP by July 9th so we can get an accurate count for organizing a dinner. The eventbrite information is at the bottom of this web page: https://wiki.openstack.org/wiki/Sprints/KollaLibertySprint __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] How to handle security issues in external repos?
In the Liberty cycle Neutron is mandating the splitting out of third-party plugins and drivers into separate repositories, see [1]. These external repositories will be managed by the maintainers of the code, who are independent from the neutron core maintainers. The question now arises about what to do when a security issue is found in such an external repository that integrates with Neutron. - How should such security issues be managed? - Should the OpenStack security team be involved? - Does a CVE need to be filed? - Do the maintainers need to publish OSSN or equivalent documents? - Anything else to consider here? [1] https://review.openstack.org/187267 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules
Please consider forwarding this to the legal list. The gpl is a bit c specific and can be tricky to apply to other languages, but I would expect the modules under gplv3 to require all others in process to be gpl compatable, which apache should be, but will prevent any nonopen to be used. That might be ok, but something to carefully consider. Thanks, Kevin From: Steven Dake (stdake) Sent: Friday, July 03, 2015 11:53:00 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Greg DeKoenigsberg Subject: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules Kolla Devs as well as the Technical Committee, I wanted to get the TC’s thoughts on this plan of action as we intend to apply for big tent once our Ansible code has completed implementation. If the approach outlined in this email seems like a blocker and we should just start with #4 instead, it would be immensely helpful to know now. The problem: A whole slew of OpenStack modules exist upstream in the Ansible core directory. Kolla wants to use these modules. These files are licensed under the GPLv3. They will be released with Ansible 2.0 but Ansible 2.0 is not yet available. In the meantime we need these modules to execute our system. The repo in question is: https://github.com/ansible/ansible-modules-core The possible solutions: 1. Mordred suggested just merging the code in our repo, but I thought this might trigger license contamination so I am not hot on this idea. 2. Relicense the upstream modules in ASL short term. Mordred tried this but thinks its not possible because of the varied contributors. 3. Fork the repo In question, remove everything except cloud/openstack directory and turn this into a pip installable library. 4. Make a hacky solution that doesn’t use any upstream modules but gets the job done. For the moment we have settled on #3, that is creating a repo here: https://github.com/sdake/kolla-pre-ansible-2-openstack/ And installing these in the deployment system. Once Ansible 2.0 is available, we would deprecate this model, and rely on Ansible 2.0 exclusively. Thoughts or concerns on this approach? Thanks -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] How to handle security issues in external repos?
On 2015-07-03 22:01:38 +0200 (+0200), Henry Gessau wrote: [...] The question now arises about what to do when a security issue is found in such an external repository that integrates with Neutron. - How should such security issues be managed? The OpenStack Vulnerability Management Team (VMT) follows a documented process[1] which can basically be reused by any project-team when needed. - Should the OpenStack security team be involved? The OpenStack VMT directly oversees vulnerability reporting and disclosure for a subset[2] of OpenStack source code repositories. However we're still quite happy to answer any questions you might have about vulnerability management for your own projects even if they're not part of that set. Feel free to reach out to us in public or in private. Also, the VMT is an autonomous subgroup of the much larger OpenStack Security project-team[3]. They're a knowledgeable bunch and quite responsive if you want to get their opinions or help with security-related issues (vulnerabilities or otherwise). - Does a CVE need to be filed? It can vary widely. If a commercial distribution such as Red Hat is redistributing a vulnerable version of your software then they may assign one anyway even if you don't request one yourself. Or the reporter may request one; the reporter may even be affiliated with an organization who has already assigned/obtained a CVE before they initiate contact with you. - Do the maintainers need to publish OSSN or equivalent documents? OpenStack Security Advisories (OSSA) are official publications of the OpenStack VMT and only cover VMT-supported software. OpenStack Security Notes (OSSN) are published by editors within the OpenStack Security project-team on more general security topics and may even cover issues in non-OpenStack software commonly used in conjunction with OpenStack, so it's at their discretion as to whether they would be able to accommodate a particular issue with an OSSN. However, these are all fairly arbitrary labels, and what really matters in the grand scheme of things is that vulnerabilities are handled seriously, fixed with due urgency and care, and announced widely--not just on relevant OpenStack mailing lists but also preferably somewhere with broader distribution like the Open Source Security mailing list[4]. The goal is to get information on your vulnerabilities, mitigating measures and fixes into the hands of the people using your software in a timely manner. - Anything else to consider here? [...] The OpenStack VMT is in the process of trying to reinvent itself so that it can better scale within the context of the Big Tent. This includes making sure our policy/process documentation is more consumable and reusable even by project-teams working on software outside the scope of our charter. It's a work in progress, and any input is welcome on how we can make this function well for everyone. [1] https://security.openstack.org/vmt-process.html [2] https://wiki.openstack.org/wiki/Security_supported_projects [3] http://governance.openstack.org/reference/projects/security.html [4] http://oss-security.openwall.org/wiki/mailing-lists/oss-security -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Barbican : Regarding the Tempest Tests for Barbican
Thanks Mathew for providing the updated information :) Thanks and Regards, Asha Seshagiri On Thu, Jul 2, 2015 at 2:32 PM, Matthew Treinish mtrein...@kortar.org wrote: On Wed, Jul 01, 2015 at 03:30:55PM -0500, Douglas Mendiz?bal wrote: Hi Asha, The blueprint you linked for Tempest is over a year old. I think it pre-dates the Tempest team's decision to stop putting all project tests in the same repo. I believe the spec is obsolete, but someone from the Tempest team can correct me if I'm wrong. Yes, that blueprint was quite old and if you look at the history for it there was nary a patch submitted against it. So, I guess whoever was planning to do that work never got around to it. The reason the BP was sitting around for so long is mostly because I'm terrible at the lp maintenance. I apologize for any confusion that caused. I took some time this afternoon to go through open blueprints and specs repo to clean things up. I marked this particular BP as obsolete now to reflect it's actual state. You're correct in your assertion that we will be moving to a limited set of projects for which tests are maintained in the tempest tree. The plan is to have everything else that wants to use tempest for testing but doesn't fit into that set of projects leverage tempest-lib and the plugin interface which is currently in progress. However, until all the pieces are in place, including docs to explain this all, we're not blocking additions for projects that are currently in-tree but outside that set. (which does not include barbican because nothing was ever added) -Matt Treinish The automated tests that validate the API are the Functional Tests I linked in my earlier email. - - Douglas Mendiz?bal On 7/1/15 3:22 PM, Asha Seshagiri wrote: Hi Douglas , Are there any Automated Test cases created for validating the Barbican APIs. Thanks and Regards, Asha Seshagiri On Wed, Jul 1, 2015 at 3:12 PM, Asha Seshagiri asha.seshag...@gmail.com mailto:asha.seshag...@gmail.com wrote: Thanks Douglas for your response and appreciate for pointing me to the right link I was talking about the tempest tests to validate the Barbican APIs Please find the spec[1] and blue print link [2] for the same . [1]http://specs.openstack.org/openstack/qa-specs/specs/barbican-api-te sts.html [2]https://blueprints.launchpad.net/tempest/+spec/add-basic-tests-for-ba rbican Are above specs and blueprint have become void for Barbican? Now I could use the link sent by you for validating the APIs Thanks and Regards, Asha Seshagiri On Wed, Jul 1, 2015 at 2:32 PM, Douglas Mendiz?bal douglas.mendiza...@rackspace.com mailto:douglas.mendiza...@rackspace.com wrote: Hi Asha, I'm not sure what you mean by tempest tests. If you're looking for Functional Tests for Barbican, then you can find them in the functionaltests directory [1] inside the Barbican repo. We have no intentions of adding Barbican specific tests to the Tempest repo. It's my understanding that Tempest is moving away from one monolithic repository into a modular approach using tempest-lib. - Douglas Mendiz?bal [1] http://git.openstack.org/cgit/openstack/barbican/tree/functionaltest s On 7/1/15 2:12 PM, Asha Seshagiri wrote: Hi All , Has anyone done the Tempest tests for Barbican API Any help would be highly appreciated. -- /Thanks and Regards,/ /Asha Seshagiri/ -- /Thanks and Regards,/ /Asha Seshagiri/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks and Regards,* *Asha Seshagiri* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules
From: Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, July 3, 2015 at 12:28 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Greg DeKoenigsberg g...@ansible.commailto:g...@ansible.com Subject: Re: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules Please consider forwarding this to the legal list. The gpl is a bit c specific and can be tricky to apply to other languages, but I would expect the modules under gplv3 to require all others in process to be gpl compatable, which apache should be, but will prevent any nonopen to be used. That might be ok, but something to carefully consider. Kevin, I don’t grok your concern. I don’t care about non-open source implementations of configuration bits for Kolla. I care about GPL license contamination within the Kolla code base, which placing the libraries in a third party downloadable library package solves (#3). This is one of many reasons distros don’t permit bundled libraries. Regards -steve Thanks, Kevin From: Steven Dake (stdake) Sent: Friday, July 03, 2015 11:53:00 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Greg DeKoenigsberg Subject: [openstack-dev] [kolla][tc] Plans for using Pre-2.0 Ansible modules Kolla Devs as well as the Technical Committee, I wanted to get the TC’s thoughts on this plan of action as we intend to apply for big tent once our Ansible code has completed implementation. If the approach outlined in this email seems like a blocker and we should just start with #4 instead, it would be immensely helpful to know now. The problem: A whole slew of OpenStack modules exist upstream in the Ansible core directory. Kolla wants to use these modules. These files are licensed under the GPLv3. They will be released with Ansible 2.0 but Ansible 2.0 is not yet available. In the meantime we need these modules to execute our system. The repo in question is: https://github.com/ansible/ansible-modules-core The possible solutions: 1. Mordred suggested just merging the code in our repo, but I thought this might trigger license contamination so I am not hot on this idea. 2. Relicense the upstream modules in ASL short term. Mordred tried this but thinks its not possible because of the varied contributors. 3. Fork the repo In question, remove everything except cloud/openstack directory and turn this into a pip installable library. 4. Make a hacky solution that doesn’t use any upstream modules but gets the job done. For the moment we have settled on #3, that is creating a repo here: https://github.com/sdake/kolla-pre-ansible-2-openstack/ And installing these in the deployment system. Once Ansible 2.0 is available, we would deprecate this model, and rely on Ansible 2.0 exclusively. Thoughts or concerns on this approach? Thanks -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Best practices for the DB maintanence in production
On 03 Jul 2015, at 12:14, Lingxian Kong anlin.k...@gmail.com wrote: What do you think if we add a script(may be under tools or cmd package) to help doing this? What script do you mean? To launch a separate clean-up component. I see that, first of all, it’s a subsystem of Mistral consisting at least of things like various eviction policies (people may want to cleanup differently) and an active manager that implements the logic, maybe there should be stat collector if we want to evaluate the work of this cleanuper. So, IMO, it should be a package which most likely contain several modules and classes and then we may want to have a script to launch it separately if needed. Or it can start automatically say within an engine instance. Anyway, let’s not run ahead of train and gather what we need to do first. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Liberty FFE Request - Dynamic Policies
samuel wrote: [...] On behalf of the team working on the Dynamic Policies subject, I would like to ask for a Feature Freeze Exception in Liberty for it. Liberty Feature Freeze is on September 3rd, so I doubt you need a feature freeze exception at this time. I suspect that would be a spec freeze exception or some other Keystone-specific freeze exception ? https://wiki.openstack.org/wiki/FeatureFreeze -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glancel] why does Glance keep the deleted membership of image ?
Hi Glance team, The question is from a bug https://bugs.launchpad.net/glance/+bug/1462315, If an image-member is deleted, then create it again with the same parameters, glance searches db to see if there is already an existing one, but the result doesn't include the record which was marked as deleted, glance will try to create a new one with the same parameters, it works well on mysql. But it is failed on DB2 with SQL0803N error. The root cause is that DB2 constraint is more restricted than mysql. For db2, the columns under unique constrains should be NOT NULL, currently the column deleted_at which is one of unique constrain of image_members is nullable. A possible solution is to alter it to not null in migration. that means we have to insert a default timestamp value for the new created image-member, an active member with a no-blank timestamp for deleted_at seems very confusing. Another fix is: we may check all existing image-member records including the deleted image-member before create image-member, then update it if it exists, otherwise create a new one, that is proposed in https://review.openstack.org/#/c/190895/ I'm wondering why can't we use only one record to maintain the member-ship between a pair of image and tenant. Maybe there is some other consideration, I'd like to know more. Thanks. Best regards, LongQuan__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Security][Bandit] Bandit gate usage
On Thu, Jul 02, 2015 at 07:09:41PM +, Kelsey, Timothy John wrote: Hello Stackers, A few intrepid projects have started adopting Bandit, an automatic security linter built by the security project, into their gate tests. This is very rewarding to see for those of us who have worked on the project and people with an interest in securing the OpenStack codebase. The list of (known) adopters so far: - Keystone - Keystone-client - Barbican - Anchor - Sahara - Magnum If you know of, or are involved in a project that’s using Bandit and isn’t on our list then please let us know, it would be great to hear your feedback. If you would like to begin using it then check out our wiki for instructions here [1]. If you have no idea what this Bandit thing is then perhaps this presentation from the Vancouver summit might be interesting to you [2]. A Bandit gate job can be configured either as an experimental or none-voting job, so if your interested in trying it out you can give it a go and decide if its a good fit for your project before fully committing. Hi, At Cinder we are adding [1] basic bandit configuration for high and medium severity results as a tox option, but not running it by default for now. Cheers, Gorka [1]: https://review.openstack.org/#/c/179568/ Bandit is regularly discussed in the Security Project IRC meetings and feedback is very welcome. If you have questions or suggestions then feel free to drop in or reply here. [1] https://wiki.openstack.org/wiki/Security/Projects/Bandit [2] https://www.youtube.com/watch?v=hxbbpdUdU_k Many thanks -- Tim Kelsey OpenStack Security member __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Nova API meeting
Hi, We have weekly Nova API meeting this week. The meeting is being held tomorrow Friday UTC1200. In other timezones the meeting is at: EST 08:00 (Fri) Japan 21:00 (Fri) China 20:00 (Fri) United Kingdom 13:00 (Fri) The proposed agenda and meeting details are here: https://wiki.openstack.org/wiki/Meetings/NovaAPI Please feel free to add items to the agenda. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Best practices for the DB maintanence in production
What do you think if we add a script(may be under tools or cmd package) to help doing this? On Thu, Jul 2, 2015 at 7:59 PM, ELISHA, Moshe (Moshe) moshe.eli...@alcatel-lucent.com wrote: Thanks, Renat. I also believe the right place to do it is in Mistral. I will create a blueprint and we will discuss the details in the spec. Thanks. *From:* Renat Akhmerov [mailto:rakhme...@mirantis.com] *Sent:* יום ה 02 יולי 2015 12:34 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [mistral] Best practices for the DB maintanence in production Hi Elisha, Currently Mistral doesn’t support any expiration policies for workflow/task/action runtime objects. It keeps them forever until someone deletes them manually. I see the following ways of addressing your need: - Implement some cleanup component within Mistral (how to call it?) using its Scheduler component to periodically query and delete objects based on a criteria provided in a config. - Just implement something on top of Mistral API to do the same. The cons of this approach is that Mistral now doesn’t provide any flexible mechanism to do criteria-based search of its objects. There’s an adjacent BP for that [1]. Generally, there’s a number of things in Mistral API we are not satisfied with and we’ve been planning to design and suggest API v3 for Mistral to support those features (don’t confuse with DSL v3, there’s no plan for now to implement a new backwards incompatible DSL). So this option may not be effective from performance perspective. I think it deserves its own blueprint so that we can discuss nuances. [1] https://blueprints.launchpad.net/mistral/+spec/mistral-items-filtering Renat Akhmerov @ Mirantis Inc. On 02 Jul 2015, at 13:37, ELISHA, Moshe (Moshe) moshe.eli...@alcatel-lucent.com wrote: Hey, We are planning to use Mistral in production in the next few months. We noticed that having even a simple workflow with a cron-trigger (For example monitor and heal workflow) can create large amounts of data in the DB (MariaDB). Does Mistral have a mechanism / configuration of automatic deletion of old executions? What is the best practice to handle this type of challenge? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Regards!* *---* *Lingxian Kong* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] db migration for vendor extensions
On Thu, Jul 2, 2015 at 6:23 PM, Henry Gessau ges...@cisco.com wrote: On Thu, Jul 02, 2015, Fawad Khaliq fa...@plumgrid.com wrote: After Neutron core and vendor code decomposition [1], it was decided to keep db migration scripts in Neutron repo. I was wondering if any of the networking-* project owners figured out an alternative to this approach where DB migration can reside in networking-* repositories instead. As far as DB models are concerned, keeping them in networking-* is simple. I plan to introduce some extensions and it would ideal if DB migration and DB models live out of Neutron repository. Any suggestions for addressing this? Anyone has a working mechanism? Neutron's contributing devref is being updated to include information about this. Please participate in the review [2] and let us know if there is anything you feel is missing or if it can be explained better. [2] https://review.openstack.org/187267 Thanks Henry. I will definitely add my comments. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] virtual mid-cycle planning
On Fri, 26 Jun 2015, Chris Dent wrote: Ceilometer contributors and other interested parties, To keep people in the loop: The Ceilometer virtual mid-cycle will be held next week, the 9th and 10th of July. The schedule is being worked out. The topics that will be covered include: * Getting Gnocchi to a state of ProductionReady™ * Schematisation of notifications * Requirements to make the split of alarming into own repo effective * Requirements to make the split of collecting into own repo effective * Plans for handling deletion or deprecation of old from repo splits * Event-based alarming * Exploring what an APIv3 will mean * Getting a move on with in-tree functional testing The timetable will be available early next week but the overall picture is that the window of events will be in the range of early morning to late evening Euro-time. Some topics will have two sessions, one on each day. The hosting technology plan is to start with Hangouts and then fall back to Bluejeans and then IRC as each inevitably fails... Everyone is welcome. More details early next week. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] ALL dependencies pinned in devstack-gate now
On 3 July 2015 at 21:01, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: I want to give an update on http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html - we've just passed a critical milestone there, and this affects how everyone updates requirements. As of a few minutes ago devstack-gate landed the change to set USE_CONSTRAINTS=True. What this means is that the file http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt is now used to determine the version of every dependency that is present in it. Great to see progress here ! [...] Now, the things you have to remember as developers: * If you are adding a new requirement you should also add it to upper-constraints.txt with an exact pin. * If you are raising a minimum version of a requirement, you need to also raise it in upper-constraints.txt. Three questions: - Do you plan to update openstack/requirements README.rst to explain upper-constraints.txt, and how it should be modified in parallel to global-requirements.txt from now on ? Naturally. It already touches on upper-constraints.txt but a full manual is yet to be written. - What should we do with existing requirements reviews ? Reject them if they don't come with associated upper-constraints changes ? Check if the upper-constraints is compatible ? Recheck them so that a magic test is run on them ? A recheck is sufficient, if its incompatible the unittests will fail (openstack_requirements/tests/test_integration.py) - Does that (or should that) also affect stable/kilo and stable/juno ? (there is no upper-constraints there) No, and since the disruption of a new pbr and associated minimum versions throughout stable would be huge, I've no plans to backport it. If folk wanted to (e.g. if stable suffers from lots of firedrills even with the caps we added last time) I can throw up some patches and we can see about it: but its a big effort requiring point releases of /everything/ (because of the pbr version issue). -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] ALL dependencies pinned in devstack-gate now
On 3 July 2015 at 10:17, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 21:01, Thierry Carrez thie...@openstack.org wrote: SNIP - Does that (or should that) also affect stable/kilo and stable/juno ? (there is no upper-constraints there) No, and since the disruption of a new pbr and associated minimum versions throughout stable would be huge, I've no plans to backport it. If folk wanted to (e.g. if stable suffers from lots of firedrills even with the caps we added last time) I can throw up some patches and we can see about it: but its a big effort requiring point releases of /everything/ (because of the pbr version issue). At the moment, it seems that additional point releases need to be created on-demand - but the situation does seem better than it did a year ago. Is it less effort to do this across the board, once for all stable/* or continue the current process? Long term, we'll benefit from this on stable/liberty - but defining a process for the old world is probably useful. Thanks -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] ALL dependencies pinned in devstack-gate now
Robert Collins wrote: I want to give an update on http://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html - we've just passed a critical milestone there, and this affects how everyone updates requirements. As of a few minutes ago devstack-gate landed the change to set USE_CONSTRAINTS=True. What this means is that the file http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt is now used to determine the version of every dependency that is present in it. Great to see progress here ! [...] Now, the things you have to remember as developers: * If you are adding a new requirement you should also add it to upper-constraints.txt with an exact pin. * If you are raising a minimum version of a requirement, you need to also raise it in upper-constraints.txt. Three questions: - Do you plan to update openstack/requirements README.rst to explain upper-constraints.txt, and how it should be modified in parallel to global-requirements.txt from now on ? - What should we do with existing requirements reviews ? Reject them if they don't come with associated upper-constraints changes ? Check if the upper-constraints is compatible ? Recheck them so that a magic test is run on them ? - Does that (or should that) also affect stable/kilo and stable/juno ? (there is no upper-constraints there) -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] ALL dependencies pinned in devstack-gate now
Robert Collins wrote: On 3 July 2015 at 21:01, Thierry Carrez thie...@openstack.org wrote: [...] - Does that (or should that) also affect stable/kilo and stable/juno ? (there is no upper-constraints there) No, and since the disruption of a new pbr and associated minimum versions throughout stable would be huge, I've no plans to backport it. If folk wanted to (e.g. if stable suffers from lots of firedrills even with the caps we added last time) I can throw up some patches and we can see about it: but its a big effort requiring point releases of /everything/ (because of the pbr version issue). Since caps were only placed on OpenStack libraries, I still expect quite a lot of firedrills on stable/juno and stable/kilo. But there is a cost/benefit tradeoff there, and you know better than me how painful backporting this would be. I guess as long as there is light at the end of the tunnel (i.e. stable/liberty benefits from the change), we get the future covered. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [mistral] Best practices for the DB maintanence in production
OK, Renat, I see, thanks for clarification. Let's discuss it together after the blueprint is proposed. On Fri, Jul 3, 2015 at 4:41 PM, Renat Akhmerov rakhme...@mirantis.com wrote: On 03 Jul 2015, at 12:14, Lingxian Kong anlin.k...@gmail.com wrote: What do you think if we add a script(may be under tools or cmd package) to help doing this? What script do you mean? To launch a separate clean-up component. I see that, first of all, it’s a subsystem of Mistral consisting at least of things like various eviction policies (people may want to cleanup differently) and an active manager that implements the logic, maybe there should be stat collector if we want to evaluate the work of this cleanuper. So, IMO, it should be a package which most likely contain several modules and classes and then we may want to have a script to launch it separately if needed. Or it can start automatically say within an engine instance. Anyway, let’s not run ahead of train and gather what we need to do first. Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Regards!* *---* *Lingxian Kong* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] [Nova] Do we really need to use rabbit_ha_queues parameter?
Hi all, I have updated puppet manifests for all OpenStack components to fix the logic of configuration of rabbit_ha_queues parameter [1] but Nova puppet unit tests failed because these tests expect that we will use rabbit_ha_queues=True for one-controller-node installations [2], [3]. Do we have some bugs in Nova which require to use rabbit_ha_queues even for installation with only one OpenStack controller node? Can we just fix unit tests or we have some reasons to use rabbit_ha_queues=True? Probably, we can use rabbit_ha_queues=True by default for any deployments? Thank you! [1] https://review.openstack.org/#/c/197013/ [2] http://logs.openstack.org/13/197013/3/check/gate-puppet-nova-puppet-unit-3.3/df55e9e/console.html [3] http://paste.openstack.org/show/338209/ -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla] Providing image specific build info
All, As part of the install-from-source blueprint, I'm proposing a basic script that can fetch tarballs in various ways, the result of which is installed as part of the image build. This script is for review here: https://review.openstack.org/#/c/197919/ This requires a couple of variables, most of which can be provided sane defaults. Defaults for some info can't be reasonably determined though, so my question is what peoples preferences are on how to best represent this info. Examples include the CLONE_FROM var (git url to clone a repo from), or whether the component should be built from source at all, e.g. keystone should be built from source but rabbitmq likely not. One possible method is to include a .builddefaults file in each image dir, which specifies this kind of image specific build info, but can still be overridden by users in buildconfs. Another would be to have this same info in a top level config file, which would keep the info together and easier to find and update. Please let me know if you have thoughts or preferences on this to save on review cycles implementing the wrong one. Best Regards, -Paul __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?
Boris, thanks for an explanation! I will take a closer look at the cover.sh script. On Fri, Jul 3, 2015 at 12:07 AM, Boris Pavlovic bpavlo...@mirantis.com wrote: Anastasia, because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. This job compares amount of non covered lines (before and after patch). If you just remove code there will be less lines that should be covered so amount of non covered lines will be less or the same (if everything was covered before) Fixing typos in docstrings won't introduce new lines. Btw job allows you to introduce N (few) new lines that are not covered by unit tests that are uncovered in some cases. Best regards, Boris Pavlovic On Thu, Jul 2, 2015 at 10:46 AM, Anastasia Kuznetsova akuznets...@mirantis.com wrote: Hi Timur, Generally I think that it is a good idea to have a gate that will check whether new code is covered by unit tests or not. But I am not sure that this gate should be voting (if I understand you correct), because new patch may not be just a new code, committer may delete something or fix typos in docsting, etc. On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hi all, I suggest to add CI job which will check the unit tests coverage for Sahara repository and will set -1 for commits with new code and without unit tests (if we have some degradation of tests coverage). This job successfully works for Rally project and it helps to organize the right code development process when developers write new unit tests for new functionality. we can just copy this job from Rally and start to use it for Sahara: Coverage control script: https://github.com/openstack/rally/blob/master/tests/ci/cover.sh Configuration file for coverage plugin (to exclude code which shouldn't be affected): https://github.com/openstack/rally/blob/master/.coveragerc Example of job in infra repository: https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088 I expect that it will help to increase the tests coverage by unit tests. Do we have any objections? -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Anastasia Kuznetsova __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] ALL dependencies pinned in devstack-gate now
On 3 July 2015 at 21:25, Dave Walker em...@daviey.com wrote: On 3 July 2015 at 10:17, Robert Collins robe...@robertcollins.net wrote: On 3 July 2015 at 21:01, Thierry Carrez thie...@openstack.org wrote: SNIP - Does that (or should that) also affect stable/kilo and stable/juno ? (there is no upper-constraints there) No, and since the disruption of a new pbr and associated minimum versions throughout stable would be huge, I've no plans to backport it. If folk wanted to (e.g. if stable suffers from lots of firedrills even with the caps we added last time) I can throw up some patches and we can see about it: but its a big effort requiring point releases of /everything/ (because of the pbr version issue). At the moment, it seems that additional point releases need to be created on-demand - but the situation does seem better than it did a year ago. Is it less effort to do this across the board, once for all stable/* or continue the current process? Long term, we'll benefit from this on stable/liberty - but defining a process for the old world is probably useful. Right - so if you look at stable kilo its largely uncapped. I'd still expect issues there. Like I say, its doable, and I'm happy to prep patches, but there's an awful lot of repos to update, unless we have definite buy-in I'd rather not start. Also, we should wait until we've bedded down all the remaining issues in master, because then we only have one patch per thing to backport. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] schedule instance based on CPU frequency ?
Le 02/07/2015 21:40, Jay Pipes a écrit : On 07/01/2015 12:23 AM, ChangBo Guo wrote: thanks Dan and Jay, we don't need add new scheduler for that :-), what about provide cpu frequency to api /os-hypervisors, that means we can report this value automatically, the value can be used in high level mange tools. Meh, I'm not too big of a fan of the os-hypervisors extension. Actually, one might say I despise that extension :) That said, I suppose it should be possible to include the output of the CPU frequency in the cpu_info field there... Well, IMHO I don't like to have the Hypervisors API to be a Nagios-like view of the hypervisors world and I don't really much benefits of pusing the metrics up to the API. On the other hand, those monitor metrics are already sent as notifications on the bus [1] so a 3rd party tool can easily fetch them without necessarly needing to extend the API. HTH, -Sylvain [1] http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/resource_tracker.py?id=49873d8f6dff651cd83ff10ad5491a04286783d9#n364 -jay 2015-07-01 2:58 GMT+08:00 Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com: On 06/30/2015 02:42 AM, ChangBo Guo wrote: CPU frequency is an import performance parameter, currently nova drivers just report cpu_info without frequency. we stored the compute node cpu_info in database with colum compute_nodes.cpu_info, we can add the frequency easily. The usage of cpu frequency I can think is used to schedule to meet applications which need high frequency. add a frequency based filter ? if we need this , I would like to propose a spec for this . There are two steps to leverage cpu frequency: 1. report cpu frequency and record the value, nova hypervisor-show will include the value . 2. filter compute nodes based cpu frequency. add a new scheduler filter to do that before I start to do these stuff. I would like to your input . Do we need leverage CPU frequency in Nova ? if yes, do we need a new filter or leverage existing filter to use frequency ? Like Dan B, I question whether CPU frequency really is a useful metric for scheduling decisions. That said, it is already possible to use CPU frequency in the MetricsWeigher scheduler weigher. The compute monitor plugin system is currently being overhauled [1], but the functionality to monitor CPU-related metrics already exists in Nova and can be enabled by doing the following in your nova-compute nova.conf: compute_monitors = ComputeDriverCPUMonitor Note that with the refactoring of the monitoring plugin interface, the above option will change due to using stevedore to load monitor extensions: compute_monitors = nova.compute.monitors.cpu.virt_driver:Monitor In your Nova scheduler nova.conf, you will need to add the following in the [metrics] section of the file: weights_setting = cpu.frequency=10.0 Again, I'm not saying that the above will result in any appreciable enhancement to the scheduler's decision-making, but it will do what you're trying to accomplish :) Best, -jay [1] https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1468012,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- ChangBo Guo(gcb) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] The sorry state of our spec process
First of all, Thanks Flavio for bring this open to the daylight! I have been really frustrated about the Glance spec process since the beginning and as glance core tried to work around the limitations the best I can. I'm not sure if the process is similar way broken on the other projects, but I think after piloting the process in Glance for couple of cycles we should take some action on it. Few comments inline as that way they are easier to scope. -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Wednesday, July 01, 2015 2:49 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] The sorry state of our spec process Greetings, We're 1 week through L-2 (or is it 2?, I can't do time) and we, the glance project, haven't even merged a single spec. Regardless of the reasons behind this situation and the fact that we've been indeed taking steps to improve this situation, I think we should put this issue to an end. This is really sad state to be in. We haven't approved a single spec by the time other projects are already freezing their spec repos for L. There are many issues we've faced in Glance: 1. The glance-drivers team is too small [0] 2. Many specs have been held back waiting for code [1] 3. Huge expectations from the spec and very low review rate (even from other members of the glance team). This issue was discussed while ago and was postponed to clarify the Glance Spec process. After that this is first initiative to bring the issue back to table and I'd like to hear if that process defining work is still blocking the expansion to share the workload. If so, could we please get the proposal of that workload or at least the parts of it that needs to be ironed out open in public so we can move that forward as community? There was a recent discussion on this m-l[2] about the spec process in Nova and while I don't agree with everything that was said there, I do think it highlights important problems that we're facing in glance as well. Therefore, I'd like to propose the following: 1. Expand our drivers team. I thik people in the glance community are getting annoyed of reading this requests from me and The Mythical Man-Month would agree with them. However, it's really sad that some of our oldest (in terms of tenure) contributors that have shown interest in joining the team haven't been added yet. I proposed to bring all cores to the drivers team already and I still think that's a good thing. Assuming that's something we don't want, then I'd like us to find 2 or 3 people willing to volunteer for this task. If this still cannot happen I'd like to get full commitment from our current drivers to dedicate the time and effort for speedy workflow on our specs or step down and trash the whole spec process. 2. Lets try to get things into the backlog instead of expecting them to be perfectly shaped and targeted for this release. Lets let people start from a base, generally agreed, idea so that code can be written and reviews on the actual feature can be made. Once the feature is implemented, we can move the spec to the release directory. I believe this was also proposed in Nikola's thread[2]. I'm huge supporter of this. Specs being part of our normal review workflow makes changing them as needed easy and trackable. Why in earth we need to have perfect plan and implementation for that plan before we're willing to indicate approval for the initial idea? 3. Not all specs need to have 3-month-long discussions to be approved. I'm not suggesting to just merge specs that are in poor state but we can't always ask for code to understand whether a spec makes sense or not. Unfortunately, we're already in L-2 and I believe it'll be really hard for some of those features to land in Liberty, which is also sad and quite a waste of time. How long we will have people trying to improve the project if any given proposed functionality takes cycles and lots of politics to merge. I don't believe the above is the ultimate solution to this issue but I believe it will help. For the next cycle, we really need to organize this process differently. ++ - Erno The email is already long enough so, I hope we'll agree on something and finally take some actions. Cheers, Flavio [0] https://review.openstack.org/#/c/126550/ [1] https://review.openstack.org/#/admin/groups/342,members (Mark Washenberger and Arnaud Legendre are not contributors anymore) [2] http://lists.openstack.org/pipermail/openstack-dev/2015- June/067861.html -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Show attribute is a collection of other attributes or not?
Thank everyone for the good feedback.
If summarize all suggestions:
- I will continue add show as raw output (similar on clients show command
output)
- Also we decided to implement additional functional for get_attr
function, when it get only resource name and returns map with all
attributes (except show).
About second one need volunteer :)
Regards,
Sergey.
On 3 July 2015 at 00:04, Steven Hardy sha...@redhat.com wrote:
On Fri, Jul 03, 2015 at 07:35:18AM +1200, Steve Baker wrote:
On 03/07/15 06:03, Randall Burt wrote:
Maybe use all for all attributes in the schema and use show for the
raw output from the service (as is done today for server and neutron stuff).
Instead of all, how about allowing a special form of {get_attr:
[resource_name]} with no extra arguments to return a dict of all
attributes?
This would be consistent with how extra arguments traverse attribute
data.
+1
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Why doesn't Gerrit email me?
Hi Jeremy, On 30/06/15 17:45, Neil Jerram wrote: On 30/06/15 16:14, Jeremy Stanley wrote: On 2015-06-30 14:08:45 +0100 (+0100), Neil Jerram wrote: [...] I keep going back to Gerrit jobs that I've reviewed or commented on, and finding that there have been other comments since mine, but that Gerrit didn't email me about. [...] Looking in our MTA logs for review.openstack.org, I see lots of 550 5.7.1 Message rejected due to content restrictions errors for your address and other addresses at your domain. I recommend having your mailserver administrators review their logs for additional detail. Thanks very much, Jeremy, that's really useful information. Hopefully with this I can get the problem fixed at my end. Would you mind checking whether there were still any such errors for my domain, for the second half of yesterday (2nd July) UK time? My admins here think they've fixed something, but I think I'm still missing some Gerrit notification emails, so I'm not convinced myself. Thanks, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
