Re: [openstack-dev] [openstack-tc][deb-packaging] Updated proposal for OpenStack deb packages

2015-07-28 Thread Thomas Goirand
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

2015-07-28 Thread Anita Kuno
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

2015-07-28 Thread John Garbutt
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

2015-07-28 Thread Kuvaja, Erno
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

2015-07-28 Thread Gaël Chamoulaud
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?

2015-07-28 Thread Wilence Yao
 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


[openstack-dev] Dragonflow - Weekly IRC Meeting

2015-07-28 Thread Gal Sagie
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-dev] [fuel] Fuel plugin as docker containers images

2015-07-28 Thread Evgeniy L
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

2015-07-28 Thread Kekane, Abhishek
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-dev] [fuel] FF Exception request for Templates for Networking feature

2015-07-28 Thread Evgeniy L
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

2015-07-28 Thread Dmitry Mescheryakov
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

2015-07-28 Thread Adrian Otto
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

2015-07-28 Thread Dmitry Tantsur

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

2015-07-28 Thread Alvise Dorigo

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

2015-07-28 Thread Sergey Vasilenko
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-dev] [cinder][nova] snapshot and cloning for NFS backend

2015-07-28 Thread Jordan Pittier
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

2015-07-28 Thread Sergey Vasilenko
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

2015-07-28 Thread Kekane, Abhishek
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

2015-07-28 Thread Sebastian Kalinowski
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

2015-07-28 Thread Evgeniy L
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

2015-07-28 Thread Dmitry Tantsur

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

2015-07-28 Thread Gorka Eguileor
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

2015-07-28 Thread Aleksandr Didenko
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

2015-07-28 Thread Aleksey Kasatkin

 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

2015-07-28 Thread Kevin Benton
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 

Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt

2015-07-28 Thread Thomas Goirand
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

2015-07-28 Thread Alexander Kostrikov
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

2015-07-28 Thread Roman Vasilets
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

2015-07-28 Thread Bogdan Dobrelya
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

2015-07-28 Thread Sergey Vasilenko

 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

2015-07-28 Thread William M Edmonds

 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

2015-07-28 Thread Julia Kreger
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

2015-07-28 Thread Jim Rollenhagen
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

2015-07-28 Thread Jain, Vivek
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

2015-07-28 Thread Jain, Vivek
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

2015-07-28 Thread Lin Hua Cheng
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-dev] [fuel] Fuel plugin as docker containers images

2015-07-28 Thread Konstantin Danilov
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

2015-07-28 Thread Doug Hellmann
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

2015-07-28 Thread Clay Gerrard
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

2015-07-28 Thread Znoinski, Waldemar
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


Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

2015-07-28 Thread Ryan Moats
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

2015-07-28 Thread Fox, Kevin M
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

2015-07-28 Thread Asha Seshagiri
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

2015-07-28 Thread Kevin Benton
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


Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

2015-07-28 Thread Konstantin Danilov
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

2015-07-28 Thread Ryan Moats
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

2015-07-28 Thread Yanis Guenane
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

2015-07-28 Thread Jay Lau
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

2015-07-28 Thread Jay Lau
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-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance

2015-07-28 Thread Flavio Percoco

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

2015-07-28 Thread Flavio Percoco

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

2015-07-28 Thread Michael Krotscheck
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?

2015-07-28 Thread ????
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

2015-07-28 Thread Lucas Alvares Gomes
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


Re: [openstack-dev] Which is the correct way to set ha queues in RabbitMQ

2015-07-28 Thread Alex Schultz
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

2015-07-28 Thread Doug Hellmann
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

2015-07-28 Thread Kuvaja, Erno
 -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

2015-07-28 Thread Asha Seshagiri
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-dev] [Fuel][Plugins] Feedback

2015-07-28 Thread Sergii Golovatiuk
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

2015-07-28 Thread Aleksey Kasatkin
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

2015-07-28 Thread Emilien Macchi


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

2015-07-28 Thread Aleksey Kasatkin
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

2015-07-28 Thread Sergii Golovatiuk
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

2015-07-28 Thread Colleen Murphy
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


Re: [openstack-dev] [Openstack-operators] [glance] Removal of Catalog Index Service from Glance

2015-07-28 Thread matt
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

