Re: [openstack-dev] [openstack-tc][deb-packaging] Updated proposal for OpenStack deb packages
On 07/24/2015 11:07 AM, Thierry Carrez wrote: Igor Yozhikov wrote: Hello again to everyone, resending this letter due to typo in the topic of the previous letter, apologize for this. * Introductory words:* I want to present renewed proposal for packaging of OpenStack components for deb based Linux distributions. In case of stackforge retirement, I believe that new repositories for deb specs should appears under the //openstack// name-space instead of //stackforge//. This and further steps was also advised by dhellmann, anteaya and angdraug at #openstack-meeting irc channel during/after TechnicalCommittee meeting http://paste.openstack.org/show/399927/ yesterday 21 of Jul 2015. Also it would be great to discuss all of this during next TC meeting July 28th. Igor, The following was proposed to the TC, but needs a revision to match what you propose here: https://review.openstack.org/#/c/185187/ Would you mind updating the proposed change there ? That way we could discuss it at the TC next week... Done. Please note that package repository names are based on actual source package names in Debian. For example, /openstack/openstack-trove and not just trove, which refers to a Java library in Debian. Thomas P.S: I'd also would like to add that I've seen people bike-shedding around the name openstack-pkg-tools. The rename of this tool is *not* open for discussion (it would be too much work). Yes, it's Debian specific, but maybe it wont at some point, as there are tools that may be interesting for RPM guys. Even if we never do that, this (Debian native) package is prefixed by deb- like every other Git repository, so there's no way to be confused. Finally, this has *nothing* to do with the actual TC discussion, so let's discuss this issue *separately*, shall we? __ 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] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API
On 07/27/2015 07:15 PM, Cathy Zhang wrote: Hi Anita, Not sure if you read the logs. The concern on https://review.openstack.org/#/c/186663/ and duplication were brought up by Sean. The goal is to have one set of API instead of multiple APIs with minor differences. The consensus is that the SFC API seems more general than the forwarding API, the forwarding API can be covered by the chain API, and the forwarding API is just a chain of 1 (a special case of chain API). Here are some snips of the meeting log related to this discussion. Per my action items of the meeting, I am sending out an email updating everyone about our discussion and consensus. No one can force anyone else to do anything. This community project team have done diligence to reach out to authors of https://review.openstack.org/#/c/186663/ multiple times before about collaboration and convergence of APIs (Please refer to previous meeting logs). --- 17:11:55 pcarver vikram: it's not the same but it has a lot in common. If we're going to have both there will need to be extremely clear documentation to guide operators and tenants on when to use each. 17:12:16 pcarver Especially if the two can interact in unpredictable ways 17:12:19 vikram pcarver: i agree.. 17:12:23 sc68cal I just feel like there are some things that are in common, the idea of redirecting traffic - the mechanics may be different but I don't like this idea of oh it's just a little bit different, therefore a whole new separate API is justified 17:12:52 vikram sc68cal: h 17:13:20 pcarver cathy_: I understand the desire to not have too many dependencies, but it may make sense to have a have one be a degenerate case of the other 17:13:42 pcarver as opposed to two unrelated things that appear similar to the user 17:14:04 LouisF sc68cal: the sfc is more general than the forwarding spec 17:14:30 LouisF its functionality can be covered by the sfc spec 17:14:36 vikram sc68cal, pcarver: I agree, service function chaining can achieve the use case defined in forwarding spec 17:15:06 pcarver LouisF, vikram: I haven't reviewed 186663 before looking at it just now, but is there a reason why it couldn't be implemented as a trivially simple service chain? -- 17:15:31 cathy_ vikram:agree with you. Would you like to talk with Yuji on that ? 17:15:32 vikram pcarver: I believe it can 17:15:36 LouisF pcarver: yes I think that can be done 17:16:03 sc68cal yeah I mean I could be stupid but the forwarding API is basically just a chain of 1 -- 17:16:11 vikram cathy_: We can put our concerns over the etherpad link shared for this spec 17:16:14 sc68cal and BTW - fwaas is going to be a chain of 1 17:16:26 vikram https://etherpad.openstack.org/p/forwarding-rule 17:16:27 sc68cal if we're inserting a firewall between an instance and the rest of the network 17:16:52 sc68cal I had hoped to consume SFC, to look into making fwaas more flexible 17:17:00 vikram sc68cal:+++100 17:17:41 pcarver sc68cal: +1, security functions are a primary example of the reason for SFC, although not all chained functions are firewallish 17:17:55 jwarendt +1 17:18:27 cathy_ So we all agree that the service chain API can cover the functionality needed in https://review.openstack.org/#/c/186663/ 17:18:41 LouisF +1 17:18:58 pcarver I'm also hearing requirements from the NFV side wanting to replicate hub and spoke topologies. I'm viewing that also as a subset of SFC - 17:21:16 cathy_ So how should we make sure there is no duplicate API? Maybe Vikram can communicate this with Yuji? Suggestion? 17:22:13 sc68cal I'd say maybe an e-mail to the ML, with the results of this meeting, and say that we want to try and converge where there is commonality 17:22:19 vikram cathy_: sure.. i have posted a comment on the spec.. will try to catch him tomorrow over IRC as wekk I'm suggesting to both yourself and Louis that a bit of humility would be a welcome consideration to your communications. Thank you, Anita. -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Monday, July 27, 2015 2:20 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API On 07/24/2015 06:50 PM, Cathy Zhang wrote: Hi Everyone, In our last networking-sfc project IRC meeting, an issue was brought up that the API proposed in https://review.openstack.org/#/c/186663/ has a lot of duplication to the SFC API https://review.openstack.org/#/c/192933/ that is being currently implemented. In the IRC meeting, the project team reached consensus that we only need one API and the service chain API can cover the functionality needed by https://review.openstack.org/#/c/186663/. Please refer to
[openstack-dev] [all] Cross-Project meeting, Tue July 28th, 21:00 UTC
Dear PTLs, cross-project liaisons and anyone else interested, We'll have a cross-project meeting today at 21:00 UTC. I have agreed to chair it this week. Here is the agenda: * Team announcements (horizontal, vertical, diagonal) * API Guidelines that are ready for final review [1] * Cross project specs ** No global admin [2] ** Uniform public methods for clients [3] ** Return request-id to caller - tpatil [4] * Open discussion [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069765.html [2] https://review.openstack.org/#/c/205629 [3] https://review.openstack.org/#/c/202586 [4] https://review.openstack.org/#/c/156508 If you're from an horizontal team (Release management, QA, Infra, Docs, Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and have something to communicate to the other teams, feel free to abuse the relevant sections of that meeting and make sure it gets #info-ed by the meetbot in the meeting summary. See you there! For more details on this meeting, please see: https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting Thanks, johnthetubaguy __ 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] Removing python-swiftclient from requirements.txt
I do agree, we don't depend or are cleaning the other clients out of the glance dependencies as well and I think swift should not be there either. The default store is filesystem store and if something is depending on the actual store clients it should be either glance_store or deployer (well for example our gate) glance itself should not have hard dependencies for 'em. - Erno From: William M Edmonds [mailto:edmon...@us.ibm.com] Sent: Monday, July 27, 2015 10:42 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? The optional dependencies spec [2] could definitely help here. I don't think we should have to wait for that, though. This is an issue we obviously already have today for other backends, which indicates folks can deal with it without an optional dependencies implementation. This would be a new concern for operators using the default swift backend, though. So how do we get the message out to those operators? And do we need to put out a message about this change in Liberty and then wait until Mitaka to actually remove this, or can we go ahead and remove in Liberty? [1] https://review.openstack.org/#/c/203242 [2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/optional-deps.html -Matthew __ 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] Proposing Yanis Guenane core
On 27/Jul/2015 .::. 15:06, Emilien Macchi wrote: Puppet group, Yanis has been working in our group for a while now. He has been involved in a lot of tasks, let me highlight some of them: * Many times, involved in improving consistency across our modules. * Strong focus on data binding, backward compatibility and flexibility. * Leadership on cookiebutter project [1]. * Active participation to meetings, always with actions, and thoughts. * Beyond the stats, he has a good understanding of our modules, and quite good number of reviews, regularly. Yanis is for our group a strong asset and I would like him part of our core team. I really think his involvement, regularity and strong knowledge in Puppet OpenStack will really help to make our project better and stronger. I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Best regards, [1] https://github.com/openstack/puppet-openstack-cookiecutter -- Emilien Macchi A Strong +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 Best Regards, Gaël. -- Gaël Chamoulaud Openstack Engineering Mail: [gchamoul|gael] at redhat dot com IRC: strider/gchamoul (Red Hat), gchamoul (Freenode) GnuPG Key ID: 7F4B301 C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301 Freedom...Courage...Commitment...Accountability signature.asc Description: PGP 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
[openstack-dev] [Horizon][Neutron] how to configure horizon to use lbaas api v2?
Hi all, In devstack, I configured enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas ENABLED_SERVICES+=,q-lbaasv2 so, I can use lbaasv2 api in neutronclient. But I see the agent that's name is q-lbaasv2 not q-lbaas in screen, and horizon can recognize it . So I cann't use resource about lbaas in horizon. What should to let horizon recognize q-lbaasv2? Wilence Yao __ 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-operators] Is the neutron port-security extension available for ML2 linux-bridge?
Thanks for the response James. The port-security extension was implemented for ML2 with OVS in Kilo but I cannot seem to find any similar implementation for linux-bridge. It also works with LinuxBridge in Kilo. To gain this functionality, you'll need to upgrade the environment from Juno to Kilo. Though I have never tried code patches to my environment before, I have to ask: is it possible to bring just enough of the changes in Kilo ML2 into the current Juno install? If so, how could I go about that? Charles ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[openstack-dev] Dragonflow - Weekly IRC Meeting
Hello Everyone, If you are not familiar with Dragonflow, it is a lightweight SDN controller embedded in Neutron that tries to solve distributed virtual routing the SDN way. Dragonflow is officially part of Neutron big tent starting at Kilo, you can read more information about it in the following blog posts [1], [2] and [3]. We are currently under going scale testing and performance tuning using shaker [4] and big scale Openstack environment. There are many future features and ideas coming and we want to make our discussion as transparent and visible to everyone that is interested and hopefully prioritize things based on inputs from the community. We would like to conduct a weekly IRC meeting, If you are interested in the project and planning to attend, please suggest what is the best day/time to do the meeting. Thanks Gal. [1] http://blog.gampel.net/2015/01/dragonflow-sdn-based-distributed.html [2] http://galsagie.github.io/sdn/openstack/ovs/dragonflow/2015/05/09/dragonflow-1/ [3] http://galsagie.github.io/sdn/openstack/ovs/dragonflow/2015/05/11/dragonflow-2/ [4] https://github.com/stackforge/shaker __ 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-operators] [openstack-dev] Which is the correct way to set ha queues in RabbitMQ
You're welcome :)
On Tue, Jul 28, 2015 at 1:15 PM, Alvise Dorigo alvise.dor...@pd.infn.it
wrote:
thank you very much Vishal.
A.
On 28/07/2015 09:41, vishal yadav wrote:
ha_all vs. HA.
which one is correct ?
That's the policy name, you can name anything...
Excerpt from 'man rabbitmqctl'
...
set_policy [-p vhostpath] {name} {pattern} {definition} [priority]
Sets a policy.
name
The name of the policy.
pattern
The regular expression, which when matches on a given
resources causes the policy to apply.
definition
The definition of the policy, as a JSON term. In most
shells you are very likely to need to quote this.
priority
The priority of the policy as an integer, defaulting to 0.
Higher numbers indicate greater precedence.
...
Regards,
Vishal
On Tue, Jul 28, 2015 at 12:47 PM, Alvise Dorigo alvise.dor...@pd.infn.it
wrote:
Hi,
I read these two documents:
http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
https://www.rdoproject.org/RabbitMQ
To configure the queues in HA mode, the two docs suggests two slightly
different commands;
The first one says:
rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{ha-mode: all}'
while the second one says:
rabbitmqctl set_policy HA '^(?!amq\.).*' '{ha-mode: all}'
ha_all vs. HA.
which one is correct ?
thanks,
Alvise
__
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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [fuel] Fuel plugin as docker containers images
Hi Konstantin, I'm not sure if we track such feature anywhere. But one of the reasons to use containers on the master was to deliver plugin specific containers, so they don't intersect and don't break Fuel master dependencies. Do you have some specific use case for that? Thanks, On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov kdani...@mirantis.com wrote: Hi, Is there a plans to allow plugin to be delivered as docker container images? Thanks -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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] [cinder][nova] snapshot and cloning for NFS backend
Hi Devs, There is an NFS backend driver for cinder, which supports only limited volume handling features. Specifically, snapshot and cloning features are missing. Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], which was approved on Dec 2014 but not implemented yet. [1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots [2] cinder-specs https://review.openstack.org/#/c/133074/ - merged for Kilo but moved to Liberty [3] implementation https://review.openstack.org/#/c/147186/ - WIP As of now [4] nova patch is a blocker for this feature. I have tested this feature by applying [4] nova patch and it is working as per expectation. [4] https://review.openstack.org/#/c/149037/ IMO this is a very useful feature and I want to know communities opinion/direction about getting it merged during liberty time-frame. Thanks Regards, 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 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-operators] [puppet] module dependencies and different openstack versions
Hi, I have same feedback as Robert, we use the openstack/puppet-[project] modules and they are quiet independent. We have our own module that integrates those modules as we need and we even deploy each service on different nodes so we need them to be independent and we could achieve it. Kind regards, Cynthia Lopes do Sacramento 2015-07-28 9:43 GMT+02:00 Van Leeuwen, Robert rovanleeu...@ebay.com: We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don¹t want it to mess with keystone (for one we don¹t support setting endpoints via an API) but also we don¹t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we¹ll may never move to the official keystone puppet module. The neutron module pulls in the vswitch module but we don¹t use vswitch and it doesn¹t seem to be a requirement of the module so maybe doesn¹t need to be in metadata dependencies? It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? Hi, In my experience (I am setting up a new environment) the modules can be used ³stand-alone². It is the OpenStack module itself that comes with a combined server example. The separate modules (nova, glance, etc) are very configurable and don¹t necessarily need to setup e.g. keystone. From the OpenStack module you can modify the profiles and it will not do the keystone stuff / database, etc.. E.g. Remove the ³:nova::keystone::auth² part in the nova profile. We use r10k to select which versions to install and it should be trivial to use Juno / Kilo stuff together (have not tested this myself). Regarding the vswich module I *guess* that that is regulated by the following: neutron/manifests/agents/ml2/ovs.pp: if $::neutron::params::ovs_agent_package So unsetting that variable should not pull the package. Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Hi Alexander, I don't agree with your statements
[1] - I just uses % and % to substitute values.
It's what templating is about, you have some text preprocessor to
substitute values.
That is not ERB style template language.
ERB uses the same syntax, hence it Is ERB style.
[2] - We are not using Jinja templating (it is just yaml file, not html
template), we are using Jinja placeholder substitution.
We *are using* jinja templating (I don't understand why you mention here
html),
with all it's features and here is the proof [1].
And in current code we have a problem with content at first parsed from
yaml and that parser treats { and [ as a start if a dict or an array.
key: {{blha}}
[3] - Templates are for people who do not care about Jinja/ERB (maybe
some familiar with Puppet/Chef), so no confusion.
That is not correct, every template has it's own syntax, so people have to
care about
specific implementation i.e. Jinja or ERB, and there will be confusion when
somebody will
try to use ERB specific features, and she/he will fail because you hide
Jinja under ERB
syntax.
[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/objects/node.py#L854-L855
On Tue, Jul 28, 2015 at 11:29 AM, Alexander Kostrikov
akostri...@mirantis.com wrote:
Completely agree with Sergey.
Currently network template uses ERB [1] style template language,
but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
the user
[1] - I just uses % and % to substitute values. That is not ERB style
template language.
[2] - We are not using Jinja templating (it is just yaml file, not html
template), we are using Jinja placeholder substitution. And in current code
we have a problem with content at first parsed from yaml and that parser
treats { and [ as a start if a dict or an array.
[3] - Templates are for people who do not care about Jinja/ERB (maybe some
familiar with Puppet/Chef), so no confusion.
On Tue, Jul 28, 2015 at 10:57 AM, Sergey Vasilenko
svasile...@mirantis.com wrote:
On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L e...@mirantis.com wrote:
Currently network template uses ERB [1] style template language,
but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
the user, with ERB which is in fact jinja and doesn't have any ERB
features.
we have not so much syntax choices for convenient templating. Network
temptales will be used by system administrators.
The '% %' pair is a de-facto standart in this area. In the puppet
world. Not every system administrator will meaning ERB when seeing '% %'
pair.
Another pairs (i.e. '$ $' , ' ', etc) looks more
non-standart. Plenty of syntax features are annoy and make usability of
product less convenient.
I propose do not make extra essences on the clean area...
We never say in the docs about ERB. IMHO it's enough for leave '% %'
as is.
/sv
__
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
--
Kind Regards,
Alexandr Kostrikov,
Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia
Tel.: +7 (495) 640-49-04
Tel.: +7 (925) 716-64-52 %2B7%20%28906%29%20740-64-79
Skype: akostrikov_mirantis
E-mail: akostri...@mirantis.com elogut...@mirantis.com
*www.mirantis.com http://www.mirantis.ru/*
*www.mirantis.ru http://www.mirantis.ru/*
__
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] [Fuel][RabbitMQ][puppet] Kilo status of the heartbeats implementation
Bogdan, Answering your questions, in MOS 7.0 source code heartbeats are enabled by default (with heartbeat_timeout_threshold value set to 60). We patched our version of upstream stable/kilo to do so. So, in installed env heartbeats are enabled for every component except Neutron, for which puppet manifests explicitly disable heartbeats, as you already noted. Regarding how should we proceed, right now we are testing how upstream implementation performs in our environments. I suggest to postpone the decision until we have enough data. Thanks, Dmitry 2015-07-28 12:06 GMT+03:00 Bogdan Dobrelya bdobre...@mirantis.com: Folks, it seems the situation with Kilo support for RabbitMQ heartbeats should be elaborated. There is a bug [0] and a ML [1] related. The questions are: a) Should Fuel 7.0 with Kilo *explicitly* disable via puppet the upstream implementation of heartbeats for all OpenStack components (Neutron example [2]) and keep the MOS specific implementation of heartbeats configured the same way as it was for Juno? b) Or should we change nothing additionally allowing Oslo defaults for Kilo being populated for heartbeats settings out of box? Related question - what are upstream heartbeat defaults in MOS, do they differ to upstream ones? [0] https://bugs.launchpad.net/fuel/+bug/1477689 [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068751.html [2] https://review.openstack.org/#/c/194381/ -- Best regards, Bogdan Dobrelya, Irc #bogdando __ 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] Announcing HyperStack project
Jay, Yes, it is on the agenda. Thanks, Adrian On Jul 27, 2015, at 8:32 AM, Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com wrote: Adrian, Can we put hyper as a topic for this week's (Tomorrow) meeting? I want to have some discussion with you. Thanks 2015-07-27 0:43 GMT-04:00 Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com: Peng, For the record, the Magnum team is not yet comfortable with this proposal. This arrangement is not the way we think containers should be integrated with OpenStack. It completely bypasses Nova, and offers no Bay abstraction, so there is no user selectable choice of a COE (Container Orchestration Engine). We advised that it would be smarter to build a nova virt driver for Hyper, and integrate that with Magnum so that it could work with all the different bay types. It also produces a situation where operators can not effectively bill for the services that are in use by the consumers, there is no sensible infrastructure layer capacity management (scheduler), no encryption management solution for the communication between k8s minions/nodes and the k8s master, and a number of other weaknesses. I’m not convinced the single-tenant approach here makes sense. To be fair, the concept is interesting, and we are discussing how it could be integrated with Magnum. It’s appropriate for experimentation, but I would not characterize it as a “solution for cloud providers” for the above reasons, and the callouts I mentioned here: http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html Positioning it that way is simply premature. I strongly suggest that you attend the Magnum team meetings, and work through these concerns as we had Hyper on the agenda last Tuesday, but you did not show up to discuss it. The ML thread was confused by duplicate responses, which makes it rather hard to follow. I think it’s a really bad idea to basically re-implement Nova in Hyper. Your’e already re-implementing Docker in Hyper. With a scope that’s too wide, you won’t be able to keep up with the rapid changes in these projects, and anyone using them will be unable to use new features that they would expect from Docker and Nova while you are busy copying all of that functionality each time new features are added. I think there’s a better approach available that does not require you to duplicate such a wide range of functionality. I suggest we work together on this, and select an approach that sets you up for success, and gives OpenStack could operators what they need to build services on Hyper. Regards, Adrian On Jul 26, 2015, at 7:40 PM, Peng Zhao p...@hyper.shmailto:p...@hyper.sh wrote: Hi all, I am glad to introduce the HyperStack project to you. HyperStack is a native, multi-tenant CaaS solution built on top of OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper + Kubernetes + Cinder + Neutron. HyperStack is different from Magnum in that HyperStack doesn't employ the Bay concept. Instead, HyperStack pools all bare-metal servers into one singe cluster. Due to the hypervisor nature in Hyper, different tenants' applications are completely isolated (no shared kernel), thus co-exist without security concerns in a same cluster. Given this, HyperStack is a solution for public cloud providers who want to offer the secure, multi-tenant CaaS. Ref: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png The next step is to present a working beta of HyperStack at Tokyo summit, which we submitted a presentation: https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030. Please vote if you are interested. In the future, we want to integrate HyperStack with Magnum and Nova to make sure one OpenStack deployment can offer both IaaS and native CaaS services. Best, Peng -- Background --- Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker images with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different from the minimalist Linux distros like CoreOS by that Hyper runs on the physical box and load the Docker images from the metal into the VM instance, in which no guest OS is present. Instead, Hyper boots a minimalist kernel in the VM to host the Docker images (Pod). With this approach, Hyper is able to bring some encouraging results, which are similar to container: - 300ms to boot a new HyperVM instance with a pod of Docker images - 20MB for min mem footprint of a HyperVM instance - Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for scheduling - Immune from the shared kernel problem in LXC, isolated by VM - Work seamlessly with OpenStack components, Neutron, Cinder, due to the hypervisor nature - BYOK, bring-your-own-kernel is somewhat mandatory for a public cloud platform
Re: [openstack-dev] [all] [oslo] Suggestion to change verbose=false to true in oslo.log by default
On 07/27/2015 02:11 PM, Sean Dague wrote: Honestly, I think deprecating and removing 'verbose' is probably the best option. INFO is probably the right default behavior, and it's not really verbose in any real openstack usage. It is unlikely that anyone would want that to be in the off state, and if so, they can do that via python logging config. Thanks! As I saw no objections, I went ahead and proposed https://review.openstack.org/#/c/206437/ On 07/27/2015 06:32 AM, Dmitry Tantsur wrote: Hi all! I didn't find the discussion on the ML so I feel like starting one. What was the reason of setting verbose to false by default? The patch [1] does not provide any reasoning for it. We all know that software does fail from time to time. While the default level of WARN might give some signal to an operator that *something* is wrong, it usually does not give much clues on *what* and *why*. Our logs guidelines define INFO as units of work, and the default means that operators/people debugging their logs won't even be able to track transitions in their system that lead to an error/warning. Of all people I know 100% are using DEBUG level by default, the only post I've found here on this topic [2] seems to state the same. I realize that DEBUG might give too much information to process (though I always request people to enable debugging log before sending my any bug reports). But is there really a compelling reason to disable INFO? Examples of INFO logs from ironic tempest run: ironic cond: http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-ir-cond.txt.gz?level=INFO nova cpu: http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-n-cpu.txt.gz?level=INFO and the biggest one neutron agt: http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-q-agt.txt.gz?level=INFO As you can see, these logs are so small, you can just read through them without any tooling! Of course it's not a real world example, but I'm dealing with hundrer-of-megabytes debug-level text logs from nova + ironic nearly every day. It's still manangeable for me, grep handles it pretty well (to say nothing about journalctl). WDYT about changing this default on oslo.log level? Thanks, Dmitry [1] https://review.openstack.org/#/c/18110/ [2] http://lists.openstack.org/pipermail/openstack-operators/2014-March/004156.html __ 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] Which is the correct way to set ha queues in RabbitMQ
Hi,
I read these two documents:
http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
https://www.rdoproject.org/RabbitMQ
To configure the queues in HA mode, the two docs suggests two slightly
different commands;
The first one says:
rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{ha-mode: all}'
while the second one says:
rabbitmqctl set_policy HA '^(?!amq\.).*' '{ha-mode: all}'
ha_all vs. HA.
which one is correct ?
thanks,
Alvise
__
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] [fuel] FF Exception request for Templates for Networking feature
On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L e...@mirantis.com wrote: Currently network template uses ERB [1] style template language, but in fact it's Jinja [2], it was agreed to change it [3], no to confuse the user, with ERB which is in fact jinja and doesn't have any ERB features. we have not so much syntax choices for convenient templating. Network temptales will be used by system administrators. The '% %' pair is a de-facto standart in this area. In the puppet world. Not every system administrator will meaning ERB when seeing '% %' pair. Another pairs (i.e. '$ $' , ' ', etc) looks more non-standart. Plenty of syntax features are annoy and make usability of product less convenient. I propose do not make extra essences on the clean area... We never say in the docs about ERB. IMHO it's enough for leave '% %' as is. /sv __ 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-operators] [openstack-dev] Which is the correct way to set ha queues in RabbitMQ
Hi Vishal,
do you have a effective recipe to test if the rabbitmq's HA ?
I've three instances of it; I've also nova, cinder and neutron
configured with rabbit_ha_queues = true.
Just restarting a rabbit instance seems not to be sufficient to test a
real case scenario, is it ?
any advice ?
thanks,
Alvise
On 28/07/2015 09:46, vishal yadav wrote:
You're welcome :)
On Tue, Jul 28, 2015 at 1:15 PM, Alvise Dorigo
alvise.dor...@pd.infn.it mailto:alvise.dor...@pd.infn.it wrote:
thank you very much Vishal.
A.
On 28/07/2015 09:41, vishal yadav wrote:
ha_all vs. HA.
which one is correct ?
That's the policy name, you can name anything...
Excerpt from 'man rabbitmqctl'
...
set_policy [-p vhostpath] {name} {pattern} {definition} [priority]
Sets a policy.
name
The name of the policy.
pattern
The regular expression, which when matches on a
given resources causes the policy to apply.
definition
The definition of the policy, as a JSON term. In
most shells you are very likely to need to quote this.
priority
The priority of the policy as an integer,
defaulting to 0. Higher numbers indicate greater precedence.
...
Regards,
Vishal
On Tue, Jul 28, 2015 at 12:47 PM, Alvise Dorigo
alvise.dor...@pd.infn.it mailto:alvise.dor...@pd.infn.it wrote:
Hi,
I read these two documents:
http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
https://www.rdoproject.org/RabbitMQ
To configure the queues in HA mode, the two docs suggests two
slightly different commands;
The first one says:
rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{ha-mode: all}'
while the second one says:
rabbitmqctl set_policy HA '^(?!amq\.).*' '{ha-mode: all}'
ha_all vs. HA.
which one is correct ?
thanks,
Alvise
__
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
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend
Hi The patch [4] has been abandoned but it's not clear why. I too think that having a full fledged NFS driver would be great ! [4] https://review.openstack.org/#/c/149037/ Jordan On Tue, Jul 28, 2015 at 10:00 AM, Kekane, Abhishek abhishek.kek...@nttdata.com wrote: Hi Devs, There is an NFS backend driver for cinder, which supports only limited volume handling features. Specifically, snapshot and cloning features are missing. Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], which was approved on Dec 2014 but not implemented yet. [1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots [2] cinder-specs https://review.openstack.org/#/c/133074/ - merged for Kilo but moved to Liberty [3] implementation https://review.openstack.org/#/c/147186/ - WIP As of now [4] nova patch is a blocker for this feature. I have tested this feature by applying [4] nova patch and it is working as per expectation. [4] https://review.openstack.org/#/c/149037/ IMO this is a very useful feature and I want to know communities opinion/direction about getting it merged during liberty time-frame. Thanks Regards, 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 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] [fuel] FF Exception request for Templates for Networking feature
On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L e...@mirantis.com wrote: Hi Alexander, I don't agree with your statements [1] - I just uses % and % to substitute values. It's what templating is about, you have some text preprocessor to substitute values. Network templates feature don't mean any text preprocessor actions. Only value substitutions That is not ERB style template language. ERB uses the same syntax, hence it Is ERB style. ... hence it looks like ERB. not more. Not only ruby used for programming. Non only EBD -- is template language. ;) [2] - We are not using Jinja templating (it is just yaml file, not html template), we are using Jinja placeholder substitution. We *are using* jinja templating (I don't understand why you mention here html), with all it's features and here is the proof [1]. We don't promise use Junja (or whatever) template language for this feature. If some jinja features allowed for parsing Network template -- it's a bug. We should check it and fix it. Only value substitutions should allow in the network templates. [3] - Templates are for people who do not care about Jinja/ERB (maybe some familiar with Puppet/Chef), so no confusion. That is not correct, every template has it's own syntax, so people have to care about specific implementation i.e. Jinja or ERB, and there will be confusion when somebody will try to use ERB specific features, and she/he will fail because you hide Jinja under ERB syntax. I, partially, agree with you. But please honored to following facts: * In the deployers world used Jinja and ERB syntax. * ERB used more often, because Ansible (I don't know another popular deployers tools with Jinja templating) is to young. * Plenty of syntax features is a really hell. In the Network templates we don't suppose anything other than a simple substitution variable values. All logic of template processing implementing on Nailgun side. Now on the template parsing, later -- on the network manipulation class. Allowance of mix template language and Nailgun logic may lead to heavy diagnostic issues. Meantime I don't see any cases, where required something more, than substitution. /sv __ 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][nova] snapshot and cloning for NFS backend
Hi Jordan, The patch [4] is abandoned by the owner because as of now as it’s not an appropriate way to fix this issue and it need to be fixed using some other way. Nova members please let us know your suggestions about the same. Thank you, Abhishek Kekane From: Jordan Pittier [mailto:jordan.pitt...@scality.com] Sent: 28 July 2015 14:24 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [cinder][nova] snapshot and cloning for NFS backend Hi The patch [4] has been abandoned but it's not clear why. I too think that having a full fledged NFS driver would be great ! [4] https://review.openstack.org/#/c/149037/ Jordan On Tue, Jul 28, 2015 at 10:00 AM, Kekane, Abhishek abhishek.kek...@nttdata.commailto:abhishek.kek...@nttdata.com wrote: Hi Devs, There is an NFS backend driver for cinder, which supports only limited volume handling features. Specifically, snapshot and cloning features are missing. Eric Harney has proposed a feature of NFS driver snapshot [1][2][3], which was approved on Dec 2014 but not implemented yet. [1] blueprint https://blueprints.launchpad.net/cinder/+spec/nfs-snapshots [2] cinder-specs https://review.openstack.org/#/c/133074/ - merged for Kilo but moved to Liberty [3] implementation https://review.openstack.org/#/c/147186/ - WIP As of now [4] nova patch is a blocker for this feature. I have tested this feature by applying [4] nova patch and it is working as per expectation. [4] https://review.openstack.org/#/c/149037/ IMO this is a very useful feature and I want to know communities opinion/direction about getting it merged during liberty time-frame. Thanks Regards, 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 Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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 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] [Fuel][python-fuelclient] Implementing new commands
It looks like most people agree on option C (implement features in fuel and fuel2) and in the meantime we should slowly progress with moving fuel to fuel2. 2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk sgolovat...@mirantis.com: Hi, Every functionality should be applied to both clients. Core developers should set -1 if it's not applied to second version of plugin. Though I believe we should completely get rid of first version of CLI in Fuel 8.0 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh ogelb...@mirantis.com wrote: FWIW, I'm for option B, combined with clear timeline for porting features of fuel-variant to fuel2. For example, we are developing client-side functions for fuel-octane (cluster upgrade) extensions only for fuel2, and don't plan to implement it for 'fuel'. The main reason why we can't just drop 'fuel', or rather switch it to fuel2 syntax, IMO, is the possibility that someone somewhere uses its current syntax for automation. However, if the function is completely new, the automation of this function should be implemented with the new version of syntax. -- Best regards, Oleg Gelbukh On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev fzhad...@mirantis.com wrote: Hi all, I think that in current situation the best solution will be to add new features for the both versions of client. It may cause a little slowing down of developing each feature, but we won't have to return to them in future. 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com: Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C.. but only if implementing support in either fuel or fuel2 may be postponed to SCF. Thanks, Igor On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote: Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Hi Sergey, Thanks, now I see why we had misunderstanding. The problem is currently all set of features which Jinja2 provides is available for the user. As far as I know there is no way in Jinja to disable all of the functionality except just substitution. If we need only substitution, probably it's better to use standard templating in python [1], there is a way to redefine tokens, so you will be able to use % % syntax if you want to. [1] https://docs.python.org/2.6/library/string.html#template-strings https://docs.python.org/dev/library/string.html#template-strings [2] http://pymotw.com/2/string/#advanced-templates On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko svasile...@mirantis.com wrote: On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L e...@mirantis.com wrote: Hi Alexander, I don't agree with your statements [1] - I just uses % and % to substitute values. It's what templating is about, you have some text preprocessor to substitute values. Network templates feature don't mean any text preprocessor actions. Only value substitutions That is not ERB style template language. ERB uses the same syntax, hence it Is ERB style. ... hence it looks like ERB. not more. Not only ruby used for programming. Non only EBD -- is template language. ;) [2] - We are not using Jinja templating (it is just yaml file, not html template), we are using Jinja placeholder substitution. We *are using* jinja templating (I don't understand why you mention here html), with all it's features and here is the proof [1]. We don't promise use Junja (or whatever) template language for this feature. If some jinja features allowed for parsing Network template -- it's a bug. We should check it and fix it. Only value substitutions should allow in the network templates. [3] - Templates are for people who do not care about Jinja/ERB (maybe some familiar with Puppet/Chef), so no confusion. That is not correct, every template has it's own syntax, so people have to care about specific implementation i.e. Jinja or ERB, and there will be confusion when somebody will try to use ERB specific features, and she/he will fail because you hide Jinja under ERB syntax. I, partially, agree with you. But please honored to following facts: * In the deployers world used Jinja and ERB syntax. * ERB used more often, because Ansible (I don't know another popular deployers tools with Jinja templating) is to young. * Plenty of syntax features is a really hell. In the Network templates we don't suppose anything other than a simple substitution variable values. All logic of template processing implementing on Nailgun side. Now on the template parsing, later -- on the network manipulation class. Allowance of mix template language and Nailgun logic may lead to heavy diagnostic issues. Meantime I don't see any cases, where required something more, than substitution. /sv __ 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] [Ironic] Let's talk about API versions
On 07/27/2015 10:41 PM, Sean Dague wrote: On 07/27/2015 04:35 PM, Jim Rollenhagen wrote: Hi friends. Ironic implemented API micro versions in Kilo. We originally did this to allow for breaking changes in the API while allowing users to opt in to the breakage. Since then, we've had a default version for our client that we bump to something sensible with each release. Currently it is at 1.8. Negotiation is done with the server to figure out what is supported and adjust accordingly. Now we've landed a patch[0] with a new version (1.11) that is not backward compatible. It causes newly added Node objects to begin life in the ENROLL state, rather than AVAILABLE. This is a good thing, and people should want this! However, it is a breaking change. Automation that adds nodes to Ironic will need to do different things after the node-create call. Our API versioning scheme makes this opt-in (by specifying the API version). However, some folks have a problem with releasing this change as-is. The logic is that we might release a client that defaults to 1.11 or higher, or the user may request 1.12 later to get a new feature, thus breaking their application that enrolls nodes. This is clearly backwards. Users should read release notes and be aware of what changes between versions in the API. Users need to be aware of the fact that our API is versioned, and use that to their advantage. It seems to me that the goal of the version negotiation in our client has been to pretend that our API versions don't exist, from a user perspective. We need to stop doing this and force users to think about what they are doing when they interact with our API. It seems to me we have a few options here: 1) Default the python client and CLI to the earliest supported version. This will never break users by default. 2) Default the python client and CLI to use the special version 'latest'. This will always use the latest API version, and always break people when a new server version (that is not backwards compatible) is deployed. 3) Do what Nova does[1]. Default CLI to latest and python client to earliest. This assumes that CLI is typically used for one-time commands (and it isn't a big deal if we break a one-off command once), and the python client is used for applications. Actually what Nova is doing is slight different than this, the CLI will default to latest on the server. There will be an extra round trip to figure out what that is. And the CLI will (long term) just not present commands that aren't available at the server level you are talking to. Consider the CLI an auto negotiating microversion application of the python API client. And, realistically, should solve some of the issues of people running nova foo and getting cryptic errors from the server when they are hitting an old version of Nova that doesn't know how to foo. So the CLI should actually break less often, and will expose the most functionality you can get out of your cloud. What I find weird about this and similar approaches is that we treat CLI and any different from other ways to use API. And I *suspect* this is because we, the developers, use it the most and point newcomers to it. And I agree it's troublesome to explain that to use manage provision verb you have to provide --ironic-api-version 1.6. Or was 1.6 for inspect? Hmm, I really don't remember. CLI is not different, CLI is not special and CLI is not an auto negotiating microversion application of the python API client. By saying any of these we just refusing it eat our dog's food. If we consciously believe (I personally don't) that versioning is the right thing to do for people using our API - lets stop dodging it ourselves. Otherwise it looks like we've invented an architecture that people presumably dream of, but we don't know if it's even usable (to say nothing about useful). I tried writing versioning-aware code for our devstack yesterday, and it wasn't that nice and shiny. If our versioning requires negotiations, lets have it on API level, so that all users get it. Actually, server has the same level of information as the client. Let's have X-OpenStack-XXX-Version: negotiate figure out a proper version for us - or refuse to process a request if it's not possible. And if we think that versioning as it is now is unusable at all, lets rework the whole idea. tl;dr my vote if for CLI to strictly follow whatever server API does. That is, default to the lowest version, require explicit version argument to get new features. (it's up to a follow up discussion what to do during the deprecation period). -Sean __ 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] cross project communication: Return request-id to caller
On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote: Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +: Hi Devs, X-Openstack-Request-Id. We have analysed python-cinderclient, python-glanceclient, python-novaclient, python-keystoneclient and python-neutronclient to check the return types. There are 9 ways return values are returned from python clients: 1. List 2. Dict 3. Resource class object 4. None 5. Tuple 6. Exception 7. Boolean (True/False, for keystoneclient) 8. Generator (for list api's in glanceclient) 9. String (for novaclient) Out of 9 we have solution for all return types except generator. In case of glance-client list api's are returning generator which is immutable. So it is not possible to return request-id in this case, which is a blocker for adopting the solution. I have added detail analysis for above return types in etherpad [2] as solution #3. If you have any suggestion in case of generation type then please let me know. It should be possible to create a new class to wrap the existing generator and implement the iterator protocol [3]. [3] https://docs.python.org/2/reference/expressions.html#generator-iterator-methods Doug Unless I'm missing something I think we wouldn't even need to create a new class that implements the iterator protocol, we can just return a generator that generates from the other one. For example, for each of the requests, if we get the generator in variable *result* that returns dictionaries and we want to add *headers* to each dictionary: return (DictWithHeaders(resource, headers) for resource in result) Wouldn't that work? Cheers, Gorka. [1] http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-07-07-21.01.log.html [2] https://etherpad.openstack.org/p/request-id Thanks Best Regards, Abhishek Kekane __ 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] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature
Hi, I agree with Sergii, the patch had some problems only with tests which are already resolved. So I vote for FFE. P.S. We've just merged it. Regards, Alex On Mon, Jul 27, 2015 at 3:30 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have checked the code. After fixing tests, this patch maybe included to FFE as it has minimal impact on core functionality. +1 for FFE for https://review.openstack.org/#/c/196114/ -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Mon, Jul 27, 2015 at 1:38 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: There is a slight change needed, e.g. fixing of noop tests. Then we can merge it and accept for FFE, I think. On Fri, Jul 24, 2015 at 1:34 PM, Andrian Noga an...@mirantis.com wrote: Colleagues, actually, i'm tottaly agree with Mike. We can merge https://review.openstack.org/#/c/196114/ w/o additional Ceilometer support (will be moved to next release). So if we merge it today we dont need FFE for this feature. Regards, Andrian On Fri, Jul 24, 2015 at 1:18 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Since we are in FF state already, I'd like to have urgent estimate from one of fuel-library cores: - holser - alex_didenko - aglarendil - bogdando aglarendil is on vacation though. Guys, please take a look at https://review.openstack.org/#/c/196114/ - can we accept it as exception? Seems to be good to go... I still think that additional Ceilometer support should be moved to the next release. Thanks, On Thu, Jul 23, 2015 at 1:56 PM Mike Scherbakov mscherba...@mirantis.com wrote: Hi Andrian, this is High priority blueprint [1] for 7.0 timeframe. It seems we still didn't merge the main part [2], and need FF exception for additional stuff. The question is about quality. If we focus on enhancements, then we don't focus on bugs. Which whether means to deliver work with lower quality of slip the release. My opinion is rather don't give FF exception in this case, and don't have Ceilometer support for this new feature. [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role [2] https://review.openstack.org/#/c/196114/ On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote: Hi, The patch patch for fuel-library https://review.openstack.org/#/c/196114/ that implements 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires additional work to do (ceilometer support.), but as far as I can see it doesn't affect any other parts of the product. We plan to implement it in 3 working days (2 for implementation, 1 day for writing system test and test runs), it should not be hard since we already support ceilometer compute agent deployment on controller nodes. We need 1 DevOps engineer and 1 QA engineer to be engaged for this work. So I think it's ok to accept this feature as an exception for feature freeze. Regards, Andrian Noga Project manager Partner Centric Engineering Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen -- -- Regards, Andrian Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua __ 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ 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] [fuel] FF Exception request for Templates for Networking feature
We don't promise use Junja (or whatever) template language for this feature. If some jinja features allowed for parsing Network template -- it's a bug. We should check it and fix it. Only value substitutions should allow in the network templates. Yes, we just use jinja for values substitution. We could replace it with anything else suitable here. I don't see any reason to stick to jinja anyhow. That is not correct, every template has it's own syntax, so people have to care about specific implementation i.e. Jinja or ERB, and there will be confusion when somebody will try to use ERB specific features, and she/he will fail because you hide Jinja under ERB syntax. Format of template should be defined in docs finally. It is defined in spec and there is explanation in slides for Demo. It is not about jinja or ERB. It is just a token for substitution of values. There is no jinja nor ERB features granted within template language. Aleksey Kasatkin On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko svasile...@mirantis.com wrote: On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L e...@mirantis.com wrote: Hi Alexander, I don't agree with your statements [1] - I just uses % and % to substitute values. It's what templating is about, you have some text preprocessor to substitute values. Network templates feature don't mean any text preprocessor actions. Only value substitutions That is not ERB style template language. ERB uses the same syntax, hence it Is ERB style. ... hence it looks like ERB. not more. Not only ruby used for programming. Non only EBD -- is template language. ;) [2] - We are not using Jinja templating (it is just yaml file, not html template), we are using Jinja placeholder substitution. We *are using* jinja templating (I don't understand why you mention here html), with all it's features and here is the proof [1]. We don't promise use Junja (or whatever) template language for this feature. If some jinja features allowed for parsing Network template -- it's a bug. We should check it and fix it. Only value substitutions should allow in the network templates. [3] - Templates are for people who do not care about Jinja/ERB (maybe some familiar with Puppet/Chef), so no confusion. That is not correct, every template has it's own syntax, so people have to care about specific implementation i.e. Jinja or ERB, and there will be confusion when somebody will try to use ERB specific features, and she/he will fail because you hide Jinja under ERB syntax. I, partially, agree with you. But please honored to following facts: * In the deployers world used Jinja and ERB syntax. * ERB used more often, because Ansible (I don't know another popular deployers tools with Jinja templating) is to young. * Plenty of syntax features is a really hell. In the Network templates we don't suppose anything other than a simple substitution variable values. All logic of template processing implementing on Nailgun side. Now on the template parsing, later -- on the network manipulation class. Allowance of mix template language and Nailgun logic may lead to heavy diagnostic issues. Meantime I don't see any cases, where required something more, than substitution. /sv __ 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] [Neutron][L3] Representing a networks connected by routers
Also, in my proposal, it is more the router that is the grouping mechanism. I can't reconcile this with all of the points you make in the rest of your email. You want the collection of subnets that a network represents, but you don't want any other properties of the network. that the network object is currently the closest thing we have to representing the L3 part of the network. The L3 part of a network is the subnets. You can't have IP addresses without the subnets, you can't have floating IPs without the subnets, etc. A Neutron network is an L2 construct that encapsulates L3 things. By encapsulating them it also provides an implicit grouping. The routed networks proposal basically wants that implicit grouping without the encapsulation or the L2 part. We don't associate floating ips with a network because we want to arp for them. You're taking a consequence of the current model and its constraints and presenting that as the motivation for the model. We do so because there is no better L3 object to associate it to. Don't make assumptions about how people use floating IPs now just because it doesn't fit your use-case well. When an external network is implemented as a real Neutron network (leaving external_network_bridge blank like we suggest in the networking guide), normal ports can be attached and can co-exist/communicate with the floating IPs because it behaves as an L2 network exactly as implied by the API. The current model works quite well *if *your fabric can extend the external network everywhere it needs to be. If you don't want floating IPs to be reachable on the network they are associated with, then let's stop associating them with a network and instead start associating them with a group of subnets from which they allocate IPs. If we insist on a new object for the L3 part of a network then I'd say we had better have an L3 only port to connect to it. I don't think a new port type is necessary. We can just make the network ID nullable for a port to indicate that it isn't attached to a Neutron network since it won't be. It would then have a relationship to its associated subnet via fixed_ips as it does now. The subnet is not the L3 object that we're looking for. You may wish it were but that does not make it so. I never said a subnet is what we are looking for. The group of subnets is what we seem to be after. Ignoring the forced dependence on L2, the subnets still don't stand alone to describe just the L3 part, they must be linked to a network to make any sense. They don't need to be. If we made the network_id nullable on ports and subnets, we could still have ports associated with subnets. The network portion is the L2 portion. You don't want L2 so don't ask for the network. I understand that we want a way to reference collections of subnets and create ports that allocate IPs from them. Networks provide that now, but they imply an L2 domain for the ports, which we don't want. So we are trying to change what a network implies for this one special case, which is going to have ripple effects everywhere. Here are some areas where I can already see we will need special-casing: - DHCP agent scheduling - broadcast doesn't work on L3 networks, every compute node will need to use the direct tap attachment logic Neil brought up. - DHCP lease generation - a port can't get the normal subnet mask for the L3 network it's attached to because it would try to ARP for addresses in the same subnet, which are actually somewhere else. - Router interface attachment - what happens when a user attaches one interface to a regular network and one to an L3 network? Before they were all L2 networks so it didn't matter, but now none of the ports will be reachable on the L3 network without route table manipulation. - (or) Router creation - to avoid the above you can have different router types that can only attach to one or the other. - Every L2 attribute related to networks - we will need logic in the API that hides these fields or marks them as invalid and to generate an error if the user tries to update them. - Multi-provider segments - We can't let a user add an L3 segment to a network with L2 segments (e.g. VXLAN, VLAN). Same goes for the inverse. - Hierarchical port binding - coordinating ToRs for VXLAN+VLAN is l2 encap. L3 would need route propagation logic instead. - Every plugin, service, tool, etc, built on the assumption that a Neutron network is L2. - Port creation - If you aren't doing the full l3 like Neil's proposal, you need to intercept port creation requests and schedule the port to one of the underlying regular networks. The port then has a different network_id than the one requested, or we have more special-casing to hide that. All of those will be branches in the codebase to handle current Neutron networks vs L3 networks. If we go down this route, it will be even worse than the conditionals we have to
[Openstack] networking-ovs-dpdk
Hi, I was wondering if anyone was aware of the state of 'networking-ovs-dpdk' https://github.com/stackforge/networking-ovs-dpdk I've been trying to get it running with Kilo, but with little success so far. Can this just be installed on compute nodes, or does the controller require changes as well. I'm trying to understand if /usr/bin/networking-ovs-dpdk-agent should run in place of the neutron-openvswitch-agent? Dave Johnston ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack-operators] [puppet] module dependencies and different openstack versions
We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don¹t want it to mess with keystone (for one we don¹t support setting endpoints via an API) but also we don¹t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we¹ll may never move to the official keystone puppet module. The neutron module pulls in the vswitch module but we don¹t use vswitch and it doesn¹t seem to be a requirement of the module so maybe doesn¹t need to be in metadata dependencies? It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? Hi, In my experience (I am setting up a new environment) the modules can be used ³stand-alone². It is the OpenStack module itself that comes with a combined server example. The separate modules (nova, glance, etc) are very configurable and don¹t necessarily need to setup e.g. keystone. From the OpenStack module you can modify the profiles and it will not do the keystone stuff / database, etc.. E.g. Remove the ³:nova::keystone::auth² part in the nova profile. We use r10k to select which versions to install and it should be trivial to use Juno / Kilo stuff together (have not tested this myself). Regarding the vswich module I *guess* that that is regulated by the following: neutron/manifests/agents/ml2/ovs.pp: if $::neutron::params::ovs_agent_package So unsetting that variable should not pull the package. Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt
On 07/27/2015 11:42 PM, William M Edmonds wrote: python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? Even if swiftclient was removed from requirements.txt, I would still keep it as a hard Depends: in Debian, so it would not change anything for (Debian) users. Thomas __ 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] [fuel] FF Exception request for Templates for Networking feature
Completely agree with Sergey.
Currently network template uses ERB [1] style template language,
but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
the user
[1] - I just uses % and % to substitute values. That is not ERB style
template language.
[2] - We are not using Jinja templating (it is just yaml file, not html
template), we are using Jinja placeholder substitution. And in current code
we have a problem with content at first parsed from yaml and that parser
treats { and [ as a start if a dict or an array.
[3] - Templates are for people who do not care about Jinja/ERB (maybe some
familiar with Puppet/Chef), so no confusion.
On Tue, Jul 28, 2015 at 10:57 AM, Sergey Vasilenko svasile...@mirantis.com
wrote:
On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L e...@mirantis.com wrote:
Currently network template uses ERB [1] style template language,
but in fact it's Jinja [2], it was agreed to change it [3], no to confuse
the user, with ERB which is in fact jinja and doesn't have any ERB
features.
we have not so much syntax choices for convenient templating. Network
temptales will be used by system administrators.
The '% %' pair is a de-facto standart in this area. In the puppet
world. Not every system administrator will meaning ERB when seeing '% %'
pair.
Another pairs (i.e. '$ $' , ' ', etc) looks more
non-standart. Plenty of syntax features are annoy and make usability of
product less convenient.
I propose do not make extra essences on the clean area...
We never say in the docs about ERB. IMHO it's enough for leave '% %' as
is.
/sv
__
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
--
Kind Regards,
Alexandr Kostrikov,
Mirantis, Inc.
35b/3, Vorontsovskaya St., 109147, Moscow, Russia
Tel.: +7 (495) 640-49-04
Tel.: +7 (925) 716-64-52 %2B7%20%28906%29%20740-64-79
Skype: akostrikov_mirantis
E-mail: akostri...@mirantis.com elogut...@mirantis.com
*www.mirantis.com http://www.mirantis.ru/*
*www.mirantis.ru http://www.mirantis.ru/*
__
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] Python 3: 5 more projects with a py34 voting gate, only 4 remaing
I have updated it. Thank you for sharing a link. On Mon, Jul 27, 2015 at 3:44 PM, Victor Stinner vstin...@redhat.com wrote: Hi, On 27/07/2015 12:35, Roman Vasilets wrote: Hi, just what to share with you. Rally project also have voting py34 jobs. Thank you. Cool! I don't know if Rally port the Python 3 is complete or not, so I wrote work in progress. Please update the wiki page if the port is done: https://wiki.openstack.org/wiki/Python3#OpenStack_applications Victor __ 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] [Fuel][RabbitMQ][puppet] Kilo status of the heartbeats implementation
Folks, it seems the situation with Kilo support for RabbitMQ heartbeats should be elaborated. There is a bug [0] and a ML [1] related. The questions are: a) Should Fuel 7.0 with Kilo *explicitly* disable via puppet the upstream implementation of heartbeats for all OpenStack components (Neutron example [2]) and keep the MOS specific implementation of heartbeats configured the same way as it was for Juno? b) Or should we change nothing additionally allowing Oslo defaults for Kilo being populated for heartbeats settings out of box? Related question - what are upstream heartbeat defaults in MOS, do they differ to upstream ones? [0] https://bugs.launchpad.net/fuel/+bug/1477689 [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/068751.html [2] https://review.openstack.org/#/c/194381/ -- Best regards, Bogdan Dobrelya, Irc #bogdando __ 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] [fuel] FF Exception request for Templates for Networking feature
If we need only substitution, probably it's better to use standard templating in python [1], there is a way to redefine tokens, so you will be able to use % % syntax if you want to. [1] https://docs.python.org/2.6/library/string.html#template-strings https://docs.python.org/dev/library/string.html#template-strings [2] http://pymotw.com/2/string/#advanced-templates I think it's a better solution for this issue. /sv __ 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] Removing python-swiftclient from requirements.txt
From: Flavio Percoco fla...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/28/2015 07:36 AM Subject: Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt On 28/07/15 09:15 +, Kuvaja, Erno wrote: I do agree, we don’t depend or are cleaning the other clients out of the glance dependencies as well and I think swift should not be there either. The default store is filesystem store and if something is depending on the actual store clients it should be either glance_store or deployer (well for example our gate) glance itself should not have hard dependencies for ‘em. Agreed! William, would it be possible for you to spend some more time and create a single patch that removes all non-required dependencies? Cheers, Flavio This all started when I opened a bug [1] saying we needed to pull out oslo.vmware. Louis quickly threw up a patch [2] to remove that, but it was pointed out that swiftclient falls into the same category. So I created a separate patch to remove swiftclient [3]. Looking over what else is in requirements.txt and running a few searches, it looks like we may also be able to remove greenlet, kombu, and posix-ipc. Does anyone know if any of those (greenlet?) are needed for some reason other than a direct import? In which case I can add a comment to clarify that while I'm removing the others. I'd originally included the removal of oslo.vmware in [3], but I pulled that out thinking we could go ahead and merge [2] while we were having this discussion. But that didn't seem to fly, so I guess we want to make all these changes together under [3] and abandon [2]? Or should we go ahead and merge [2] while we're figuring out whether to remove greenlet, kombu, and posix-ipc as well under [3]? Just to be clear, it sounds to me like Flavio and Erno agree we should pull swiftclient out of requirements.txt immediately. I'd like to see a reply from Ian and Louis to round things out, make sure we're all on the same page and we won't be fighting over this in the review... [1] https://launchpad.net/bugs/1475737 [2] https://review.openstack.org/#/c/203200/ [3] https://review.openstack.org/#/c/203242/ - Erno From: William M Edmonds [mailto:edmon...@us.ibm.com] Sent: Monday, July 27, 2015 10:42 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? The optional dependencies spec [2] could definitely help here. I don't think we should have to wait for that, though. This is an issue we obviously already have today for other backends, which indicates folks can deal with it without an optional dependencies implementation. This would be a new concern for operators using the default swift backend, though. So how do we get the message out to those operators? And dowe need to put out a message about this change in Liberty and then wait until Mitaka to actually remove this, or can we go ahead and remove in Liberty? [1] https://review.openstack.org/#/c/203242 [2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/ optional-deps.html -Matthew __ 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 -- @flaper87 Flavio Percoco [attachment attdy18a.dat deleted by William M Edmonds/Raleigh/IBM] __ 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:
Re: [openstack-dev] [Ironic] Let's talk about API versions
On Tue, Jul 28, 2015 at 5:30 PM, Jim Rollenhagen j...@jimrollenhagen.com wrote: On Tue, Jul 28, 2015 at 09:19:46PM +, Devananda van der Veen wrote: On Tue, Jul 28, 2015 at 1:57 PM Jim Rollenhagen j...@jimrollenhagen.com wrote: On Tue, Jul 28, 2015 at 08:23:34PM +, Devananda van der Veen wrote: On Mon, Jul 27, 2015 at 4:58 PM Sean Dague s...@dague.net wrote: On 07/27/2015 07:10 PM, Jim Rollenhagen wrote: On Mon, Jul 27, 2015 at 03:28:49PM -0700, Clint Byrum wrote: Excerpts from Sean Dague's message of 2015-07-27 13:41:20 -0700: So the CLI should actually break less often, and will expose the most functionality you can get out of your cloud. What I find odd about this is that I want the CLI to be a faithful representation of the API, because many times the CLI is the only way I can access the API for integration purposes. Faithful representation of the API is an interesting way to put it; it is a faithful representation either way. This way is a representation of the newest state of the API. It sounds like you're expecting a representation of the oldest state, or the state that you're used to (the hardest to predict). So lets say I just want a very simple bash script to do something with nodes: id=$(ironic node-create ...|getid) while true ; do state=$(ironic node-get $id | get_state) case $state in AVAILABLE) break;; ERROR) # retry or something ;; *) splode(UNKNOWN STATE) ;; esac done Then the script is going to start exploding with a CLI that shows me ENROLL state. So I'm not sure having the CLI go faster than the python client is a great way to avoid breakage. It might be the opposite of that, and that might just be a large burden on users. I tend to think that folks using the CLI for automation should be pinning the version in that automation. A quick IRONIC_API_VERSION=1.8 or whatever would solve this problem. When new versions are available, read the notes for that version and adjust your code as necessary. Or just leave it at the same version until it breaks. :) Yeh, it's a cli, not a bash API. Having had to maintain devstack exercise code for a while, I'll tell you that the above is just a time bomb waiting to go off. None of the CLIs have that kind of contract, nor should they. Inflicting the bad UX of today on future generations because someone thinks, incorrectly, that it's a bash SDK is not a good trade off. And people script against that CLI all. the. time. Is it pretty? No. But is it something that people do? Yep. Does that mean we should try to care? Yea, I think so, and I think that means we should try to avoid breaking it when reasonably possible. If you want to pin things, explicitly, like jroll said, do that. And microversions lets you until your clouds uplift past your legacy code. if you want to pin the version != all users must explicitly specify the version I believe Jim is advocating for the latter. I'm advocating for the former. The problem that I'm now seeing is you're advocating not just that people should be able to pin a version. You're advocating for: 1. People don't need to pin the version. Fine. 1.1. Side note: perhaps you're actually advocating for people should not need to pin the version? It's starting to sound that way. 2. The client should always default to the most recent compatible version. Fine. 3. We should never break a user. Fine. 4. 1-3 must all be true always. Not fine. We can't reasonably make progress while having the latest API version be compatible with the previous API version. The combination above breaks down when we also want to continue to produce software (preferably quickly). We need to let one of those things go; they can't all be true at the same time. I think the best thing to let go is 1 or 2, personally. Where we are today is letting 3 go, and that's why we're stuck here. Mmmm, close. I think I expanded on that in my last email (replying to Dmitry) ... but... tldr; 1. yes 2. no -- the client should default to the minimum supported version. We got that wrong previously, and that's what is hurting us now. So if we do this, simply shipping the code doesn't break anyone. Nobody has disagreed on this yet, best I can tell. So let's ship some code. :) // jim I'm not sure we can just ship some code, unless I've missed something in the discussion, at some point a user/operator workflow could still break if a future user client is upgraded with the current
Re: [openstack-dev] [Ironic] Let's talk about API versions
On Tue, Jul 28, 2015 at 09:55:03PM -0400, Julia Kreger wrote: So if we do this, simply shipping the code doesn't break anyone. Nobody has disagreed on this yet, best I can tell. So let's ship some code. :) // jim I'm not sure we can just ship some code, unless I've missed something in the discussion, at some point a user/operator workflow could still break if a future user client is upgraded with the current server code. Now if this is something the Ironic community is willing to accept, as I personally thought was originally the case, then that is another matter. My $0.02 is that forcing a workflow change should be handled with a deprecation period while avoiding the hard breaking change for the user workflow, because it is akin to taking away a feature, or in this case, forcing the user to use a feature they may not want nor need. What if we revert 523da21cd3f5fc3299f9b91ac6d885f0fb54eddb and 1410e59228c3835cfc4f89db1ec482137a3cfa10 in order to cut a release, then revert the reverts while layering on top a server side fix to remove the hard break for users? So that's the other part here - even if we have a way to make 1.11 easier for users to swallow, we can't. There are people that deploy master out there, so we need to treat master as already released. If we change how the enroll API works (again), that needs to be 1.12. If we revert it, that also needs to be 1.12, with 1.11 carrying the current code. // jim __ 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][lbaas] Horizon support for neutron-lbaas v2
Hi Folks, Screenshots are uploaded. Please review and leave your feedback: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, vivek From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:14 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Doug. We are planning to submit initial review version by end of day today. Also, we will be uploading LBaaS wireframes for review here: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, Vivek From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 The repo is now live. Initial review is here: https://review.openstack.org/#/c/206757 , please make any near-term reviews dependent on that, unless you’re replacing the skeleton. Vivek, when do you think we can get some initial code in there to start iterating on? Thanks, doug On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 15, 2015 at 10:35 AM To: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a easy way to de-couple lbaas dashboard from horizon? I think that will simplify development efforts. What does it take to separate lbaas dashboard from horizon? Thanks, Vivek From: Akihiro Motoki amot...@gmail.commailto:amot...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Another option is to create a project under openstack. designate-dashboard project takes this approach, and the core team of the project is both horizon-core and designate-core. We can do the similar approach. Thought? I have one question. Do we have a separate place forever or do we want to merge horizon repo once the implementation are available. If we have a separate repo for LBaaS v2 panel, we need to release it separately. I am not sure I am available at LBaaS meeting, but I would like to help this efforts as a core from horizon and
Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2
Thanks Doug. We are planning to submit initial review version by end of day today. Also, we will be uploading LBaaS wireframes for review here: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, Vivek From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 The repo is now live. Initial review is here: https://review.openstack.org/#/c/206757 , please make any near-term reviews dependent on that, unless you’re replacing the skeleton. Vivek, when do you think we can get some initial code in there to start iterating on? Thanks, doug On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 15, 2015 at 10:35 AM To: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a easy way to de-couple lbaas dashboard from horizon? I think that will simplify development efforts. What does it take to separate lbaas dashboard from horizon? Thanks, Vivek From: Akihiro Motoki amot...@gmail.commailto:amot...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Another option is to create a project under openstack. designate-dashboard project takes this approach, and the core team of the project is both horizon-core and designate-core. We can do the similar approach. Thought? I have one question. Do we have a separate place forever or do we want to merge horizon repo once the implementation are available. If we have a separate repo for LBaaS v2 panel, we need to release it separately. I am not sure I am available at LBaaS meeting, but I would like to help this efforts as a core from horizon and neutron. Akihiro 2015-07-15 1:52 GMT+09:00 Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com: I’d be good submitting it to the neutron-lbaas repo, under a horizon/ directory. We can iterate there, and talk with the Horizon team about how best to integrate. Would that work? Thanks, doug On Jul 13, 2015, at 3:05 PM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: Hi German, We integrated UI with LBaaS v2 GET APIs. We have created all panels for CREATE and UPDATE as well. Plan is to share our code with community on stackforge for more collaboration from the community. So far Ganesh from cisco has shown interest in
Re: [openstack-dev] [horizon] [stable] Freeze exception
The patch fixes a bug that prevent user from using N1KV network, and the change is low risk and minimal. I think it would be good to backport. Thanks, Lin On Tue, Jul 28, 2015 at 3:20 PM, Saksham Varma (sakvarma) sakva...@cisco.com wrote: Hi all, I would like to request for a freeze exception for the this bug: https://bugs.launchpad.net/horizon/+bug/1474618 This is the patch: https://review.openstack.org/#/c/206184/ It’s a critical bug, which has already been merged to master, and needs to be back ported to kilo. Thanks, Saksham __ 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] [Fuel] changing assigned VLANs after install
Can we add this to the official documentation? On 07/27/2015 08:39 AM, Alexander Liemieshko wrote: Changing VLAN ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [fuel] Fuel plugin as docker containers images
Andrew, On deployed env. Yep, plugin can install docker, but docker installation usually harder, than just 'apt-get docker'. That's why I'm asking about fuel team plans. The main (and the real one for now) reason to have a VSM in container - is to not poisoning controller node with it outdated dependencies. I think that fixing dependency hell is one of main reason for using containers at all. Yep, that is clear, that container and plugin, as results, would be quite large. Thanks On Tue, Jul 28, 2015 at 11:41 PM, Andrew Woodward xar...@gmail.com wrote: I'm still confused are you wanting to add a container to the master node, or a deployed env? For the master node, the latest fuel-plugin-builder allows for post-install scripts, you could load a container image from here For nodes in a deployed ENV, there is no formal target to support containers, you would need to install the container manager and containers yourself. However I would note that not packaging the applications dependencies because it's in a container is not a good practice as it quickly becomes very difficult to work with versioning and updates. It may be acceptable for a dev build of the plugin, but should be avoided in validated versions of the plugin. The container its self should also be contained within a package so that it's versioning can be tracked with operator familiar tools. Lastly, containers with python are quite large, so if you can get the versioning to work I'd avoid putting it into a container all together as you will end up with 150-300mb container mostly just because of python. On Tue, Jul 28, 2015 at 7:26 AM Konstantin Danilov kdani...@mirantis.com wrote: Evgene, I'm sure you understand this, but just to be clear - now FUEL uses containers on master node, not on cluster nodes. I'm asking about plugin containers on cluster nodes. Yep, there a particular example - VSM (Intel ceph management tool). It requires a set of packages, like python2.6, old django, etc, which I would rather not install on master node directly. Thanks On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L e...@mirantis.com wrote: Hi Konstantin, I'm not sure if we track such feature anywhere. But one of the reasons to use containers on the master was to deliver plugin specific containers, so they don't intersect and don't break Fuel master dependencies. Do you have some specific use case for that? Thanks, On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov kdani...@mirantis.com wrote: Hi, Is there a plans to allow plugin to be delivered as docker container images? Thanks -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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] Removing python-swiftclient from requirements.txt
Excerpts from William M Edmonds's message of 2015-07-28 18:34:29 -0400: From: Flavio Percoco fla...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/28/2015 07:36 AM Subject: Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt On 28/07/15 09:15 +, Kuvaja, Erno wrote: I do agree, we don’t depend or are cleaning the other clients out of the glance dependencies as well and I think swift should not be there either. The default store is filesystem store and if something is depending on the actual store clients it should be either glance_store or deployer (well for example our gate) glance itself should not have hard dependencies for ‘em. Agreed! William, would it be possible for you to spend some more time and create a single patch that removes all non-required dependencies? Cheers, Flavio This all started when I opened a bug [1] saying we needed to pull out oslo.vmware. Louis quickly threw up a patch [2] to remove that, but it was pointed out that swiftclient falls into the same category. So I created a separate patch to remove swiftclient [3]. Looking over what else is in requirements.txt and running a few searches, it looks like we may also be able to remove greenlet, kombu, and posix-ipc. Does anyone know if any of those (greenlet?) are needed for some reason other than a direct import? In which case I can add a comment to clarify that while I'm removing the others. I'd originally included the removal of oslo.vmware in [3], but I pulled that out thinking we could go ahead and merge [2] while we were having this discussion. But that didn't seem to fly, so I guess we want to make all these changes together under [3] and abandon [2]? Or should we go ahead and merge [2] while we're figuring out whether to remove greenlet, kombu, and posix-ipc as well under [3]? Just to be clear, it sounds to me like Flavio and Erno agree we should pull swiftclient out of requirements.txt immediately. I'd like to see a reply from Ian and Louis to round things out, make sure we're all on the same page and we won't be fighting over this in the review... I replied on both patches, but I'll repeat it here for a broader audience: Please set up an extras entry for each backend instead of just removing the dependencies. That will signal to users that you know what dependencies there are for a backend, but that they are optional, and still allow someone to do the equivalent of pip install glance[vmware] or pip install glance[swift] to get those dependencies. Nova and oslo.versionedobjects have examples in their setup.cfg if you need a template. I didn't mention in the reviews, but this will also make integration tests in our gate easier, since you can put .[vmware] or .[swift] in the tox.ini to pull in those dependencies. Doug [1] https://launchpad.net/bugs/1475737 [2] https://review.openstack.org/#/c/203200/ [3] https://review.openstack.org/#/c/203242/ - Erno From: William M Edmonds [mailto:edmon...@us.ibm.com] Sent: Monday, July 27, 2015 10:42 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? The optional dependencies spec [2] could definitely help here. I don't think we should have to wait for that, though. This is an issue we obviously already have today for other backends, which indicates folks can deal with it without an optional dependencies implementation. This would be a new concern for operators using the default swift backend, though. So how do we get the message out to those operators? And dowe need to put out a message about this change in Liberty and then wait until Mitaka to actually remove this, or can we go ahead and remove in Liberty? [1] https://review.openstack.org/#/c/203242 [2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/ optional-deps.html
Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt
Doug, I believe our glance friends are not the only project with some open questions on dealing with the required dependency for optional plugin use-case. You've made a recommendation to leverage some python tooling functionality that I'm not familiar with. I was hoping I could probe you to elaborate so I can try and educate myself more? ... inline On Tue, Jul 28, 2015 at 4:55 PM, Doug Hellmann d...@doughellmann.com wrote: Please set up an extras entry for each backend instead of just removing the dependencies. That will signal to users that you know what dependencies there are for a backend, You referenced nova [1], and oslo.versionedobjects [2] for examples - but I'd be more curious for the documentation if you have any idea where I might look for it? Is this a feature of pkg_resources, distutils, setuptools, pbr? What exactly does describing dependencies via this extras key afford? but that they are optional, and still allow someone to do the equivalent of pip install glance[vmware] or pip install glance[swift] to get those dependencies. I'm not familiar with that syntax for pip or it's equivalent! That sounds awesome! Can you do like [extras:pluginname] in your setup.cfg and pip install project[pluginname] just works!? OMGBBQ! Nova and oslo.versionedobjects have examples in their setup.cfg if you need a template. Hrm... I'm missing how either one of those setup.cfg's [1, 2] include an example relevant to this use-case (i.e. required dependency for optional backend plugin)? I didn't mention in the reviews, but this will also make integration tests in our gate easier, since you can put .[vmware] or .[swift] in the tox.ini to pull in those dependencies. Hrm... yes testing. So that's part just a new -e for the tox.ini - but I'm not quite sure I follow how each environment would specify different dependencies for the virtualenv? I hope you can point me to some more information on the subject. Thank you very much for pushing this out to a wider audience, clayg 1. https://github.com/openstack/nova/blob/master/setup.cfg 2. https://github.com/openstack/oslo.versionedobjects/blob/master/setup.cfg#L25 __ 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] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights
Hi Kyle, Neutron Cores and Infra Team, a) Was there a final decision/conclusion on the matter? b) Do we make jodavidg’s suggestion[1] a rule and we change it in Neutron third party policy[2]. c) I can’t see any recent changes in policy[2] and if there are no plans to change the guidelines on how/whether to get voting rights Infra please continue with the setup of the voting rights for Intel Networking CI. I’ll disable -1 voting depending on b). [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068202.html [2] http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/thirdparty-ci.rst From: Znoinski, Waldemar Sent: Friday, June 26, 2015 9:58 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: RE: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights Thanks Kyle. Yes, I’d wait with further processing of this request till we have a consensus on the thread. From: Kyle Mestery [mailto:mest...@mestery.com] Sent: Thursday, June 25, 2015 8:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-infra][Infra][Neutron] Nominating intel-networking-ci for voting rights On Wed, Jun 24, 2015 at 12:22 PM, Znoinski, Waldemar waldemar.znoin...@intel.commailto:waldemar.znoin...@intel.com wrote: Hi Kyle and Neutron Cores, I would like to nominate Intel-Networking-CI (https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-Networking-CI) to have voting (non-gating) rights. It’s been commenting on each proposed patch-set in Neutron since Feb 10 ’15: https://review.openstack.org/#/q/reviewer:%22Intel+Networking+CI+%253Copenstack-networking-ci%2540intel.com%253E%22,n,00333e9b0002530a Any issues with it were resolved within 1-2 working days. A recent cut from history – although a full one is at https://review.openstack.org/#/q/reviewer:%22Intel+Networking+CI+%253Copenstack-networking-ci%2540intel.com%253E%22,n,z : https://review.openstack.org/#/c/194441/ - http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/41/194441/6/ https://review.openstack.org/#/c/173001/ - http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/01/173001/14/ https://review.openstack.org/#/c/195218/ - http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/18/195218/1/ https://review.openstack.org/#/c/194455/ - http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/55/194455/4/ https://review.openstack.org/#/c/195045/ - http://intel-openstack-ci-logs.ovh/networking-ci/refs/changes/45/195045/1/ Let me know if there are any other requirements we should be fulfilling and/or approve if no questions. +1 from me. See the recent thread [1] about this topic, however, and decide if you really want to vote or not. Thanks! Kyle [1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067992.html Waldek -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. __ 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-operators] [nova] Quota per flavor, availability zone or a combination
A lot of us have had use cases where a cloud-admin wanted to set - 1. Quota per flavor 2. Quota per Availability Zone 3. Quota per flavor_az (flavor and availability zone) All of these use cases requires an update to the quota module. Currently, quota module only tracks static resources like core, ram, disk which are hardcoded in the quota module. All quota calculations during quota commit is made using static resources. If we need the ability to set Quota per X, we need the ability to add a quota resource dynamically during quota-update. So, Vliobh Meshram, Josh Harlow and myself have been working on a spec to support dynamic quota resources in nova, which will staisfy all use cases above. Here is the link to the spec - https://review.openstack.org/#/c/206160/ This spec talks about 1. Providing capability to create dynamic quota resource 2. Update metadata (flavor and AZ) for dynamic quota resource 3. Incrementing/Decrementing dynamic quota resource value during instance creation and deletion. It would be great if we could get input from dev and operators on the spec. This is a problem that we have been trying hard at Yahoo to solve and we would love to get your feedback. Operators mailing list was not included in my email (sent yesterday) to dev mailing list. So, sending this email to operators mailing list. Thanks, Meghal ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers
If that's the case, then I'd say let's just solve this right way and create a new construct rather... Ryan Moats Kevin Benton blak...@gmail.com wrote on 07/28/2015 06:44:53 PM: From: Kevin Benton blak...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 07/28/2015 06:46 PM Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers We need to work on that code quite a bit anyway for other features (get me a network, VLAN trunk ports) so adding a different parameter shouldn't be bad. Even if Nova doesn't initially buy in, we can always pre-create the port and pass it to Nova boot as a UUID. On Tue, Jul 28, 2015 at 6:15 AM, Ryan Moats rmo...@us.ibm.com wrote: Kevin, doesn't this in itself create technical debt on the nova side in the sense of what an instance attaches to? I agree that it looks like less technical debt than conditionally redefining a network, but without nova buy-in, it looks like a non-starter... Ryan Kevin Benton blak...@gmail.com wrote on 07/28/2015 02:15:13 AM: [snip] I would rather see something to reference a group of subnets that can be used for floating IP allocation and port creation in lieu of a network ID than the technical debt that conditionally redefining a network will bring. __ 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 -- Kevin Benton __ 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] [neutron][lbaas] Horizon support for neutron-lbaas v2
One of the features I'm looking forward to most in v2 is multiple ports on one lb. Like 80 and 443. The ui doesnt look to easily support that? Thanks, Kevin From: Jain, Vivek Sent: Tuesday, July 28, 2015 6:19:25 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi Folks, Screenshots are uploaded. Please review and leave your feedback: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, vivek From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:14 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Doug. We are planning to submit initial review version by end of day today. Also, we will be uploading LBaaS wireframes for review here: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, Vivek From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 The repo is now live. Initial review is here: https://review.openstack.org/#/c/206757 , please make any near-term reviews dependent on that, unless you’re replacing the skeleton. Vivek, when do you think we can get some initial code in there to start iterating on? Thanks, doug On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 15, 2015 at 10:35 AM To: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a easy way to de-couple lbaas dashboard from horizon? I think that will simplify development efforts. What does it take to separate lbaas dashboard from horizon? Thanks, Vivek From: Akihiro Motoki amot...@gmail.commailto:amot...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Another option is to create a project under openstack. designate-dashboard project takes this approach, and the core team of the
Re: [openstack-dev] Barbican : Unable to create the secret after Integrating Barbican with HSM HA
Thanks John for your response :) I am currently working on the reconfiguring the HSM in different way. Shall let you know once my stuff is working. Thanks and Regards, Asha Seshagiri On Tue, Jul 28, 2015 at 11:31 AM, John Vrbanac john.vrba...@rackspace.com wrote: Asha, I'm not sure what went wrong. Something must have happened during your HA setup. You might check a couple different things, first you might check out your HA policies and HA group setup. The other thing you might make sure is that you only generate one mkek and hmac on one hsm (I use direct slot and not the HA virtual slot for this) and then replicate (vtl haAdmin -synchronize). If the HA group is setup properly it should replicate your mkek and hmac across the other HSMs in the HA group. As a side note, the pkcs11 plugin in Barbican currently retrieves the mkek and hmac by label, so make sure you don't have multiple keys in the HSM with the same label. John Vrbanac -- *From:* Asha Seshagiri asha.seshag...@gmail.com *Sent:* Tuesday, July 28, 2015 9:22 AM *To:* John Vrbanac *Cc:* openstack-dev; John Wood; Douglas Mendizabal; Reller, Nathan S. *Subject:* Re: Barbican : Unable to create the secret after Integrating Barbican with HSM HA Hi John , Any help would highly be appreciated. Thanks and Regards, Asha Seshagiri On Mon, Jul 27, 2015 at 3:10 PM, Asha Seshagiri asha.seshag...@gmail.com wrote: Hi John , Thanks a lot for providing me the response:) I followed the link[1] for configuring the HA SETUP [1] : http://docs.aws.amazon.com/cloudhsm/latest/userguide/ha-setup.html the final step in the above link is haAdmin command which is run on the client side(on Barbican) . The slot 6 is the virtual slot(only on the client side and not visible on LUNA SA ) and 1 and 2 are actual slots on LUNA SA HSM Please find the response below : [root@HSM-Client bin]# ./vtl haAdmin show HA Global Configuration Settings === HA Proxy: disabled HA Auto Recovery: disabled Maximum Auto Recovery Retry: 0 Auto Recovery Poll Interval: 60 seconds HA Logging: disabled Only Show HA Slots: no HA Group and Member Information HA Group Label: barbican_ha HA Group Number: 1489361010 HA Group Slot #: 6 Synchronization: enabled Group Members: 489361010, 489361011 Standby members: none Slot # Member S/N Member Label Status == == == 1 489361010 barbican2 alive 2 489361011 barbican3 alive After knowing the virtual slot HA number , I ran the pkcs11-key-generation with slot number 6 which did create mkek and hmac in slot/partition 1 and 2 automatically . I am not sure why do we have to replicate the keys between partitions? Configured the slot 6 on the barbican.conf as mentioned in my first email Not sure what might be the issue and It would be great if you could tell me the steps or where I would have gone wrong. Thanks and Regards, Asha Seshagiri On Mon, Jul 27, 2015 at 2:36 PM, John Vrbanac john.vrba...@rackspace.com wrote: Asha, I've used the Safenet HSM HA virtual slot setup and it does work. However, the setup is very interesting because you need to generate the MKEK and HMAC on a single HSM and then replicate it to the other HSMs out of band of anything we have in Barbican. If I recall correctly, the Safenet Luna docs mention how to replicate keys or partitions between HSMs. John Vrbanac -- *From:* Asha Seshagiri asha.seshag...@gmail.com *Sent:* Monday, July 27, 2015 2:00 PM *To:* openstack-dev *Cc:* John Wood; Douglas Mendizabal; John Vrbanac; Reller, Nathan S. *Subject:* Barbican : Unable to create the secret after Integrating Barbican with HSM HA Hi All , I am working on Integrating Barbican with HSM HA set up. I have configured slot 1 and slot 2 to be on HA on Luna SA set up . Slot 6 is a virtual slot on the client side which acts as the proxy for the slot 1 and 2. Hence on the Barbican side , I mentioned the slot number 6 and its password which is identical to that of the passwords of slot1 and slot 2 in barbican.conf file. Please find the contents of the file : # = Secret Store Plugin === [secretstore] namespace = barbican.secretstore.plugin enabled_secretstore_plugins = store_crypto # = Crypto plugin === [crypto] namespace = barbican.crypto.plugin enabled_crypto_plugins = p11_crypto [simple_crypto_plugin] # the kek should be a 32-byte value which is base64 encoded kek = 'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=' [dogtag_plugin] pem_path = '/etc/barbican/kra_admin_cert.pem' dogtag_host = localhost dogtag_port = 8443 nss_db_path = '/etc/barbican/alias' nss_db_path_ca = '/etc/barbican/alias-ca' nss_password = 'password123' simple_cmc_profile =
Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers
We need to work on that code quite a bit anyway for other features (get me a network, VLAN trunk ports) so adding a different parameter shouldn't be bad. Even if Nova doesn't initially buy in, we can always pre-create the port and pass it to Nova boot as a UUID. On Tue, Jul 28, 2015 at 6:15 AM, Ryan Moats rmo...@us.ibm.com wrote: Kevin, doesn't this in itself create technical debt on the nova side in the sense of what an instance attaches to? I agree that it looks like less technical debt than conditionally redefining a network, but without nova buy-in, it looks like a non-starter... Ryan Kevin Benton blak...@gmail.com wrote on 07/28/2015 02:15:13 AM: [snip] I would rather see something to reference a group of subnets that can be used for floating IP allocation and port creation in lieu of a network ID than the technical debt that conditionally redefining a network will bring. __ 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 -- Kevin Benton __ 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-operators] [neutron][extra-dhcp-opt]How to use extra-dhcp-opt when the opt_name=static-route and opt_name=classless-static-route?
Hi all, When using the extr-dhcp-opt, I find the function works well when opt_name=mtu and opt_name=router. The vm created will use the assigned mtu value or the assigned gateway. But when I create port using --extra-dhcp-opt opt_name=static-route,opt_value=192.168.0.0/24 2.2.2.2 the vm won't use this route. The opt_name=classless-static-route shows the same result.Do i use them in the wrong way? Any suggestion will be grateful. Thank you.___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [fuel] Fuel plugin as docker containers images
Evgene, I'm sure you understand this, but just to be clear - now FUEL uses containers on master node, not on cluster nodes. I'm asking about plugin containers on cluster nodes. Yep, there a particular example - VSM (Intel ceph management tool). It requires a set of packages, like python2.6, old django, etc, which I would rather not install on master node directly. Thanks On Tue, Jul 28, 2015 at 10:47 AM, Evgeniy L e...@mirantis.com wrote: Hi Konstantin, I'm not sure if we track such feature anywhere. But one of the reasons to use containers on the master was to deliver plugin specific containers, so they don't intersect and don't break Fuel master dependencies. Do you have some specific use case for that? Thanks, On Mon, Jul 27, 2015 at 4:58 PM, Konstantin Danilov kdani...@mirantis.com wrote: Hi, Is there a plans to allow plugin to be delivered as docker container images? Thanks -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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 -- Kostiantyn Danilov aka koder.ua Principal software engineer, Mirantis skype:koder.ua http://koder-ua.blogspot.com/ http://mirantis.com __ 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][L3] Representing a networks connected by routers
Kevin, doesn't this in itself create technical debt on the nova side in the sense of what an instance attaches to? I agree that it looks like less technical debt than conditionally redefining a network, but without nova buy-in, it looks like a non-starter... Ryan Kevin Benton blak...@gmail.com wrote on 07/28/2015 02:15:13 AM: [snip] I would rather see something to reference a group of subnets that can be used for floating IP allocation and port creation in lieu of a network ID than the technical debt that conditionally redefining a network will bring. __ 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] [infra][puppet] Keeping common set of file synchronized across puppet modules
In PuppetOpenstack we have a common set of filesthat are shared across all our modules. We would like to have an easy way to keep those set of filessynchronized. Based on some discussions on #openstack-infra, infra might also be interested by this problematic. They are (at least) two approaches for that matter : * The Puppet community have developed a tool specifically for that matter called modulesync[1] widely used in the Puppet community. One needs to create a repo[2] with a specific layout, and then running msync will ensure all files across every modules specified in the managed_modules.yml file are synchronized, and if not will create a commit to synchronized them. * The openstack-infra way : Based on my understanding, we would have to create a repo much like this one[3] with all the common files in there. puppet_update.sh[4] would need to be modified so that in the for loop all the common files are copied and then the regular git workflow happens. The advantage I see relying on modulesync is that all the logic is taken care of by modulesync, and the logic of the hook itself holds in one line[5], making it pretty simple, to follow, understand and eventually debug. A review have been submitted[6] on infra, relying on a propose_msync_update.sh script rather than the propose_update.sh script, one of the comment was I suggest to enhance that file (ie. jenkins/scripts/propose_update.sh) instead of creating a new syncing setup. As I see it, using msync and propose_update.sh while keeping the pattern it has today is incompatible - as they overlap a lot (projects.txt vs. managed_modules.yml, the git worflow, etc..) hence I would rather stick with the propose_msync_update.sh patch. Using just the bit of modulesync for its templating feature and relying on propose_update.sh for the git workflow sounds a bit over complicated here. Though my hope would be havingboth PuppetOpenstack and Infra to rely on the same tooling here as it will make it consistent.I'd like to have your feedbacks/ideas, on how best to deal with that problematic. Thank you, [1] https://github.com/puppet-community/modulesync [2] https://github.com/openstack/puppet-modulesync-configs [3] https://github.com/pabelanger/puppet-modules-sync [4] https://github.com/openstack-infra/project-config/blob/master/jenkins/scripts/propose_update.sh [5] https://review.openstack.org/gitweb?p=openstack-infra/project-config.git;a=blob;f=jenkins/scripts/propose_msync_update.sh;h=602615f41a6c09741f953e3310bf1512033dde0c;hb=7ff5fa189392709486bc544273a1949ece4da049#l82 [6] https://review.openstack.org/#/c/189216 -- Yanis Guenane __ 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] Announcing HyperStack project
Thanks Matt, though proposed but nova team think that this should belong to Magnum ;-) We can check where is the best place for hyper. 2015-07-27 16:06 GMT-04:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 7/26/2015 11:43 PM, Adrian Otto wrote: Peng, For the record, the Magnum team is not yet comfortable with this proposal. This arrangement is not the way we think containers should be integrated with OpenStack. It completely bypasses Nova, and offers no Bay abstraction, so there is no user selectable choice of a COE (Container Orchestration Engine). We advised that it would be smarter to build a nova virt driver for Hyper, and integrate that with Magnum so that it could work with all the different bay types. It also produces a The nova-hyper virt driver idea has already been proposed: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067501.html situation where operators can not effectively bill for the services that are in use by the consumers, there is no sensible infrastructure layer capacity management (scheduler), no encryption management solution for the communication between k8s minions/nodes and the k8s master, and a number of other weaknesses. I’m not convinced the single-tenant approach here makes sense. To be fair, the concept is interesting, and we are discussing how it could be integrated with Magnum. It’s appropriate for experimentation, but I would not characterize it as a “solution for cloud providers” for the above reasons, and the callouts I mentioned here: http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html Positioning it that way is simply premature. I strongly suggest that you attend the Magnum team meetings, and work through these concerns as we had Hyper on the agenda last Tuesday, but you did not show up to discuss it. The ML thread was confused by duplicate responses, which makes it rather hard to follow. I think it’s a really bad idea to basically re-implement Nova in Hyper. Your’e already re-implementing Docker in Hyper. With a scope that’s too wide, you won’t be able to keep up with the rapid changes in these projects, and anyone using them will be unable to use new features that they would expect from Docker and Nova while you are busy copying all of that functionality each time new features are added. I think there’s a better approach available that does not require you to duplicate such a wide range of functionality. I suggest we work together on this, and select an approach that sets you up for success, and gives OpenStack could operators what they need to build services on Hyper. Regards, Adrian On Jul 26, 2015, at 7:40 PM, Peng Zhao p...@hyper.sh mailto:p...@hyper.sh wrote: Hi all, I am glad to introduce the HyperStack project to you. HyperStack is a native, multi-tenant CaaS solution built on top of OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper + Kubernetes + Cinder + Neutron. HyperStack is different from Magnum in that HyperStack doesn't employ the Bay concept. Instead, HyperStack pools all bare-metal servers into one singe cluster. Due to the hypervisor nature in Hyper, different tenants' applications are completely isolated (no shared kernel), thus co-exist without security concerns in a same cluster. Given this, HyperStack is a solution for public cloud providers who want to offer the secure, multi-tenant CaaS. Ref: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png The next step is to present a working beta of HyperStack at Tokyo summit, which we submitted a presentation: https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030 . Please vote if you are interested. In the future, we want to integrate HyperStack with Magnum and Nova to make sure one OpenStack deployment can offer both IaaS and native CaaS services. Best, Peng -- Background --- Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker images with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different from the minimalist Linux distros like CoreOS by that Hyper runs on the physical box and load the Docker images from the metal into the VM instance, in which no guest OS is present. Instead, Hyper boots a minimalist kernel in the VM to host the Docker images (Pod). With this approach, Hyper is able to bring some encouraging results, which are similar to container: - 300ms to boot a new HyperVM instance with a pod of Docker images - 20MB for min mem footprint of a HyperVM instance - Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for scheduling - Immune from the shared
Re: [openstack-dev] Announcing HyperStack project
Thanks Adrian, we can talk later in the IRC meeting. 2015-07-28 4:07 GMT-04:00 Adrian Otto adrian.o...@rackspace.com: Jay, Yes, it is on the agenda. Thanks, Adrian On Jul 27, 2015, at 8:32 AM, Jay Lau jay.lau@gmail.com wrote: Adrian, Can we put hyper as a topic for this week's (Tomorrow) meeting? I want to have some discussion with you. Thanks 2015-07-27 0:43 GMT-04:00 Adrian Otto adrian.o...@rackspace.com: Peng, For the record, the Magnum team is not yet comfortable with this proposal. This arrangement is not the way we think containers should be integrated with OpenStack. It completely bypasses Nova, and offers no Bay abstraction, so there is no user selectable choice of a COE (Container Orchestration Engine). We advised that it would be smarter to build a nova virt driver for Hyper, and integrate that with Magnum so that it could work with all the different bay types. It also produces a situation where operators can not effectively bill for the services that are in use by the consumers, there is no sensible infrastructure layer capacity management (scheduler), no encryption management solution for the communication between k8s minions/nodes and the k8s master, and a number of other weaknesses. I’m not convinced the single-tenant approach here makes sense. To be fair, the concept is interesting, and we are discussing how it could be integrated with Magnum. It’s appropriate for experimentation, but I would not characterize it as a “solution for cloud providers” for the above reasons, and the callouts I mentioned here: http://lists.openstack.org/pipermail/openstack-dev/2015-July/069940.html Positioning it that way is simply premature. I strongly suggest that you attend the Magnum team meetings, and work through these concerns as we had Hyper on the agenda last Tuesday, but you did not show up to discuss it. The ML thread was confused by duplicate responses, which makes it rather hard to follow. I think it’s a really bad idea to basically re-implement Nova in Hyper. Your’e already re-implementing Docker in Hyper. With a scope that’s too wide, you won’t be able to keep up with the rapid changes in these projects, and anyone using them will be unable to use new features that they would expect from Docker and Nova while you are busy copying all of that functionality each time new features are added. I think there’s a better approach available that does not require you to duplicate such a wide range of functionality. I suggest we work together on this, and select an approach that sets you up for success, and gives OpenStack could operators what they need to build services on Hyper. Regards, Adrian On Jul 26, 2015, at 7:40 PM, Peng Zhao p...@hyper.sh wrote: Hi all, I am glad to introduce the HyperStack project to you. HyperStack is a native, multi-tenant CaaS solution built on top of OpenStack. In terms of architecture, HyperStack = Bare-metal + Hyper + Kubernetes + Cinder + Neutron. HyperStack is different from Magnum in that HyperStack doesn't employ the Bay concept. Instead, HyperStack pools all bare-metal servers into one singe cluster. Due to the hypervisor nature in Hyper, different tenants' applications are completely isolated (no shared kernel), thus co-exist without security concerns in a same cluster. Given this, HyperStack is a solution for public cloud providers who want to offer the secure, multi-tenant CaaS. Ref: https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/1258x535/1c85a755dcb5e4a4147d37e6aa22fd40/upload_7_23_2015_at_11_00_41_AM.png The next step is to present a working beta of HyperStack at Tokyo summit, which we submitted a presentation: https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/4030. Please vote if you are interested. In the future, we want to integrate HyperStack with Magnum and Nova to make sure one OpenStack deployment can offer both IaaS and native CaaS services. Best, Peng -- Background --- Hyper is a hypervisor-agnostic Docker runtime. It allows to run Docker images with any hypervisor (KVM, Xen, Vbox, ESX). Hyper is different from the minimalist Linux distros like CoreOS by that Hyper runs on the physical box and load the Docker images from the metal into the VM instance, in which no guest OS is present. Instead, Hyper boots a minimalist kernel in the VM to host the Docker images (Pod). With this approach, Hyper is able to bring some encouraging results, which are similar to container: - 300ms to boot a new HyperVM instance with a pod of Docker images - 20MB for min mem footprint of a HyperVM instance - Immutable HyperVM, only kernel+images, serves as atomic unit (Pod) for scheduling - Immune from the shared kernel problem in LXC, isolated by VM - Work seamlessly with OpenStack components, Neutron, Cinder, due to
Re: [Openstack-operators] [openstack-dev] [glance] Removal of Catalog Index Service from Glance
On 27/07/15 19:24 +, Ian Cordasco wrote: On 7/27/15, 11:29, Louis Taylor lo...@kragniz.eu wrote: On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: Hi operators, In Kilo, we added the Catalog Index Service as an experimental API in Glance. It soon became apparent this would be better suited as a separate project, so it was split into the Searchlight project: https://wiki.openstack.org/wiki/Searchlight We've now started the process of removing the service from Glance for the Liberty release. Since the service was originally had the status of being experimental, we felt it would be okay to remove it without a cycle of deprecation. Is this something that would cause issues for any existing deployments? If you have any feelings about this one way or the other, feel free to share your thoughts on this mailing list or in the review to remove the code: https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis +1 Commented on the review! +2 __ 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 -- @flaper87 Flavio Percoco pgp27Jqj0N95q.pgp Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance
On 27/07/15 19:24 +, Ian Cordasco wrote: On 7/27/15, 11:29, Louis Taylor lo...@kragniz.eu wrote: On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: Hi operators, In Kilo, we added the Catalog Index Service as an experimental API in Glance. It soon became apparent this would be better suited as a separate project, so it was split into the Searchlight project: https://wiki.openstack.org/wiki/Searchlight We've now started the process of removing the service from Glance for the Liberty release. Since the service was originally had the status of being experimental, we felt it would be okay to remove it without a cycle of deprecation. Is this something that would cause issues for any existing deployments? If you have any feelings about this one way or the other, feel free to share your thoughts on this mailing list or in the review to remove the code: https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis +1 Commented on the review! +2 __ 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 -- @flaper87 Flavio Percoco pgpMBSqpUI4k3.pgp Description: PGP 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
[openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None
Greetings, We recently found a bug in the Nova-Glance interaction that prevents booting snapshots using Glance's V2 API. The bug is that Nova creates the snapshot and sets the ramdisk_id/kernel_id to None when it's not available. While this was ok in V1, it causes a failure for V2 since the current schema-properties file doesn't allow both fields to be None. The right fix would be for Nova not to set these fields at all if no value is found. Nonetheless, we have a workaround that would make this work. The workaround landed in master and it's been proposed for kilo. Therefore, I'm asking for a stable exception to merge this patch, which is backwards compatible (unless I'm missing something). The exception is being requested because it does change the API. The change proposed is to allow these fields to be None. The review: https://review.openstack.org/#/c/205432/ Cheers, Flavio -- @flaper87 Flavio Percoco pgpLJLj9mYSWg.pgp Description: PGP 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] [murano] eslint cleanup
Well, the reasons those rules are deactivated is because they simply had no equivalent in the previous tool, and we didn't want to force the Horizon team to suddenly take on a far more aggressive style correction job than they'd signed up for. Once their job goes green, I'm going to start updating those rules one by one to slowly tighten the rules set. With that in mind though: You can always extend the openstack rules and add your own additional restrictions. So: Best of both worlds :), just make sure you keep track of what's coming in from upstream. Michael On Tue, Jul 28, 2015 at 3:58 AM Kirill Zaitsev kzait...@mirantis.com wrote: Thanks Michael, I’m actually watching this process closely, and considering switching to these rules, as soon as the job goes green. =) The upside of not doing so is that, since our (murano) js code base is significantly smaller than that of horizon — we can impose slightly stricter rule set, than horizon currently does. But switching to it completely is something, that I do consider and it is on the roadmap =) -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com) wrote: FYI, those rules have been moved into OpenStack under the QA program. I'm currently working on getting npm publish jobs to function so we can release those rules as well. http://git.openstack.org/cgit/openstack/eslint-config-openstack/ Michael On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev kzait...@mirantis.com wrote: Since there was some interest in my side activity (which is described in https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an etherpad with files, that are yet to be cleaned up. Here is the link https://etherpad.openstack.org/p/murano-escleanup So I suggest, that if you’re willing to help — add yourself in front of the file you’d like to cleanup so that we would not do the same job twice. When adding rule configs I try to refer to https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc (I’m considering switching to it completely, but that is a story for a different letter =)) -- Kirill Zaitsev Murano team Software Engineer 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 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] [neutron][extra-dhcp-opt]How to use extra-dhcp-opt when the opt_name=static-route and opt_name=classless-static-route?
Hi all, When using the extr-dhcp-opt, I find the function works well when opt_name=mtu and opt_name=router. The vm created will use the assigned mtu value or the assigned gateway. But when I create port using --extra-dhcp-opt opt_name=static-route,opt_value=192.168.0.0/24 2.2.2.2 the vm won't use this route. The opt_name=classless-static-route shows the same result. Do i use them in the wrong way? Any suggestion will be grateful. Thank you.__ 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] [Ironic] Let's talk about API versions
Hi, Could you combine 1 and 4? Deprecate not specifying the version, but pin to the oldest one for now? That way users get the warnings that they need to adapt, but things keep working? Could be switched to just 4 after a few months. This is similar to what I would like to suggest. But I would leave the pin at the current version we have right now (which is 1.9 [1]) instead of the earliest one; We then add some deprecation messages when the user do not specify a version. Otherwise we may break people that are currently using the features up to version we have pinned right now. In the long run I think that option 4. is the best option. As @Jim already pointed out from a UX point of view it's not that it will make anything worse since we already require a number of arguments. This will also makes users understand the versions we provide and pin his environment at a specific version, that way it will not break due future changes to our API and he/she can, at his/her own pace, update his/her systems to a newest version knowing that he/she already has a version that works. I say that having just added some IP addresses to a server with iproute2, which has been telling me for probably 10 years that _not_ adding /32 to single IP's will eventually be deprecated... Heh we should be faster than that (-: [1] https://github.com/openstack/python-ironicclient/blob/52f4ba68ba8a2e45875783c3240fe58f27fa54c6/ironicclient/common/http.py#L40 Cheers, Lucas __ 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] (no subject)
sumanth0...@gmail.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] Which is the correct way to set ha queues in RabbitMQ
https://www.rabbitmq.com/ha.html
Both? I think ha_all/HA is just the policy name and so it can be whatever
you want.
-Alex
On Tue, Jul 28, 2015 at 2:17 AM, Alvise Dorigo alvise.dor...@pd.infn.it
wrote:
Hi,
I read these two documents:
http://docs.openstack.org/high-availability-guide/content/_configure_rabbitmq.html
https://www.rdoproject.org/RabbitMQ
To configure the queues in HA mode, the two docs suggests two slightly
different commands;
The first one says:
rabbitmqctl set_policy ha-all '^(?!amq\.).*' '{ha-mode: all}'
while the second one says:
rabbitmqctl set_policy HA '^(?!amq\.).*' '{ha-mode: all}'
ha_all vs. HA.
which one is correct ?
thanks,
Alvise
__
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] [all] cross project communication: Return request-id to caller
Excerpts from Gorka Eguileor's message of 2015-07-28 10:37:42 +0200: On Fri, Jul 24, 2015 at 10:08:45AM -0400, Doug Hellmann wrote: Excerpts from Kekane, Abhishek's message of 2015-07-24 06:33:00 +: Hi Devs, X-Openstack-Request-Id. We have analysed python-cinderclient, python-glanceclient, python-novaclient, python-keystoneclient and python-neutronclient to check the return types. There are 9 ways return values are returned from python clients: 1. List 2. Dict 3. Resource class object 4. None 5. Tuple 6. Exception 7. Boolean (True/False, for keystoneclient) 8. Generator (for list api's in glanceclient) 9. String (for novaclient) Out of 9 we have solution for all return types except generator. In case of glance-client list api's are returning generator which is immutable. So it is not possible to return request-id in this case, which is a blocker for adopting the solution. I have added detail analysis for above return types in etherpad [2] as solution #3. If you have any suggestion in case of generation type then please let me know. It should be possible to create a new class to wrap the existing generator and implement the iterator protocol [3]. [3] https://docs.python.org/2/reference/expressions.html#generator-iterator-methods Doug Unless I'm missing something I think we wouldn't even need to create a new class that implements the iterator protocol, we can just return a generator that generates from the other one. For example, for each of the requests, if we get the generator in variable *result* that returns dictionaries and we want to add *headers* to each dictionary: return (DictWithHeaders(resource, headers) for resource in result) Wouldn't that work? That would work, but it wouldn't be consistent with the way I read [2] as describing how the other methods are being updated. For example, a method that now returns a list() will return a ListWithHeaders(), and only that returned object will have the headers, not its contents. A caller could do: response = client.some_method_returning_a_list() print reponse.headers but could not do print response[0].headers and get the same values. Creating a GeneratorWithHeaders class mirrors that behavior for methods that return generators instead of lists. Doug [2] https://etherpad.openstack.org/p/request-id __ 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][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None
-Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Tuesday, July 28, 2015 3:15 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None Greetings, We recently found a bug in the Nova-Glance interaction that prevents booting snapshots using Glance's V2 API. The bug is that Nova creates the snapshot and sets the ramdisk_id/kernel_id to None when it's not available. While this was ok in V1, it causes a failure for V2 since the current schema- properties file doesn't allow both fields to be None. The right fix would be for Nova not to set these fields at all if no value is found. Nonetheless, we have a workaround that would make this work. The workaround landed in master and it's been proposed for kilo. Therefore, I'm asking for a stable exception to merge this patch, which is backwards compatible (unless I'm missing something). The exception is being requested because it does change the API. +1 In my understanding as well we would be backwards compatible and this would make the future upgrades so much easier in the case nova starts consuming v2 Image API. - Erno The change proposed is to allow these fields to be None. The review: https://review.openstack.org/#/c/205432/ Cheers, Flavio -- @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] Barbican : Unable to create the secret after Integrating Barbican with HSM HA
Hi John , Any help would highly be appreciated. Thanks and Regards, Asha Seshagiri On Mon, Jul 27, 2015 at 3:10 PM, Asha Seshagiri asha.seshag...@gmail.com wrote: Hi John , Thanks a lot for providing me the response:) I followed the link[1] for configuring the HA SETUP [1] : http://docs.aws.amazon.com/cloudhsm/latest/userguide/ha-setup.html the final step in the above link is haAdmin command which is run on the client side(on Barbican) . The slot 6 is the virtual slot(only on the client side and not visible on LUNA SA ) and 1 and 2 are actual slots on LUNA SA HSM Please find the response below : [root@HSM-Client bin]# ./vtl haAdmin show HA Global Configuration Settings === HA Proxy: disabled HA Auto Recovery: disabled Maximum Auto Recovery Retry: 0 Auto Recovery Poll Interval: 60 seconds HA Logging: disabled Only Show HA Slots: no HA Group and Member Information HA Group Label: barbican_ha HA Group Number: 1489361010 HA Group Slot #: 6 Synchronization: enabled Group Members: 489361010, 489361011 Standby members: none Slot # Member S/N Member Label Status == == == 1 489361010 barbican2 alive 2 489361011 barbican3 alive After knowing the virtual slot HA number , I ran the pkcs11-key-generation with slot number 6 which did create mkek and hmac in slot/partition 1 and 2 automatically . I am not sure why do we have to replicate the keys between partitions? Configured the slot 6 on the barbican.conf as mentioned in my first email Not sure what might be the issue and It would be great if you could tell me the steps or where I would have gone wrong. Thanks and Regards, Asha Seshagiri On Mon, Jul 27, 2015 at 2:36 PM, John Vrbanac john.vrba...@rackspace.com wrote: Asha, I've used the Safenet HSM HA virtual slot setup and it does work. However, the setup is very interesting because you need to generate the MKEK and HMAC on a single HSM and then replicate it to the other HSMs out of band of anything we have in Barbican. If I recall correctly, the Safenet Luna docs mention how to replicate keys or partitions between HSMs. John Vrbanac -- *From:* Asha Seshagiri asha.seshag...@gmail.com *Sent:* Monday, July 27, 2015 2:00 PM *To:* openstack-dev *Cc:* John Wood; Douglas Mendizabal; John Vrbanac; Reller, Nathan S. *Subject:* Barbican : Unable to create the secret after Integrating Barbican with HSM HA Hi All , I am working on Integrating Barbican with HSM HA set up. I have configured slot 1 and slot 2 to be on HA on Luna SA set up . Slot 6 is a virtual slot on the client side which acts as the proxy for the slot 1 and 2. Hence on the Barbican side , I mentioned the slot number 6 and its password which is identical to that of the passwords of slot1 and slot 2 in barbican.conf file. Please find the contents of the file : # = Secret Store Plugin === [secretstore] namespace = barbican.secretstore.plugin enabled_secretstore_plugins = store_crypto # = Crypto plugin === [crypto] namespace = barbican.crypto.plugin enabled_crypto_plugins = p11_crypto [simple_crypto_plugin] # the kek should be a 32-byte value which is base64 encoded kek = 'YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY=' [dogtag_plugin] pem_path = '/etc/barbican/kra_admin_cert.pem' dogtag_host = localhost dogtag_port = 8443 nss_db_path = '/etc/barbican/alias' nss_db_path_ca = '/etc/barbican/alias-ca' nss_password = 'password123' simple_cmc_profile = 'caOtherCert' *[p11_crypto_plugin] # Path to vendor PKCS11 library library_path = '/usr/lib/libCryptoki2_64.so' # Password to login to PKCS11 session login = 'test5678' # Label to identify master KEK in the HSM (must not be the same as HMAC label) mkek_label = 'ha_mkek' # Length in bytes of master KEK mkek_length = 32 # Label to identify HMAC key in the HSM (must not be the same as MKEK label) hmac_label = 'ha_hmac' # HSM Slot id (Should correspond to a configured PKCS11 slot). Default: 1 slot_id = 6 * *Was able to create MKEK and HMAC successfully for the slots 1 and 2 on the HSM when we run the * *pkcs11-key-generation script for slot 6 which should be the expected behaviour. * [root@HSM-Client bin]# python pkcs11-key-generation --library-path '/usr/lib/libCryptoki2_64.so' --passphrase 'test5678' --slot-id 6 mkek --label 'ha_mkek' Verified label ! MKEK successfully generated! [root@HSM-Client bin]# python pkcs11-key-generation --library-path '/usr/lib/libCryptoki2_64.so' --passphrase 'test5678' --slot-id 6 hmac --label 'ha_hmac' HMAC successfully generated! [root@HSM-Client bin]# Please find the HSM commands and responses to show the details of the partitions and partitions contents : root@HSM-Client bin]# ./vtl verify The following Luna SA
[Openstack] VM goes for cyclic reboot
Hi, I am having Juno multinode setup with 1Controller, 1 Network and 10 Compute nodes. There are 12 VMs running on that setup. After some time one of my VM starts printing some strange messages on console repeatedly, which says: [78943.168505] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78946.592786] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78946.594413] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78947.617555] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78948.642004] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78949.600762] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78950.689530] Dead loop on virtual device vnf_sig_sp, fix it urgently! vnf_sig_sp is one interface created internally on that VM (not by neutron). After this VM runs in Kernel panic and then VM goes for a cyclic reboot. I am attaching the logs as well. Can anyone please suggest what should be done to fix this. Thanks in advance! BR, Varun [78943.168505] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78946.592786] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78946.594413] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78947.617555] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78948.642004] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78949.600762] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78950.689530] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78952.290076] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78954.660765] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78955.592326] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78956.920754] Dead loop on virtual device vnf_sig_sp, fix it urgently! [78984.036141] Stack: [78984.036846] Call Trace: [78984.037802] Code: 19 e1 df ff 5b c3 0f 1f 80 00 00 00 00 53 48 89 fb e8 77 34 c0 ff b8 00 00 01 00 f0 0f c1 03 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 13 eb f5 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 53 48 89 [78984.040002] Kernel panic - not syncing: softlockup: hung tasks [78984.040002] Pid: 1342, comm: java Tainted: PF ENX 3.0.101-0.47.52-default #1 [78984.040002] Call Trace: [78984.040002] [81004b95] dump_trace+0x75/0x300 [78984.040002] [81461d43] dump_stack+0x69/0x6f [78984.040002] [81461ddc] panic+0x93/0x201 [78984.040002] [810c8261] watchdog_timer_fn+0x181/0x190 [78984.040002] [8108842e] __run_hrtimer+0xbe/0x1a0 [78984.040002] [81088739] hrtimer_interrupt+0xd9/0x210 [78984.040002] [81026f43] smp_apic_timer_interrupt+0x63/0xa0 [78984.040002] [8146d573] apic_timer_interrupt+0x13/0x20 [78984.040002] [81464e6e] _raw_spin_lock_bh+0x1e/0x30 [78984.060008] BUG: soft lockup - CPU#1 stuck for 22s! [java:1345] [78984.060009] Modules linked in: multimmap(PEN) tcp_diag inet_diag sch_htb xt_DROPDST(EN) ip_set_rule_ipportipportproto(EN) xt_set(E) ip_set_hash_ip(E) ip_set(E) ip_vs_rr(EN) ip6t_REJECT ipt_REJECT af_packet xt_tcpudp evip_sctpd(PFEN) nf_conntrack_ipv6(E) nf_defrag_ipv6 xfrm_user xt_multiport xt_connmark xt_state xt_mark xt_conntrack ip6table_mangle ip6table_filter iptable_filter ip_vs(EN) crc32c libcrc32c nf_conntrack_netlink nfnetlink ip6_tunnel(E) tunnel6 macvlan ev_drv(PEN) nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 xt_HMARK(EN) ip6_tables(E) iptable_mangle ip_tables x_tables binfmt_misc mperf tipc(EX) softdog fuse loop dm_mod joydev usbhid hid sg sr_mod cdrom ata_generic ata_piix libata ipv6 ipv6_lib uhci_hcd rtc_cmos ehci_hcd xen_platform_pci acpiphp pci_hotplug processor thermal_sys hwmon serio_raw pcspkr scsi_mod usbcore button i2c_piix4 i2c_core usb_common nfs lockd fscache auth_rpcgss nfs_acl sunrpc virtio_balloon virtio_blk virtio_net virtio_pci virtio_ring virtio intel_agp intel_gtt floppy [last unloaded: multimmap] [78984.060044] Supported: No, Proprietary and Unsupported modules are loaded [78984.060045] CPU 1 [78984.060046] Modules linked in: multimmap(PEN) tcp_diag inet_diag sch_htb xt_DROPDST(EN) ip_set_rule_ipportipportproto(EN) xt_set(E) ip_set_hash_ip(E) ip_set(E) ip_vs_rr(EN) ip6t_REJECT ipt_REJECT af_packet xt_tcpudp evip_sctpd(PFEN) nf_conntrack_ipv6(E) nf_defrag_ipv6 xfrm_user xt_multiport xt_connmark xt_state xt_mark xt_conntrack ip6table_mangle ip6table_filter iptable_filter ip_vs(EN) crc32c libcrc32c nf_conntrack_netlink nfnetlink ip6_tunnel(E) tunnel6 macvlan ev_drv(PEN) nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 xt_HMARK(EN) ip6_tables(E) iptable_mangle ip_tables x_tables binfmt_misc mperf tipc(EX) softdog fuse loop dm_mod joydev usbhid hid sg sr_mod cdrom ata_generic ata_piix libata ipv6 ipv6_lib uhci_hcd rtc_cmos ehci_hcd xen_platform_pci acpiphp pci_hotplug processor thermal_sys hwmon serio_raw pcspkr scsi_mod usbcore button i2c_piix4 i2c_core usb_common nfs lockd fscache auth_rpcgss nfs_acl sunrpc virtio_balloon virtio_blk
[openstack-dev] [Fuel][Plugins] Feedback
Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] [fuel] FF Exception request for Templates for Networking feature
AFAIU, string.Template doesn't help.
This seems to be helpful:
import re
def interp(string, params):
for item in re.findall(r'#\{([^}]*)\}', string):
string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
return string
Evgeniy, do you know some better options for this?
Aleksey Kasatkin
On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko svasile...@mirantis.com
wrote:
If we need only substitution, probably it's better to use standard
templating
in python [1], there is a way to redefine tokens, so you will be able to
use
% % syntax if you want to.
[1] https://docs.python.org/2.6/library/string.html#template-strings
https://docs.python.org/dev/library/string.html#template-strings
[2] http://pymotw.com/2/string/#advanced-templates
I think it's a better solution for this issue.
/sv
__
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] Proposing Yanis Guenane core
On 07/28/2015 11:35 AM, Colleen Murphy wrote: On Mon, Jul 27, 2015 at 12:06 PM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: Puppet group, Yanis has been working in our group for a while now. He has been involved in a lot of tasks, let me highlight some of them: * Many times, involved in improving consistency across our modules. * Strong focus on data binding, backward compatibility and flexibility. * Leadership on cookiebutter project [1]. * Active participation to meetings, always with actions, and thoughts. * Beyond the stats, he has a good understanding of our modules, and quite good number of reviews, regularly. Yanis is for our group a strong asset and I would like him part of our core team. I really think his involvement, regularity and strong knowledge in Puppet OpenStack will really help to make our project better and stronger. I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Best regards, [1] https://github.com/openstack/puppet-openstack-cookiecutter -- Emilien Macchi +1, Yanis has been a strong contributor for a long time. 5 positive reviews from core-reviewers on my proposal, I guess we can approve it. Congratulations Yanis, you're now part of Puppet OpenStack core group! -- 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] [fuel] FF Exception request for Templates for Networking feature
Evgeniy, do we need to remove jinja before July 30th ?
Aleksey Kasatkin
On Tue, Jul 28, 2015 at 6:40 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:
AFAIU, string.Template doesn't help.
This seems to be helpful:
import re
def interp(string, params):
for item in re.findall(r'#\{([^}]*)\}', string):
string = string.replace('#{%s}' % item, str(eval(item, {}, params)))
return string
Evgeniy, do you know some better options for this?
Aleksey Kasatkin
On Tue, Jul 28, 2015 at 1:12 PM, Sergey Vasilenko svasile...@mirantis.com
wrote:
If we need only substitution, probably it's better to use standard
templating
in python [1], there is a way to redefine tokens, so you will be able to
use
% % syntax if you want to.
[1] https://docs.python.org/2.6/library/string.html#template-strings
https://docs.python.org/dev/library/string.html#template-strings
[2] http://pymotw.com/2/string/#advanced-templates
I think it's a better solution for this issue.
/sv
__
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] [Fuel][CI] CI on commit message
Hi, It looks like our CI is not configured to set +1/-1 automatically, when only commit message is changed. It would be nice to have +1 automatically when I change Commit Message only instead of waiting hours on CI. It would save some hardware resources to save some energy and help environment protection movement. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] Proposing Yanis Guenane core
On Mon, Jul 27, 2015 at 12:06 PM, Emilien Macchi emil...@redhat.com wrote: Puppet group, Yanis has been working in our group for a while now. He has been involved in a lot of tasks, let me highlight some of them: * Many times, involved in improving consistency across our modules. * Strong focus on data binding, backward compatibility and flexibility. * Leadership on cookiebutter project [1]. * Active participation to meetings, always with actions, and thoughts. * Beyond the stats, he has a good understanding of our modules, and quite good number of reviews, regularly. Yanis is for our group a strong asset and I would like him part of our core team. I really think his involvement, regularity and strong knowledge in Puppet OpenStack will really help to make our project better and stronger. I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Best regards, [1] https://github.com/openstack/puppet-openstack-cookiecutter -- Emilien Macchi +1, Yanis has been a strong contributor for a long time. 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
[Openstack] [Security][LP# 1471161] Designate mDNS DoS through incorrect handling of large RecordSets
Launchpad Number: 1471161 CVE: TBA Date: July 28, 2015 Title: Designate mDNS DoS through incorrect handling of large RecordSets Reporter: Florian Weimer (Red Hat) Products: Designate Versions: 2015.1.0 through 1.0.0.0b1 Description: Florian Weimer from Red Hat reported a vulnerability in Designate. By creating a single RecordSet that exceeds the configured max allowed DNS packet size, an authenticated user may cause the Designate mDNS service to enter an infinite loop, triggering a DoS. Liberty (development branch) fix: https://review.openstack.org/206578 Kilo fix: https://review.openstack.org/206580 Notes: This fix will be included in a future 1.0.0.0b2 release. References: https://launchpad.net/bugs/1471161 -- Kiall Mac Innes, OpenStack Designate PTL 0x6DD192A2.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack] Cinder volume from vmware sparse vmdk
I have an openstack created instance running within my vmware compute node. The vmdk boot image I used to create this instance, is stored in glance and contains the below disk properties: adapter type = lsiLogic disk type = sparse Now, if I use this image to boot an instance, all works as expected. No problems. If I create a volume with this image and try to boot from this volume, the hypervisor complains that no operating system is found. If I attach the volume to a running linux instance fdisk reports that no partition table is found. So I guess the question is, what step am I missing when I create a volume from a sparse vmdk image ?When I create a volume from a preallocated image, everything works fine. So some step is missing when using sparse images to create a working cinder volume. Thanks! ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance
yeah that really didn't belong in glance at all. On Tue, Jul 28, 2015 at 10:05 AM, Flavio Percoco fla...@redhat.com wrote: On 27/07/15 19:24 +, Ian Cordasco wrote: On 7/27/15, 11:29, Louis Taylor lo...@kragniz.eu wrote: On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: Hi operators, In Kilo, we added the Catalog Index Service as an experimental API in Glance. It soon became apparent this would be better suited as a separate project, so it was split into the Searchlight project: https://wiki.openstack.org/wiki/Searchlight We've now started the process of removing the service from Glance for the Liberty release. Since the service was originally had the status of being experimental, we felt it would be okay to remove it without a cycle of deprecation. Is this something that would cause issues for any existing deployments? If you have any feelings about this one way or the other, feel free to share your thoughts on this mailing list or in the review to remove the code: https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis +1 Commented on the review! +2 __ 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 -- @flaper87 Flavio Percoco ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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] [fuel] OS_SERVICE_TOKEN usage in Fuel
Hello all, We need to discuss removal of OS_SERVICE_TOKEN usage in Fuel after deployment. This came from https://bugs.launchpad.net/fuel/+bug/1430619. I guess not all of us have an access to this bug, so to be short: # A shared secret that can be used to bootstrap Keystone. # This token does not represent a user, and carries no # explicit authorization. To disable in production (highly # recommended), remove AdminTokenAuthMiddleware from your # paste application pipelines (for example, in keystone- # paste.ini). (string value) After removing this and testing we found out that OSTF fails because it uses admin token. What do you think if we create ostf user like for workloads, but with wider permissions? BR, Oleksiy. __ 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] [midcycle][kolla] Kolla-Palooza Midcycle Event July 28th, July 29th
Today at 10:00 AM PST our Kola-Palooza Midcycle event begins! Please join us remotely if you are not able to make it on site if you have an interest in deploying OpenStack using Ansible within Docker container technology. If you are attending in person, please appear before 9:30 so we can get you checked in and settled. The full midcyce information including remote attendance via Webex information Is here: https://wiki.openstack.org/wiki/Sprints/KollaLibertySprint A map is present in the above link if your Uber driver has trouble finding building D. The full agenda is present here: https://etherpad.openstack.org/p/liberty-kolla-midcycle Note if we are running early/late during the day, we wont “block” and wait to synchronize times, so if there is only one session your interested in, you may try joining our IRC channel #kolla where we will list off the topics as they come up so you know when to join. Looking forward to seeing folks there! Regards -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-operators] [openstack-dev] [glance] Removal of Catalog Index Service from Glance
yeah that really didn't belong in glance at all. On Tue, Jul 28, 2015 at 10:05 AM, Flavio Percoco fla...@redhat.com wrote: On 27/07/15 19:24 +, Ian Cordasco wrote: On 7/27/15, 11:29, Louis Taylor lo...@kragniz.eu wrote: On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: Hi operators, In Kilo, we added the Catalog Index Service as an experimental API in Glance. It soon became apparent this would be better suited as a separate project, so it was split into the Searchlight project: https://wiki.openstack.org/wiki/Searchlight We've now started the process of removing the service from Glance for the Liberty release. Since the service was originally had the status of being experimental, we felt it would be okay to remove it without a cycle of deprecation. Is this something that would cause issues for any existing deployments? If you have any feelings about this one way or the other, feel free to share your thoughts on this mailing list or in the review to remove the code: https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis +1 Commented on the review! +2 __ 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 -- @flaper87 Flavio Percoco ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [puppet] module dependencies and different openstack versions
We use the OpenStack modules, but glue everything together with a monolithic composition module (our own.) We do want to get to a place where we can upgrade/apply config/etc. each OpenStack component separately, but have’t tackled it yet. I think it will be possible, but will take some work. I have heard of a few others who have been working toward the same thing, though I don’t think there’s really anything concrete in the upstream modules yet. WRT the dependencies, we use r10k with a manually populated Puppetfile, so we don’t rely on the module metadata to determine which modules to pull in. That’s one way to get exactly what you want rather than all the dependency sprawl. Mike On 7/27/15, 5:10 PM, Sam Morrison sorri...@gmail.com wrote: On 27 Jul 2015, at 11:25 pm, Emilien Macchi emil...@redhat.com wrote: On 07/27/2015 02:32 AM, Sam Morrison wrote: We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone module and try to do things in keystone suck as create users, service endpoints etc. This is a pain as I don’t want it to mess with keystone (for one we don’t support setting endpoints via an API) but also we don’t want to move to the official keystone module at the same time. We have some custom keystone stuff which means we’ll may never move to the official keystone puppet module. Well, in that case it's going to be very hard for you to use the modules. Trying to give up forks and catch-up to upstream is really expensive and challenging (Fuel is currently working on this). What I suggest is: 1/ have a look at the diff between your manifests and upstream ones. 2/ try to use upstream modules with the maximum number of classes, and put the rest in a custom module (or a manifest somewhere). 3/ submit patches if you think we're missing something in the modules. The neutron module pulls in the vswitch module but we don’t use vswitch and it doesn’t seem to be a requirement of the module so maybe doesn’t need to be in metadata dependencies? AFIK there is no conditional in metadata.json, so we need the module anyway. It should not cause any trouble to you, except if you have a custom 'vswitch' module. Yeah it would be nice if you could specify dependencies as well as recommended much like debian packages do. We use librarian-puppet to manage all our modules and you can’t disable it installing all the dependencies. But that is another issue… It looks as if all the openstack puppet modules are designed to all be used at once? Does anyone else have these kind of issues? It would be great if eg. the neutron module would just manage neutron and not try and do things in nova, keystone, mysql etc. We try to design our modules to work together because Puppet OpenStack is a single project composed of modules that are supposed to -together- deploy OpenStack. All the puppet modules we use are very modular (hence the name), the openstack modules aren’t at this stage. Ideally each module would be self contained and then if people wanted to deploy “openstack” there could be an “openstack” module that would pull in all the individual project modules and make them work together. It’s the first tip for writing a module listed at https://docs.puppetlabs.com/puppet/latest/reference/modules_fundamentals.h tml#tips I guess I’m just wondering if other people are having the same issue I am? and if so is there a way forward to make the puppet modules more modular or do I just stick with my own modules. In your case, I would just install the module from source (git) and not trying to pull them from Puppetforge. The other issue we have is that we have different services in openstack running different versions. Currently we have Kilo, Juno and Icehouse versions of different bits in the same cloud. It seems as if the puppet modules are designed just to manage one openstack version? Is there any thoughts on making it support different versions at the same time? Does this work? 1/ you're running Kilo, Juno and Icehouse in the same cloud? Wow. You're brave! We are a large deployment spanning multiple data centres and 1000+ hosts so upgrading in one big bang isn’t an option. I don’t think this is brave it is the norm for people running large openstack clouds in production. 2/ Puppet modules do not hardcode OpenStack packages version. Though our current master is targeting Liberty, but we have stable/kilo, stable/juno, etc. You can even disable the package dependency in most of the classes. The packages aren’t the issue it’s more the configs that get pushed out and so on, when config variables change location etc. with different versions this becomes hard. I'm not sure this is an issue here,
Re: [openstack-dev] [puppet] Proposing Yanis Guenane core
+1 On 2015-07-27 3:06 PM, Emilien Macchi wrote: Puppet group, Yanis has been working in our group for a while now. He has been involved in a lot of tasks, let me highlight some of them: * Many times, involved in improving consistency across our modules. * Strong focus on data binding, backward compatibility and flexibility. * Leadership on cookiebutter project [1]. * Active participation to meetings, always with actions, and thoughts. * Beyond the stats, he has a good understanding of our modules, and quite good number of reviews, regularly. Yanis is for our group a strong asset and I would like him part of our core team. I really think his involvement, regularity and strong knowledge in Puppet OpenStack will really help to make our project better and stronger. I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Best regards, [1] https://github.com/openstack/puppet-openstack-cookiecutter __ 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 -- 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
[Openstack] [OSSA 2015-013] Glance task flow may fail to delete image from backend
= OSSA-2015-013: Glance task flow may fail to delete image from backend = :Date: July 28, 2015 :CVE: CVE-2015-3289 Affects ~~~ - Glance: versions 2015.1.0 Description ~~~ Abhishek Kekane from NTT reported a vulnerability in Glance. By creating numerous images using the import task flow API and deleting them, an authenticated attacker may accumulate untracked image data in the backend resulting in potential resource exhaustion and denial of service. All glance setups are affected. Patches ~~~ - https://review.openstack.org/#/c/181816/ (Kilo) - https://review.openstack.org/#/c/181345/ (Liberty) Credits ~~~ - Abhishek Kekane from NTT (CVE-2015-3289) References ~~ - https://launchpad.net/bugs/1454087 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3289 Notes ~ - This fix will be included in the future 2015.1.1 (kilo) release. pgpKiuuPbeRq7.pgp Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [puppet] Proposing Yanis Guenane core
+1 On Tue, Jul 28, 2015 at 9:00 AM, Sebastien Badia s...@sebian.fr wrote: On Mon, Jul 27, 2015 at 03:06:56PM (-0400), Emilien Macchi wrote: I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Hi, Yes, of course! A big +1 Seb -- Sebastien Badia __ 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-operators] RE : Can't launch docker instance, Unexpected vif_type=binding_failed.
openvswitch agent is running and the logs in compute2 are as follow: 1. OVS-cleanup.log 2015-06-20 12:52:19.976 1529 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-06-23 15:48:43.401 1332 INFO neutron.common.config [-] Logging enabled! 2015-06-23 15:48:43.893 1332 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-06-23 15:48:44.520 1332 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-06-24 11:49:21.423 1770 INFO neutron.common.config [-] Logging enabled! 2015-06-24 11:49:22.123 1770 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-06-24 11:49:22.628 1770 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-06-25 00:21:55.634 1337 INFO neutron.common.config [-] Logging enabled! 2015-06-25 00:21:56.858 1337 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-06-25 00:21:57.900 1337 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-07-07 16:43:42.608 1457 INFO neutron.common.config [-] Logging enabled! 2015-07-07 16:43:43.399 1457 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-07-07 16:43:43.792 1457 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-07-08 15:04:31.954 1351 INFO neutron.common.config [-] Logging enabled! 2015-07-08 15:04:32.888 1351 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-07-08 15:04:33.235 1351 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed successfully 2015-07-20 13:25:20.300 1550 INFO neutron.common.config [-] Logging enabled! 2015-07-20 13:25:22.665 1550 INFO neutron.agent.ovs_cleanup_util [-] Cleaning br-int 2015-07-20 13:25:22.770 1550 INFO neutron.agent.ovs_cleanup_util [-] OVS cleanup completed succe 2. Openvswitch-agent.log 2015-07-28 13:23:29.151 4615 ERROR neutron.agent.linux.ovsdb_monitor [-] Error received from ovsdb monitor: 2015-07-28T11:23:29Z|1|fatal_signal|WARN|terminating with signal 15 (Terminated) 2015-07-28 13:23:29.190 4615 ERROR neutron.agent.linux.utils [-] Command: ['ps', '--ppid', '4764', '-o', 'pid='] Exit code: 1 Stdout: '' Stderr: '' 2015-07-28 13:23:29.835 4615 CRITICAL neutron [req-dbf6bc78-c2df-4454-9e19-5f09bf688ee9 None] AssertionError: Trying to re-send() an already-triggered event. 2015-07-28 13:23:29.835 4615 TRACE neutron Traceback (most recent call last): 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/bin/neutron-openvswitch-agent, line 10, in module 2015-07-28 13:23:29.835 4615 TRACE neutron sys.exit(main()) 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py, line 1565, in main 2015-07-28 13:23:29.835 4615 TRACE neutron agent.daemon_loop() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py, line 1485, in daemon_loop 2015-07-28 13:23:29.835 4615 TRACE neutron self.rpc_loop(polling_manager=pm) 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/contextlib.py, line 24, in __exit__ 2015-07-28 13:23:29.835 4615 TRACE neutron self.gen.next() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/agent/linux/polling.py, line 39, in get_polling_manager 2015-07-28 13:23:29.835 4615 TRACE neutron pm.stop() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/agent/linux/polling.py, line 106, in stop 2015-07-28 13:23:29.835 4615 TRACE neutron self._monitor.stop() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/agent/linux/async_process.py, line 89, in stop 2015-07-28 13:23:29.835 4615 TRACE neutron self._kill() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/agent/linux/ovsdb_monitor.py, line 99, in _kill 2015-07-28 13:23:29.835 4615 TRACE neutron super(SimpleInterfaceMonitor, self)._kill(*args, **kwargs) 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/neutron/agent/linux/async_process.py, line 116, in _kill 2015-07-28 13:23:29.835 4615 TRACE neutron self._kill_event.send() 2015-07-28 13:23:29.835 4615 TRACE neutron File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 150, in send 2015-07-28 13:23:29.835 4615 TRACE neutron assert self._result is NOT_USED, 'Trying to re-send() an already-triggered event.' 2015-07-28 13:23:29.835 4615 TRACE neutron AssertionError: Trying to re-send() an already-triggered event. 2015-07-28 13:23:29.835 4615 TRACE neutron 2015-07-28 13:23:32.197 6195 INFO neutron.common.config [-] Logging enabled! 2015-07-28 13:23:33.005 6195 INFO oslo.messaging._drivers.impl_rabbit [-] Connecting to AMQP server on controller:5672 2015-07-28 13:23:33.120 6195 INFO oslo.messaging._drivers.impl_rabbit [-] Connected to AMQP server on
Re: [openstack-dev] [murano] eslint cleanup
Thanks Michael, I’m actually watching this process closely, and considering switching to these rules, as soon as the job goes green. =) The upside of not doing so is that, since our (murano) js code base is significantly smaller than that of horizon — we can impose slightly stricter rule set, than horizon currently does. But switching to it completely is something, that I do consider and it is on the roadmap =) -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 28 Jul 2015 at 03:00:40, Michael Krotscheck (krotsch...@gmail.com) wrote: FYI, those rules have been moved into OpenStack under the QA program. I'm currently working on getting npm publish jobs to function so we can release those rules as well. http://git.openstack.org/cgit/openstack/eslint-config-openstack/ Michael On Mon, Jul 27, 2015 at 4:13 PM Kirill Zaitsev kzait...@mirantis.com wrote: Since there was some interest in my side activity (which is described in https://blueprints.launchpad.net/murano/+spec/add-js-lint-jobs) I’ve created an etherpad with files, that are yet to be cleaned up. Here is the link https://etherpad.openstack.org/p/murano-escleanup So I suggest, that if you’re willing to help — add yourself in front of the file you’d like to cleanup so that we would not do the same job twice. When adding rule configs I try to refer to https://github.com/krotscheck/eslint-config-openstack/blob/master/.eslintrc (I’m considering switching to it completely, but that is a story for a different letter =)) -- Kirill Zaitsev Murano team Software Engineer 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 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] Removing python-swiftclient from requirements.txt
On 28/07/15 10:29 +0200, Thomas Goirand wrote: On 07/27/2015 11:42 PM, William M Edmonds wrote: python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? Even if swiftclient was removed from requirements.txt, I would still keep it as a hard Depends: in Debian, so it would not change anything for (Debian) users. I think this is perfectly find and it's a good thing. Upstream packages don't need to follow everything that happens downstream. From a downstream perspective, it's a requirement that is not needed neither in the CI nor in most of the development environments. Cheers, Flavio Thomas __ 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 -- @flaper87 Flavio Percoco pgppnN17ZocFu.pgp Description: PGP 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] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?
Hi jay, There are a few Nova people in HP who intend to work on this area (perhaps you have heard that from Scott or Duncan). In fact I brought up that this would be coming up in Vancouver and that we intend to support it. Unfortunately none of us are available that week. I would like to be kept involved and will have to catch up with the other HP guys after the event. In the meantime, if you want names to be involved beyond the cinder mid-cycle you can put down as a place holder for HP and I will sort out people to be involved when we are all back from vacation. Paul -Original Message- From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net] Sent: 24 July 2015 22:50 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup? All, I had the opportunity to chat with John Garbutt when he was here in Rochester for the Nova mid-cycle meet-up. We discussed the fact that there was much to be gained by improving the communication between the Cinder and Nova teams. With that idea in mind, it was suggested that the Cinder team open an invitation to Nova members to attend our mid-cycle meet-up. The mid-cycle meet-up, of course, is not a secret. A member of the Nova team has always been welcome to join, just hoping that an explicit invitation here may spark some interest. :-) Note: John considered attending but is unable to do so. The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site in Fort Collins, CO . Friday is an optional code sprint day for those who are able to stay that long. Details about the meet-up can be seen on our mid-cycle meetup planning etherpad [1]. If you are able to join us and help us work through the various challenges we are having between Cinder and Nova it would be greatly appreciated! Jay [1] https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup __ 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] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup?
In the meantime, if you want names to be involved beyond the cinder mid-cycle you can put down as a place holder for HP and I will sort out people to be involved when we are all back from vacation. Of course I meant you can put ME down :) Paul -Original Message- From: Murray, Paul (HP Cloud) Sent: 28 July 2015 12:52 To: 'jsbry...@electronicjungle.net'; OpenStack Development Mailing List (not for usage questions) Cc: Rosa, Andrea (HP Cloud Services) Subject: RE: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup? Hi jay, There are a few Nova people in HP who intend to work on this area (perhaps you have heard that from Scott or Duncan). In fact I brought up that this would be coming up in Vancouver and that we intend to support it. Unfortunately none of us are available that week. I would like to be kept involved and will have to catch up with the other HP guys after the event. In the meantime, if you want names to be involved beyond the cinder mid-cycle you can put down as a place holder for HP and I will sort out people to be involved when we are all back from vacation. Paul -Original Message- From: Jay S. Bryant [mailto:jsbry...@electronicjungle.net] Sent: 24 July 2015 22:50 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][cinder] Would anyone from Nova Core be able to join the Cinder mid-cycle meetup? All, I had the opportunity to chat with John Garbutt when he was here in Rochester for the Nova mid-cycle meet-up. We discussed the fact that there was much to be gained by improving the communication between the Cinder and Nova teams. With that idea in mind, it was suggested that the Cinder team open an invitation to Nova members to attend our mid-cycle meet-up. The mid-cycle meet-up, of course, is not a secret. A member of the Nova team has always been welcome to join, just hoping that an explicit invitation here may spark some interest. :-) Note: John considered attending but is unable to do so. The mid-cycle meet-up for Cinder is 8/4 through 8/7 at the HP site in Fort Collins, CO . Friday is an optional code sprint day for those who are able to stay that long. Details about the meet-up can be seen on our mid-cycle meetup planning etherpad [1]. If you are able to join us and help us work through the various challenges we are having between Cinder and Nova it would be greatly appreciated! Jay [1] https://etherpad.openstack.org/p/cinder-liberty-midcycle-meetup __ 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] Proposing Yanis Guenane core
On Mon, Jul 27, 2015 at 03:06:56PM (-0400), Emilien Macchi wrote: I would like to open the vote to promote Yanis part of Puppet OpenStack core reviewers. Hi, Yes, of course! A big +1 Seb -- Sebastien Badia 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] [glance] Removing python-swiftclient from requirements.txt
On 28/07/15 09:15 +, Kuvaja, Erno wrote: I do agree, we don’t depend or are cleaning the other clients out of the glance dependencies as well and I think swift should not be there either. The default store is filesystem store and if something is depending on the actual store clients it should be either glance_store or deployer (well for example our gate) glance itself should not have hard dependencies for ‘em. Agreed! William, would it be possible for you to spend some more time and create a single patch that removes all non-required dependencies? Cheers, Flavio - Erno From: William M Edmonds [mailto:edmon...@us.ibm.com] Sent: Monday, July 27, 2015 10:42 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt python-swiftclient is only needed by operators that are using the swift backend, so it really doesn't belong in requirements.txt. Listing it in requirements forces all operators to install it, even if they're not going to use the swift backend. When I proposed a change [1] to move this from requirements to test-requirements (would still be needed there because of tests using the swift backend), others raised concerns about the impact this could have on operators who use the swift backend today and would be upgrading to Liberty. I believe everyone agreed this should not be in requirements, but the fact is that it has been, so operators may have (incorrectly) been depending on that during upgrades. If we remove it in Liberty, and there are changes in Liberty that require a newer version of swiftclient, how would those operators know that they need to upgrade swiftclient? The optional dependencies spec [2] could definitely help here. I don't think we should have to wait for that, though. This is an issue we obviously already have today for other backends, which indicates folks can deal with it without an optional dependencies implementation. This would be a new concern for operators using the default swift backend, though. So how do we get the message out to those operators? And do we need to put out a message about this change in Liberty and then wait until Mitaka to actually remove this, or can we go ahead and remove in Liberty? [1] https://review.openstack.org/#/c/203242 [2] http://specs.openstack.org/openstack/oslo-specs/specs/liberty/ optional-deps.html -Matthew __ 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 -- @flaper87 Flavio Percoco pgpAKKS5Gzx_m.pgp Description: PGP 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] [Horizon][Neutron] how to configure horizon to use lbaas api v2?
On 07/28/2015 12:09 PM, Wilence Yao wrote: Hi all, In devstack, I configured enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas ENABLED_SERVICES+=,q-lbaasv2 so, I can use lbaasv2 api in neutronclient. But I see the agent that's name is q-lbaasv2 not q-lbaas in screen, and horizon can recognize it . So I cann't use resource about lbaas in horizon. What should to let horizon recognize q-lbaasv2? Wilence Yao __ 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 This question was asked recently: http://lists.openstack.org/pipermail/openstack-dev/2015-July/070066.html Related BP: https://blueprints.launchpad.net/horizon/+spec/lbaas-v2-panel Kuba __ 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][lbaas] Horizon support for neutron-lbaas v2
Hi Kevin, It is supported by the UI workflow we proposed. User can select existing IP (VIP) when creating a new Load Balancer (IP drop down in first tab) https://openstack.invisionapp.com/d/main#/console/4237816/92203875/comments That selection will reuse the VIP but use different port and other configs. Thanks, Vivek 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: Tuesday, July 28, 2015 at 7:18 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 One of the features I'm looking forward to most in v2 is multiple ports on one lb. Like 80 and 443. The ui doesnt look to easily support that? Thanks, Kevin From: Jain, Vivek Sent: Tuesday, July 28, 2015 6:19:25 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi Folks, Screenshots are uploaded. Please review and leave your feedback: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, vivek From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:14 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Doug. We are planning to submit initial review version by end of day today. Also, we will be uploading LBaaS wireframes for review here: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, Vivek From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 The repo is now live. Initial review is here: https://review.openstack.org/#/c/206757 , please make any near-term reviews dependent on that, unless you’re replacing the skeleton. Vivek, when do you think we can get some initial code in there to start iterating on? Thanks, doug On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 15, 2015 at 10:35 AM To: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a easy way to de-couple lbaas dashboard from
[openstack-dev] [docs] [security-guide] RST Navigation Sidebar
Docs Team, While doing the RST migration we noticed that the navigation sidebar from the current DocBook version was not there. After continued editing we came to the conclusion that navigation pane was REALLY useful. My understanding is that there is no RST equivalent yet. Is that accurate? If so, is there any possibility of implementing one? Thanks, Nathaniel __ 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] Python API for Dynamic Large Objects in Swift
On 25/07/15 00:28, Vincenzo Pii wrote:
To upload a Dynamic Large Object with the Swift CLI one can just do
swift upload newcont -S 1048576000 large_object
but, is there any equivalent in the swift python APIs (swiftclient module
from https://github.com/openstack/python-swiftclient)?
The content_length parameter of put_object will just truncate the content...
The general approach is outlined here (Swift API section):
https://www.mirantis.com/blog/large-objects-in-cloud-storages/
I have attached a rather simple sample program that uses the idea.
regards
Mark
#!/usr/bin/python
import swiftclient
import os
import argparse
parser = argparse.ArgumentParser()
parser.add_argument(-c, --container, help=container, default=con)
parser.add_argument(-o, --obj, help=object, default=file)
parser.add_argument(-s, --segsize, help=segment size, type=int, default=104857600)
parser.add_argument(-u, --user, help=user, default=demo:demo)
parser.add_argument(-k, --key, help=key, default=password)
parser.add_argument(-r, --region, help=region, default=RegionOne)
parser.add_argument(-a, --authurl, help=auth url, default=http://192.168.122.31:35357/v2.0;)
args = parser.parse_args()
options = {'tenant_name': args.user.split(':')[0], 'region_name': args.region}
conn = swiftclient.Connection(
user = args.user,
key = args.key,
authurl = args.authurl,
insecure = True,
auth_version = 2,
os_options = options,
)
# figure out how many segments to use
obj_name = args.obj
obj_size = os.path.getsize(obj_name)
seg_size = args.segsize
segs = (obj_size / seg_size) + 1
# create the container, and the segment container
con_name = args.container
seg_con_name = con_name + '_segments'
print container {0}.format(con_name)
conn.put_container(con_name)
print container {0}.format(seg_con_name)
conn.put_container(seg_con_name)
# start upload of each segment
print begin segment upload of + obj_name
print size + str(obj_size) + , + str(segs) + segs
fp = open(obj_name, 'r')
for n in range(1, segs + 1):
seg_name = '%s/%08d' % (obj_name, n)
if (obj_size - (n - 1) * seg_size seg_size):
size = obj_size - (n - 1) * seg_size
else:
size = seg_size
fp.seek((n - 1) * seg_size)
print upload segment + str(n) + size + str(size)
conn.put_object(seg_con_name,
seg_name,
fp,
content_length=size,
)
print end segment upload
print create manifest
obj_manifest_header = {}
obj_manifest_header['x-object-manifest'] = '%s/%s/' % (seg_con_name, obj_name)
conn.put_object(con_name,
obj_name,
None,
content_length=obj_size,
headers=obj_manifest_header,
)
print done
fp.close()
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack-operators] Cinder volume on lvm volume
Hi All: I have lvm volume /dev/mapper/centos-images on allinOne installation (Cenots7, openstack icehouse) machine. I wanted to make this to configure in cinder to get ebs for instances. Can i do that? is there any document apart to do the same? Any references will be highly appreciated. Thanks, Dev ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2
Initial code for horizon lbaas v2 dashboard submitted: https://review.openstack.org/#/c/206797 Thanks, vivek From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 6:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi Folks, Screenshots are uploaded. Please review and leave your feedback: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, vivek From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:14 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Doug. We are planning to submit initial review version by end of day today. Also, we will be uploading LBaaS wireframes for review here: https://openstack.invisionapp.com/d/main#/projects/4237816 Thanks, Vivek From: Doug Wiegley doug...@parksidesoftware.commailto:doug...@parksidesoftware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 28, 2015 at 4:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 The repo is now live. Initial review is here: https://review.openstack.org/#/c/206757 , please make any near-term reviews dependent on that, unless you’re replacing the skeleton. Vivek, when do you think we can get some initial code in there to start iterating on? Thanks, doug On Jul 16, 2015, at 6:27 AM, Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com wrote: A quick reminder that we will be meeting today at 16:00UTC (9:00 am PDT) in #openstack-lbaas to discuss Horizon LBaaS v2 UI. Thanks, Vivek From: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 15, 2015 at 10:35 AM To: Eichberger, German german.eichber...@hp.commailto:german.eichber...@hp.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 I agree with German. Let’s keep things together for now. Susanne From: Eichberger, German Sent: Wednesday, July 15, 2015 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne; Tonse, Milan Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Hi, Let’s move it into the LBaaS repo that seems like the right place for me — Thanks, German From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:22 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan mto...@ebay.commailto:mto...@ebay.com Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2 Thanks Akihiro. Currently lbaas panels are part of horizon repo. If there is a easy way to de-couple lbaas dashboard from horizon? I think that will simplify development efforts. What does it take to separate lbaas dashboard from horizon? Thanks, Vivek From: Akihiro Motoki amot...@gmail.commailto:amot...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, July 14, 2015 at 10:09 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan
Re: [openstack-dev] [Fuel] Get rid of fuelmenu
Guys, how do we deal with use case provide in this bug: https://bugs.launchpad.net/fuel/7.0.x/+bug/1438658 ? Looks like Fuel Menu can't solve this one. Is there workaround possible (even with worse UX)? On Fri, Jul 24, 2015 at 5:26 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Guys, thanks a lot for your opinions. Now it is quite clear for me that vim+text UX is definitely not our way even though many developers (not all) prefer this. Vladimir Kozhukalov On Fri, Jul 24, 2015 at 12:47 AM, Fabrizio Soppelsa fsoppe...@mirantis.com wrote: Hello Vladimir, from me -1. We can discuss if enable fuelmenu=yes or not in grub, but I wouldn't get rid of it. I've never heard complaints against fuelmenu from users, and it's widely used for basic settings afterinstall. If the users had to manually edit another configuration file, should they remember to run a validator tool over it every time after editing the file? Or do we add a futher layer that invokes $EDITOR and after :wq, some validator performs a check...? IMO that's poor UX, and why reimplement it, in fuelmenu there are already nice fixed choices and check commands that restricts potential human mistakes. F. On 07/23/2015 04:23 AM, Vladimir Kozhukalov wrote: Dear colleagues, What do you think of getting rid of fuelmenu and substituting it with thoroughly commented text file + some validation + vim? The major pro of this is that text file is easier to extend and edit. Many people prefer vim UX instead of wandering through the semi-graphical interface. And it is not so hard to implement syntax and logic checking for the text file. Please give your opinions about this. Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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 -- Mike Scherbakov #mihgen __ 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