2015-07-28 Thread Oleksiy Molchanov
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

2015-07-28 Thread Steven Dake (stdake)
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-dev] [puppet] Proposing Yanis Guenane core

2015-07-28 Thread Mathieu Gagné
+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


Re: [openstack-dev] [puppet] Proposing Yanis Guenane core

2015-07-28 Thread Clayton O'Neill
+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


Re: [openstack-dev] [murano] eslint cleanup

2015-07-28 Thread Kirill Zaitsev
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

2015-07-28 Thread Flavio Percoco

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?

2015-07-28 Thread Murray, Paul (HP Cloud)
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?

2015-07-28 Thread Murray, Paul (HP Cloud)
 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

2015-07-28 Thread Sebastien Badia
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

2015-07-28 Thread Flavio Percoco

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?

2015-07-28 Thread Jakub Libosvar
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

2015-07-28 Thread Jain, Vivek
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

2015-07-28 Thread Dillon, Nathaniel
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-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

2015-07-28 Thread Jain, Vivek
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

2015-07-28 Thread Mike Scherbakov
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


Re: [openstack-dev] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

2015-07-28 Thread Armando M.
Hi,

Since I was quoted, I would like to take the blame on behalf on the Neutron
core reviewer/drivers team for not providing the right guidance to resolve
the apparent conflict between the two proposals.

As some reviewers mentioned, we should really strive to catch two birds
with one stone, and ensure that, if at all possible, the same API can
address both use cases presented. In this case, it sounds to me that the
API proposed by the networking-sfc sub-project is more comprehensive, it
has taken the steps to evolve independently from the Neutron core platform,
and it has been iterated on multiple times. Surely we can spin off (the
forwarding engine) from the spin off (the SFC API), but that would feel
like an overkill, especially when both have very little code to show for
(and everyone knows that code wins in OpenStack).

We should have provided Yuji Azama feedback a lot earlier in the process
but we didn't. Again, blame me!

I think that Sean raised a flag which should be seen as an acknowledgment
of a need to reconcile the two efforts; let's move past the blame game and
the language barriers, and let's figure out how to address Yuji's need
within the context of a single effort, without dismissing it. For this
reason I am going to suggest we iterate within the networking-sfc project,
and block change 186663 https://review.openstack.org/#/c/186663/. Let's
figure out how the model/API has to evolve to accommodate the proposed used
need.

If you disagree, please raise your concern on the patch in review itself.

Cheers,
Armando

On 28 July 2015 at 15:01, Sean M. Collins s...@coreitpro.com wrote:

 All,

 My suggestion was as follows:

  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

 I think there is overlap between the two APIs. Let's keep collaborating
 on both the networking-sfc and packet forwarding APIs, to see where we
 have commonality. I think Cathy's initial e-mail may have ruffled
 feathers - and I'd like to smooth them out again. I think the statement
 we only need one API is far too premature.

 Let's play nice with the other API proposals, yes?


 --
 Sean M. Collins

 __
 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] [magnum][blueprint] magnum-service-list

2015-07-28 Thread Jay Lau
Hi Suro,

Sorry for late. IMHO, even the magnum service-list is getting data from
DB, but the DB is actually persisting some data for Kubernetes service, so
my thinking is it possible to change magnum service-list to magnum
k8s-service-list, same for pod and rc.

I know this might bring some trouble for backward compatibility issue, not
sure if it is good to do such modification at this time. Comments?

Thanks

2015-07-27 20:12 GMT-04:00 SURO suro.p...@gmail.com:

  Hi all,
 As we did not hear back further on the requirement of this blueprint, I
 propose to keep the existing behavior without any modification.

 We would like to explore the decision on this blueprint on our next weekly
 IRC meeting[1].


 Regards,
 SURO
 irc//freenode: suro-patz

 [1] - https://wiki.openstack.org/wiki/Meetings/Containers

 2015-07-28  UTC 2200 Tuesday

  On 7/21/15 4:54 PM, SURO wrote:

 Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the
 following implementation -

- 'magnum service-list' should be similar to 'nova service-list'
- 'magnum service-list' should be moved to be ' magnum
k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list'

 As I dug some details, I find -

- 'magnum service-list' fetches data from OpenStack DB[2], instead of
the COE endpoint. So technically it is not k8s-specific. magnum is serving
data for objects modeled as 'service', just the way we are catering for
'magnum container-list' in case of swarm bay.
- If magnum provides a way to get the COE endpoint details, users can
use native tools to fetch the status of the COE-specific objects, viz.
'kubectl get services' here.
- nova has lot more backend services, e.g. cert, scheduler,
consoleauth, compute etc. in comparison to magnum's conductor only. Also,
not all the api's have this 'service-list' available.

 With these arguments in view, can we have some more
 explanation/clarification in favor of the ask in the blueprint? [1] -
 https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] -
 https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114

 --
 Regards,
 SURO
 irc//freenode: suro-patz




-- 
Thanks,

Jay Lau (Guangya Liu)
__
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

2015-07-28 Thread Evgeniy L
Aleksey, here is working version [1].

 Evgeniy, do we need to remove jinja before July 30th ?

With this issue feature can leave, and it won't have huge user impact.
At the same time by design we didn't want to have anything except
substitution, hence it's probably as Sergey mentioned is a bug.
So looks like it can be fixed after 30th of July, and should not be
considered as a blocker. Validation is much more important, so lets
fix it first.

[1] http://paste.openstack.org/show/406104/


On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko svasile...@mirantis.com
wrote:


 On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin akasat...@mirantis.com
 wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


 I think -- not.
 It just a bug, not a key-point of feature.


 /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] Barbican : Unable to create the secret after Integrating Barbican with HSM HA

2015-07-28 Thread John Vrbanac
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.commailto: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.commailto: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.commailto: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
# 

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

2015-07-28 Thread Aleksey Kasatkin
Okey, will do fix for validation first.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L e...@mirantis.com wrote:

 Aleksey, here is working version [1].

  Evgeniy, do we need to remove jinja before July 30th ?

 With this issue feature can leave, and it won't have huge user impact.
 At the same time by design we didn't want to have anything except
 substitution, hence it's probably as Sergey mentioned is a bug.
 So looks like it can be fixed after 30th of July, and should not be
 considered as a blocker. Validation is much more important, so lets
 fix it first.

 [1] http://paste.openstack.org/show/406104/


 On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko svasile...@mirantis.com
  wrote:


 On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin akasat...@mirantis.com
  wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


 I think -- not.
 It just a bug, not a key-point of feature.


 /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 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

2015-07-28 Thread Aleksey Kasatkin
Evgeniy, thank you for solution proposal.


Aleksey Kasatkin


On Tue, Jul 28, 2015 at 7:39 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:

 Okey, will do fix for validation first.


 Aleksey Kasatkin


 On Tue, Jul 28, 2015 at 7:30 PM, Evgeniy L e...@mirantis.com wrote:

 Aleksey, here is working version [1].

  Evgeniy, do we need to remove jinja before July 30th ?

 With this issue feature can leave, and it won't have huge user impact.
 At the same time by design we didn't want to have anything except
 substitution, hence it's probably as Sergey mentioned is a bug.
 So looks like it can be fixed after 30th of July, and should not be
 considered as a blocker. Validation is much more important, so lets
 fix it first.

 [1] http://paste.openstack.org/show/406104/


 On Tue, Jul 28, 2015 at 7:23 PM, Sergey Vasilenko 
 svasile...@mirantis.com wrote:


 On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin 
 akasat...@mirantis.com wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


 I think -- not.
 It just a bug, not a key-point of feature.


 /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 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][Plugins] Feedback

2015-07-28 Thread Patrick Petit
Hi

Additional comments inside.
Thanks
Patrick

On 28 Jul 2015 at 18:33:34, Sheena Gregson (sgreg...@mirantis.com) wrote:
Hey Sergii –

 

This is excellent feedback, thank you for taking the time to provide your 
thoughts.

 

#1 I agree that the documentation lag is challenging – I’m not sure how to best 
address this.  We could potentially prioritize updates to the Plugin SDK for 
soon-to-be-released features ahead of the standard release notes and user guide 
updates to ensure that plugin developers have access to this information 
earlier?  A number of the docs team members will be getting together in late 
August to discuss how to improve documentation, I will add this as a topic if 
we don’t feel there is good resolution on the mailing list.

+Alexander/Evgeny to cc for their input

+1. Yes that’s a huge impediment! Struggling myself with the same issue since 
we are supposed to release Plugins at about the same time as the new Plugins 
SDK released in Fuel. 

It’s also true that Plugins documentation lacks information about how to build 
the fpb builder.
 

#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the 
tab which should make it significantly easier for a user to find plugin 
settings.  Each plugin will create a new sub-group in the Settings tab, like 
Access (and others) in the screenshot below.

That’s certainly a very significant improvement compared to the previous 
version. But, as already stated in a retrospective meeting, going forward we’ll 
need an even more flexible way to link Plugins with settings in that settings 
could be made common to multiple plugins. I am thinking of more logical 
grouping (by feature category) independent of the underlying Plugins breakdown. 
For example, we could have an LMA monitoring settings category common to all 
LMA related plugins. This should be less confusing for users and avoid settings 
duplicates. Hope this is making sense…


 



 

I don’t have any insight on the GitHub issues, so I will wait for others to 
weigh in on your concerns there.

 

Sheena

 

From: Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
Sent: Tuesday, July 28, 2015 9:51 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: [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 
__
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

2015-07-28 Thread Sergey Vasilenko
On Tue, Jul 28, 2015 at 7:13 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:

 Evgeniy, do we need to remove jinja before July 30th ?


I think -- not.
It just a bug, not a key-point of feature.


/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] [fuel] OS_SERVICE_TOKEN usage in Fuel

2015-07-28 Thread Sergii Golovatiuk
Hi Oleksiy,

Good catch. Also OSTF should get endpoints from hiera as some plugins may
override the initial deployment settings. There may be cases when keystone
is detached by plugin.

--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser

On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov omolcha...@mirantis.com
wrote:

 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 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][Plugins] Feedback

2015-07-28 Thread Evgeniy L
Hi Sergii, thank you for feedback,

 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

We had a documentation, but removed it because the newer fpb was released,
probably we should add this information permanently [1].

 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?

These plugins are the data which are required for integration testing,
we test that plugin build is not broken, which we run when patch gets
published. I see nothing wrong with having the data for integration testing
in the same repository with product which should be tested.
Also in previous release we *removed* all the plugins which are not
related to the builder itself, lbaas and glusterfs.

 This breaks a couple of things

Having data for testing in the repository doesn't break anything.

 b. I cannot build fpm with simple

That is a good point, we should move code from fuel_plugin_builder directory
on top level, and move data for testing into examples directory.

 c. There is no tags as I can see only stable/6.0

Correct, tags should be added.

 d. There are no tests to improve code quality pep8 flask8, code coverage

That is not true, there are more then one hundreds unit tests which we run
for each patch with python 2.6 and python 2.7, also there are integration
tests
which check that for each patch we don't break validation and that we can
build plugins for previous versions. Plus there are functional tests which
are
written by fuel-qa team, those tests check that we perform deployment
with plugins and required functionality works correctly. Also there *is*
pep8
check [2].

 e. Repository doesn't follow community standards.

I think this issue should be resolved with moving fuel_plugin_builder
directory
on level higher, if not, please provide more specific description what is
wrong.

 3. Setting tab ...

Agree.

[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204
[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21

On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com
 wrote:

 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


__
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][Plugins] Feedback

2015-07-28 Thread Sheena Gregson
Hey Sergii –



This is excellent feedback, thank you for taking the time to provide your
thoughts.



#1 I agree that the documentation lag is challenging – I’m not sure how to
best address this.  We could potentially prioritize updates to the Plugin
SDK for soon-to-be-released features ahead of the standard release notes
and user guide updates to ensure that plugin developers have access to this
information earlier?  A number of the docs team members will be getting
together in late August to discuss how to improve documentation, I will add
this as a topic if we don’t feel there is good resolution on the mailing
list.

*+Alexander/Evgeny to cc for their input*



#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in
the tab which should make it significantly easier for a user to find plugin
settings.  Each plugin will create a new sub-group in the Settings tab,
like Access (and others) in the screenshot below.





I don’t have any insight on the GitHub issues, so I will wait for others to
weigh in on your concerns there.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 9:51 AM
*To:* OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
*Subject:* [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


[openstack-dev] [GSLB][LBaaS] Call for GSLB project driver nominations

2015-07-28 Thread Michael Johnson
Hello OpenStack,

We are starting up a project for Global Server Load Balancing (GSLB).
The Wiki page is here: https://wiki.openstack.org/wiki/GSLB

We are soliciting for project driver nominations for the initial team.

Drivers are expected to file, maintain, prioritize, and target
blueprints and bugs for the project in Launchpad.  Our Launchpad page
is: https://launchpad.net/gslb

Please reply to this email with your nominations.

Michael

__
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] [infra][puppet] Keeping common set of file synchronized across puppet modules

2015-07-28 Thread Andreas Jaeger

On 07/28/2015 03:35 PM, Yanis Guenane wrote:

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, thanks for the explanation. This helps to understand what you're 
doing. Still I have some questions. I'll also comment in the review with 
some specific comments.


Will this script do the same what propose_update.sh does, especially:

* Send a request to gerrit?
* If there is a proposed change already for a project, reuse that one 
instead of creating a new one?

* Will msync check out the git repositories itself?


Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] OS_SERVICE_TOKEN usage in Fuel

2015-07-28 Thread Andrew Woodward
IIRC the puppet modules, and even the heat domain create script make use of
the token straight from the config file. It not being present could cause
problems for some of the manifests. We would need to ensure that their
usage is minimized or removed.

On Tue, Jul 28, 2015 at 9:29 AM Sergii Golovatiuk sgolovat...@mirantis.com
wrote:

 Hi Oleksiy,

 Good catch. Also OSTF should get endpoints from hiera as some plugins may
 override the initial deployment settings. There may be cases when keystone
 is detached by plugin.

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

 On Tue, Jul 28, 2015 at 5:26 PM, Oleksiy Molchanov 
 omolcha...@mirantis.com wrote:

 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 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


Re: [openstack-dev] [nova][glance][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

2015-07-28 Thread Fox, Kevin M
+1. Our production system hit this on Juno - Kilo upgrade.

Thanks,
Kevin

From: Flavio Percoco [fla...@redhat.com]
Sent: Tuesday, July 28, 2015 7:15 AM
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.

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] [requirements] propose adding Robert Collins to requirements-core

2015-07-28 Thread Doug Hellmann
Excerpts from Doug Hellmann's message of 2015-07-24 12:21:16 -0400:
 Requirements reviewers,
 
 I propose that we add Robert Collins (lifeless) to the requirements-core
 review team.
 
 Robert has been doing excellent work this cycle with updating pip and
 our requirements repository to support constraints. As a result he has a
 full understanding of the sorts of checks we should be doing for new
 requirements, and I think he would make a good addition to the team.
 
 Please indicate +1 or -1 with concerns on this thread, as usual.

After 4 days with only positive responses, I went ahead and added Robert
to the team in gerrit.

Doug

__
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 for LP-1464656 fix (update ceph PG calculation algorithm)

2015-07-28 Thread Eugene Bogdanov
Good, thanks everyone for your feedback. Konstantin, let's do as 
suggested - merge pb_num calculation as a bugfix and postpone UI part 
for next release. Indeed, we don't need FF exception here.


--
EugeneB




Vitaly Kramskikh mailto:vkramsk...@mirantis.com
27 июля 2015 г., 13:57
+1 to Stanislav's proposal.




--
Vitaly Kramskikh,
Fuel UI Tech Lead,
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
Stanislav Makar mailto:sma...@mirantis.com
27 июля 2015 г., 3:05

Hello
I went through LP-1464656 and I see that it covers two things:
1. Bad pg num calculation algorithm.
2. Add the possibility to set pg num via GUI.

First is the most important and a BUG by itself, second is nice to 
have feature and no more.

Hence we should split it into a bug and a feature.

As the main part is a bug it does not impact FF at all.

My +1 to close bad pg num calculation algorithm as a bug and postpone 
specifying pg_num via GUI to the next release.


/All the best
Stanislav Makar

+1 for FFE
Given how borken pg_num calculations are now, this is essential to the 
ceph story and there is no point in testing ceph at scale with out it.


The only work-around for not having this is to delete all of the pools 
by hand after deployment and calculate the values by hand, and 
re-create the pools by hand. The story from that alone makes it high 
on the UX scale, which means we might as well fix it as a bug.


The scope of impact is limited to only ceph, the testing plan needs 
more detail, and we are still comming to turns with some of the data 
format to process between nailgun calculating and puppet consuming.


We would need about 1.2 week to get these landed.

--

--

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://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
Andrew Woodward mailto:xar...@gmail.com
25 июля 2015 г., 1:58
+1 for FFE
Given how borken pg_num calculations are now, this is essential to the 
ceph story and there is no point in testing ceph at scale with out it.


The only work-around for not having this is to delete all of the pools 
by hand after deployment and calculate the values by hand, and 
re-create the pools by hand. The story from that alone makes it high 
on the UX scale, which means we might as well fix it as a bug.


The scope of impact is limited to only ceph, the testing plan needs 
more detail, and we are still comming to turns with some of the data 
format to process between nailgun calculating and puppet consuming.


We would need about 1.2 week to get these landed.

--

--

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
Konstantin Danilov mailto:kdani...@mirantis.com
24 июля 2015 г., 13:46
Team,

I would like to request an exception from the Feature Freeze for [1]
fix. It requires changes in
fuel-web [2], fuel-library [3] and in UI. [2] and [3] are already
tested, I'm fixing UT now.
BP - [4]

Code has backward-compatibility mode. I need one more week to finish 
it. Also
I'm asking someone to be an assigned code-reviewer for this ticket to 
speed-up

review process.

Thanks

[1] https://bugs.launchpad.net/fuel/+bug/1464656
[2] https://review.openstack.org/#/c/204814
[3] https://review.openstack.org/#/c/204811
[4] https://review.openstack.org/#/c/203062



__
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

2015-07-28 Thread Matt Riedemann



On 7/28/2015 9:24 AM, Kuvaja, Erno wrote:

-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



Nova doesn't support glance v2 in kilo or liberty, so does it matter to 
nova if this is in stable/kilo or not?  Doesn't seem like it.  This is a 
barrier to getting glance v2 support into nova in mitaka though it seems.


--

Thanks,

Matt Riedemann


__
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] VM for Openstack Horizon error

2015-07-28 Thread Chandeep Khamba

Hi Guys,


I have a VM and did a ansible-playbook on main.yaml.

Looks like the Yaml files for the services has a thing  
https://stash.us.cray.com/projects/NEWT/repos/openstack-ansible/browse/openstack.yaml

# FIXME: Anvil does not currently provide the dashboard packages
- include: services/dashboard/main.yaml
  when: not using_anvil
- include: services/heat/main.yaml


It does not let me install the horizon dashboard on my VM..

Does anyone have an idea what an anvil is , and can I disable it ??



Thanks
Chandeep
__
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][Plugins] Feedback

2015-07-28 Thread Sheena Gregson
Evgeniy –



For the items which you have listed actions, who should be responsible for
next steps?



Sheena



*From:* Evgeniy L [mailto:e...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 11:54 AM
*To:* OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



Hi Sergii, thank you for feedback,



 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



We had a documentation, but removed it because the newer fpb was released,

probably we should add this information permanently [1].



 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?



These plugins are the data which are required for integration testing,

we test that plugin build is not broken, which we run when patch gets

published. I see nothing wrong with having the data for integration testing

in the same repository with product which should be tested.

Also in previous release we *removed* all the plugins which are not

related to the builder itself, lbaas and glusterfs.



 This breaks a couple of things



Having data for testing in the repository doesn't break anything.



 b. I cannot build fpm with simple



That is a good point, we should move code from fuel_plugin_builder directory

on top level, and move data for testing into examples directory.



 c. There is no tags as I can see only stable/6.0



Correct, tags should be added.



 d. There are no tests to improve code quality pep8 flask8, code coverage



That is not true, there are more then one hundreds unit tests which we run

for each patch with python 2.6 and python 2.7, also there are integration
tests

which check that for each patch we don't break validation and that we can

build plugins for previous versions. Plus there are functional tests which
are

written by fuel-qa team, those tests check that we perform deployment

with plugins and required functionality works correctly. Also there *is*
pep8

check [2].



 e. Repository doesn't follow community standards.



I think this issue should be resolved with moving fuel_plugin_builder
directory

on level higher, if not, please provide more specific description what is
wrong.



 3. Setting tab ...



Agree.



[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204

[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com
wrote:

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

  1   2   >