date:20140429

Currently, Nova API achieve this feature based on the database’s REGEX support. 
Do you have advice on alternative way to achieve it?


--
zhangleiqiang (Trump)

Best Regards

From: laserjetyang [mailto:laserjety...@gmail.com]
Sent: Tuesday, April 29, 2014 1:49 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Cinder] cinder not support query volume/snapshot 
with regular expression

It looks to me the Nova API will be dangerous source of DoS attacks due to the 
regexp?

On Mon, Apr 28, 2014 at 7:04 PM, Duncan Thomas 
duncan.tho...@gmail.commailto:duncan.tho...@gmail.com wrote:
Regex matching in APIs can be a dangerous source of DoS attacks - see
http://en.wikipedia.org/wiki/ReDoS. Unless this is mitigated sensibly,
I will continue to resist any cinder patch that adds them.

Glob matches might be safer?

On 26 April 2014 05:02, Zhangleiqiang (Trump) 
zhangleiqi...@huawei.commailto:zhangleiqi...@huawei.com wrote:
 Hi, all:

 I see Nova allows search instances by name, ip and ip6 fields which 
 can be normal string and regular expression:

 [stack@leiqzhang-stack cinder]$ nova help list

 List active servers.

 Optional arguments:
 --ip ip-regexp  Search with regular expression match by 
 IP address
 (Admin only).
 --ip6 ip6-regexpSearch with regular expression match by 
 IPv6 address
  (Admin only).
 --name name-regexp  Search with regular expression match by 
 name
 --instance-name name-regexp Search with regular expression 
 match by server name
 (Admin only).

 I think it is also needed for Cinder when query the 
 volume/snapshot/backup by name. Any advice?

 --
 zhangleiqiang (Trump)

 Best Regards


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Duncan Thomas

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?

2014-04-29 Thread Robert Collins

On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote:



 Sure: domain names are unambiguous but user mutable, whereas Heat's approach
 to using admin tenant name is at risk to both mutability and ambiguity (in
 a multi-domain deployment).

Isn't domainname/user unambiguous and unique? mutability is really not
keystones choice.

If keystone won't accept domainname/user then that will force us to
either do two stack-updates for a single deploy (ugly) or write
patches to heat (and neutron where the callback-to-nova support has
the same issue) to manually try a lookup and work around this.

Since its trivial to write such a thunk, what benefit is there to your
users - e.g. TripleO/heat/nova not have it in keystone itself?

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Cinder] Question about the magic 100M when creating zero-size volume

Hi, all:

I find in some of the cinder backend volume drivers, there are codes in 
create_volume as follows:

#cinder.volume.drivers.lvm
def _sizestr(self, size_in_g):
if int(size_in_g) == 0:
return '100m'

Similar codes also exist in ibm.gpfs, san.hp.hp_lefthand_cliq_proxy, 
san.solaris and huawei.ssh_common. I wonder why the 100M is used here, from 
the git log I cannot find useful info.

Thanks.


--
zhangleiqiang (Trump)

Best Regards



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Location of Monitoring Checks

2014-04-29 Thread Macdonald-Wallace, Matthew

Hi all,

I have a patch in flight at the moment [0] to install check_mk server and 
compliment the already merged installation of check_mk agent [1] so my thoughts 
are now turning to how we would recommend adding new service checks.

The concept behind check_mk makes this really simple to do.  You just place a 
script that outputs status_code check_name performance_data message 
into the agent's local directory (/usr/lib/check_mk_agent/local on Ubuntu for 
example) and it will be picked up the next time an inventory of the system is 
run.

There are two ways that we can recommend doing this:

1) We ask users to update the check_mk_agent T-I-E every time they wish to add 
a new check
2) We ask users to distribute checks from their own T-I-E into the correct 
location

In my opinion, requiring an update to check_mk_agent for every new check is the 
wrong way of doing this as it means that all systems get all checks regardless 
of function.  Far more preferable would be option 2, however I'm open to other 
ideas, especially if they mean that organisations using this don't have to go 
through the review process if they have checks they wish to keep behind the 
firewall for IP/Licensing reasons.

Thanks in advance for any help people can give on this,

Matt

[0] https://review.openstack.org/#/c/87226/
[1] https://review.openstack.org/#/c/81485/


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova] Add Qcow2 volume encryption support

Hi, all:

I find Nova has supported volume encryption for LVM volume ([1]). 
Currently , qcow2 also support encryption now, and there is libvirt's support 
too ([2]). After reading up the implementation, qcow2's support can be added to 
current framework.
Do you think it is meaningful to introduce the support for qcow2 volume 
encryption? The use case can be found in [1].

[1] https://wiki.openstack.org/wiki/VolumeEncryption
[2] http://libvirt.org/formatstorageencryption.html


--
zhangleiqiang (Trump)

Best Regards



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Add Qcow2 volume encryption support

2014-04-29 Thread Daniel P. Berrange

On Tue, Apr 29, 2014 at 09:17:05AM +, Zhangleiqiang (Trump) wrote:
 Hi, all:
 
   I find Nova has supported volume encryption for LVM volume ([1]).
 Currently , qcow2 also support encryption now, and there is libvirt's
 support too ([2]). After reading up the implementation, qcow2's support
 can be added to current framework.
   Do you think it is meaningful to introduce the support for qcow2
 volume encryption? The use case can be found in [1].

Support for qcow2 encryption has been proposed before and explicitly
rejected because qcow2's encryption scheme is considered fatally flawed
by design. See the warnings here

  http://qemu.weilnetz.de/qemu-doc.html#disk_005fimages_005fformats

In the short term simply avoid all use qcow2 where encryption is required
and instead use LVM with dm-crypt which is known secure  well reviewed
by cryptographers.

In the medium-long term QCow2's built-in encryption scheme has to be
completely thrown away, and replaced by a new scheme that uses the
LUKS file format specification internally.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ask for help reviewing nova-specs

2014-04-29 Thread sxmatch

Hi,guys:

There is a nova-specs add force detach volume to nova
（https://review.openstack.org/#/c/84048/）that need more review.
It has core review +1 by John. I wish it could be merged before May Day.

Thanks your help a lot!
app:ds:May%20Day
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [marconi] performance

2014-04-29 Thread Flavio Percoco


On 28/04/14 17:41 +, Janczuk, Tomasz wrote:

Hello,

Have any performance numbers been published for Marconi? I have asked this 
question before 
(http://lists.openstack.org/pipermail/openstack-dev/2014-March/031004.html) but 
there were none at that time.




Hi Tomasz,

Some folks in the team are dedicated to working on this and producing
results asap. The details and results will be shared as soon as
possible.

Thanks a lot for your interest, I'll make sure you're in the loop as
soon as we have them.

--
@flaper87
Flavio Percoco


pgpb60aS9m0UE.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Add Qcow2 volume encryption support

@Daniel:

Thanks for your explanation, it helps me a lot. 


--
zhangleiqiang (Trump)

Best Regards


 -Original Message-
 From: Daniel P. Berrange [mailto:berra...@redhat.com]
 Sent: Tuesday, April 29, 2014 5:33 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova] Add Qcow2 volume encryption support
 
 On Tue, Apr 29, 2014 at 09:17:05AM +, Zhangleiqiang (Trump) wrote:
  Hi, all:
 
  I find Nova has supported volume encryption for LVM volume ([1]).
  Currently , qcow2 also support encryption now, and there is libvirt's
  support too ([2]). After reading up the implementation, qcow2's
  support can be added to current framework.
  Do you think it is meaningful to introduce the support for qcow2
  volume encryption? The use case can be found in [1].
 
 Support for qcow2 encryption has been proposed before and explicitly rejected
 because qcow2's encryption scheme is considered fatally flawed by design. See
 the warnings here
 
   http://qemu.weilnetz.de/qemu-doc.html#disk_005fimages_005fformats
 
 In the short term simply avoid all use qcow2 where encryption is required and
 instead use LVM with dm-crypt which is known secure  well reviewed by
 cryptographers.
 
 In the medium-long term QCow2's built-in encryption scheme has to be
 completely thrown away, and replaced by a new scheme that uses the LUKS file
 format specification internally.
 
 Regards,
 Daniel
 --
 |: http://berrange.com  -o-
 http://www.flickr.com/photos/dberrange/ :|
 |: http://libvirt.org  -o-
 http://virt-manager.org :|
 |: http://autobuild.org   -o-
 http://search.cpan.org/~danberr/ :|
 |: http://entangle-photo.org   -o-
 http://live.gnome.org/gtk-vnc :|
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [MagnetoDB] Configuring consistency draft of concept

2014-04-29 Thread Illia Khudoshyn

Hi all,

Dima, I think I understand your reasoning but I have some issues with that.
I agree that binary logic is much more straightforward and easy to
understand and use. But following that logic, having the only one hardcoded
consistency level is even easier and more understandable.
As I can see, the idea of the proposal is to provide user a more
fine-grained control on consistency to leverage backend features AND at the
same time to not bound ourselves with only this concrete backend's
features. In scope of Maksym's proposal choice between WEAK/QUORUM for me
is pretty much the same as your FALSE/TRUE. But I'd prefer to have more.

PS Eager to see your new index design


On Tue, Apr 29, 2014 at 7:44 AM, Dmitriy Ukhlov dukh...@mirantis.comwrote:


 Hello Maksym,

 Thank you for your work!

 I suggest you to consider more general approach and hide backend specific
 staff. I have the next proposal:
 1) add support for inconsistent write operation by adding PutItem,
 UpdateItem and DeleteItem request parameters consistent = True of False
 (as well as GetItem and Query requests)
 2) add possibility to set backend specific metadata (it would be nice to
 use some generic format like json) per table in scope of create table
 request. I suggest to specify mapping for Cassandra consistency level per
 operation type (consistent read, inconsistent read, consistent write,
 inconsistent write)

 I agree that now we have a limitation for inconsistent write operation on
 tables with indexed fields and for requests with specified expected
 conditions. I have thought about how to overcome this limitation and it
 seems that I found out solution for index handling without CAS operation.
 And maybe it is reasonable to redesign it a bit.

 On Mon, Apr 28, 2014 at 8:33 AM, MAKSYM IARMAK (CS) 
 maksym_iar...@symantec.com wrote:

  Hi,

 Because of we can't use inconsistent write if we use indexed table and
 condition operations which indexes based on (this staff requires the state
 of data), we have one more issue.

 If we want to make write with consistency level ONE (WEAK) to the indexed
 table, we will have 2 variants:
 1. Carry out the operation successfully and implicitly make write to the
 indexed table with minimally possible consistency level for it (QUORUM);
 2. Raise an exception, that we can not perform this operation and list
 all possible CLs for this operation.

 I personally prefer the 2nd variant. So, does anybody have some
 objections or maybe another ideas?

  --
 *From:* MAKSYM IARMAK (CS) [maksym_iar...@symantec.com]
 *Sent:* Friday, April 25, 2014 9:14 PM
 *To:* openstack-dev@lists.openstack.org
 *Subject:* [openstack-dev] [MagnetoDB] Configuring consistency draft of
 concept

   So, here is specification draft of concept.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Best regards,
 Dmitriy Ukhlov
 Mirantis Inc.




-- 

Best regards,

Illia Khudoshyn,
Software Engineer, Mirantis, Inc.



38, Lenina ave. Kharkov, Ukraine

www.mirantis.com http://www.mirantis.ru/

www.mirantis.ru



Skype: gluke_work

ikhudos...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Infra] Gerrit upgrade

2014-04-29 Thread Gary Kotton

Hi,
Thanks to all those involved. Any chance of restoring the Diff side by side 
button. The new interface may take a while to get used to. In the past there 
was a link to the current branch patches. That too is missing.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Samuel Bercovici

Hi,

I think it is a good idea to have the use cases in a different document that 
API proposals (Stephen's, included)
Once we declare the uses cases done for Juno, I will move it to the BP 
repository.
I would also like to see operator's use cases flushed out in the document.

Stephen, could you please open the document also for editing?

Regards,
-Sam.




-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com] 
Sent: Tuesday, April 29, 2014 5:27 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff sbaluk...@bluebox.net wrote:
 Hi guys,

 Sorry for all the drama on the list lately.

Not a problem. Like I said, the passion from all sides is great, and I'm 
especially happy to see all the operators engaging with Neutron for LBaaS.

 Kyle: I appreciate the sentiment. I'd also be happy to open up my API 
 doc for general editing by people on the internet (and not just 
 comments) if you think that would help.

My main reason for asking this was in case the gerrit bar was too high for new 
people to Neutron and LBaaS in particular. I want to make sure we capture 
everyone's ideas and allow everyone a chance to comment.
The gerrit BP process does this nicely, but I just want to ensure it's not too 
high of a bar for people new to the entire process.

 For us new-comers to the OpenStack project environment, what do people 
 usually use for discussing potential design changes (and especially 
 large design changes)?  (From my perspective, Blue prints seem mostly 
 useful as collections of links to other documents, without having an 
 obvious way to discuss things in the blueprint directly. Gerrit seems 
 like it's mostly github workflow with CI baked in-- ie. useful for 
 specific smaller code changes, but not as much for design-level 
 discussions. I suppose etherpads might duplicate much of the 
 functionality we're currently using google docs to accomplish (though 
 I don't think etherpads have the ability to do spreadsheets, from what I can 
 tell).

I think it's fine to use the gdoc for now, with the idea being we will then 
converge on work items formed into multiple BPs out of the gdoc.
So perhaps it does make sense to use your document as the communal starting 
point for this. But I'm open to what others may say as well.

 As far as the meetings go: It might help if you could share with us 
 what you hope to accomplish prior to the summit, and what kinds of 
 things you'd like us to be prepared to discuss at the summit. (Is 
 there an LBaaS meeting of some kind scheduled there yet?)

I've given LBaaS 2 40 minute sessions. What I'd like us to do is come to come 
to a consensus on what needs discussing in person vs. what everyone is agreeing 
on and we don't need to discuss in those sessions. If we need time to discuss 
the object model and API in Atlanta, that's fine too.

 For my part, I plan on concentrating on filling out more use cases and 
 then returning to the software load balancer virtual appliance porting 
 project that's been on the back-burner for way too long for me.

Perfect! How about if we try to close the use case gap for this week's LBaaS 
meeting. Then, next week we can at least make a stab at the object model and 
API which satisfies as many use cases as we come up with.

 Samuel and German: I've gone ahead and added around 20 new use cases 
 to the google doc you linked. More will be on the way, but I'm happy 
 to add these to gerrit myself if you'd prefer, so long as I can see 
 how you're doing this for the first use cases and can follow your 
 template. Let me know if you'd like me to change what I've been doing 
 here, eh! Note also that so far these are only user use cases; It 
 doesn't look like admin/operator use cases have been filled out at all yet.

Getting the admin/operator use cases in there would be good as well Stephen.

Thanks,
Kyle

 Thanks,
 Stephen




 On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
 german.eichber...@hp.com wrote:

 Sam,

 The use cases where pretty complete the last time I checked so let's 
 move them to gerrit so we can all vote.

 Echoing Kyle I would love to see us focusing on getting things ready 
 for the summit.

 German

 -Original Message-
 From: Samuel Bercovici [mailto:samu...@radware.com]
 Sent: Monday, April 28, 2014 11:44 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API 
 proposal

 Hi,

 I was just working to push the use cases into the new format .rst but 
 I agree that using google doc would be more intuitive.
 Let me know what you prefer to do with the use cases document:
 1. leave it at google docs at -
 https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR
 1-mXuSINis/edit?pli=1
 2. Move it to the new format under -

[openstack-dev] [Juno-Summit] availability of the project project pod rooms on Monday May 12th?

2014-04-29 Thread Eoghan Glynn


... the $subject says it all.

Wondering about dedicated spaces for a cores meet-up prior
to the design summit proper kicking off on the Tuesday.

Thanks!
Eoghan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Gerrit New vs. Old Change Views

2014-04-29 Thread Sean Dague

While the infra team I've seen a lot of questions floating on IRC where
people are finding that things are missing, not usable. They are mostly
related to the New change view.

It's worth noting that among the infra team the New change screen is
considered unusable (there is a solid jeblair rant in here that I'm sure
he'll share once the dust settles). However with this version of Gerrit
we finally get a rest API, so it's possible to do more interesting
custom UI on top of Gerrit.

Remember, that before the Gerrit upstream team took the CSS style
developed for OpenStack, gerrit looked like this -
http://agentdero.cachefly.net/unethicalblogger.com/images/gerrit_changeoverview.png

There is a reason that the old change view is the default. :)

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Juno-Summit] availability of the project project pod rooms on Monday May 12th?

IIRC Thierry said that pods will be available starting from Monday.

On Tue, Apr 29, 2014 at 2:56 PM, Eoghan Glynn egl...@redhat.com wrote:

 ... the $subject says it all.

 Wondering about dedicated spaces for a cores meet-up prior
 to the design summit proper kicking off on the Tuesday.

 Thanks!
 Eoghan

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Gerrit New vs. Old Change Views

Yup, it sounds like for now the old screen is the only option. I'm now
trying to work using the new screen and collect some most annoying
issues.

On Tue, Apr 29, 2014 at 3:20 PM, Sean Dague s...@dague.net wrote:
 While the infra team I've seen a lot of questions floating on IRC where
 people are finding that things are missing, not usable. They are mostly
 related to the New change view.

 It's worth noting that among the infra team the New change screen is
 considered unusable (there is a solid jeblair rant in here that I'm sure
 he'll share once the dust settles). However with this version of Gerrit
 we finally get a rest API, so it's possible to do more interesting
 custom UI on top of Gerrit.

 Remember, that before the Gerrit upstream team took the CSS style
 developed for OpenStack, gerrit looked like this -
 http://agentdero.cachefly.net/unethicalblogger.com/images/gerrit_changeoverview.png

 There is a reason that the old change view is the default. :)

 -Sean

 --
 Sean Dague
 http://dague.net


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][IPv6] Cannot make it today

2014-04-29 Thread Shixiong Shang

Hi, guys:

For two weeks in the row, I have customer meeting at 10am EDT, which conflicts 
with our weekly Neutron IPv6 call. I hope this meeting schedule won’t be 
permanent…Will try my best to avoid it. 

Sorry for the absence. :(

Shixiong


Shixiong Shang

!--- Stay Hungry, Stay Foolish ---!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ceilometer] Error running ceilometer tox tests

On Mon, Apr 28, 2014 at 6:20 PM, Pendergrass, Eric
eric.pendergr...@hp.com wrote:
 Hi, I pulled devstack yesterday and have been trying to get any test to run
 successfully.



 My process is this:

 Install tox =1.6,1.7

 Install libmysqlclient-dev

 Install mongodb-server

 Source .tox/py27/bin/activate

 Install test-requuirements packages in venv

 Install pytidylib 0.2.1 from tarball

This step stands out as unusual. It should be enough to run tox
without doing anything extra. Are you adding pytidylib to ceilometer
for some reason?

Doug


 Execute tox –e py27 – api.v2



 Here is the result (many lines of output omitted):

 error: testr failed (3)

 + clean_exit

 + local error_code=1

 + rm -rf /tmp/CEILO-MONGODB-ezBtk

 ++ jobs -p

 + kill 13439 13463

 + return 1

 ERROR: InvocationError: '/bin/bash -x
 /opt/stack/ceilometer/setup-test-env.sh python setup.py testr --slowest
 --testr-args=api.v2'

 
 summary
 _

 ERROR:   py27: commands failed



 I’ve seen this work on a copy of devstack I cloned several weeks ago.



 Does anyone know what’s causing the testr failures?



 Thank you,

 Eric Pendergrass


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Timestamp formats in the REST API

2014-04-29 Thread Mark McLoughlin

Hey

In this patch:

  https://review.openstack.org/83681

by Ghanshyam Mann, we encountered an unusual situation where a timestamp
in the returned XML looked like this:

  2014-04-08 09:00:14.399708+00:00

What appeared to be unusual was that the timestamp had both sub-second
time resolution and timezone information. It was felt that this wasn't a
valid timestamp format and then some debate about how to 'fix' it:

  https://review.openstack.org/87563

Anyway, this lead me down a bit of a rabbit hole, so I'm going to
attempt to document some findings.

Firstly, some definitions:

  - Python's datetime module talk about datetime objects being 'naive' 
or 'aware'

https://docs.python.org/2.7/library/datetime.html

   A datetime object d is aware if d.tzinfo is not None and
d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None,
or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns
None, d is naive.

(Most people will have encountered this already, but I'm including 
it for completeness)

  - The ISO8601 time and date format specifies timestamps like this:

2014-04-29T11:37:00Z

with many variations. One distinguishing aspect of the ISO8601 
format is the 'T' separating date and time. RFC3339 is very closely
related and serves as easily accessible documentation of the format:

   http://www.ietf.org/rfc/rfc3339.txt

  - The Python iso8601 library allows parsing this time format, but 
also allows subtle variations that don't conform to the standard 
like omitting the 'T' separator:

   import iso8601
   iso8601.parse_date('2014-04-29 11:37:00Z')
  datetime.datetime(2014, 4, 29, 11, 37, tzinfo=iso8601.iso8601.Utc object 
at 0x214b050)

Presumably this is for the pragmatic reason that when you stringify 
a datetime object, the resulting string uses ' ' as a separator:

   import datetime
   str(datetime.datetime(2014, 4, 29, 11, 37))
  '2014-04-29 11:37:00'

And now some observations on what's going on in Nova:

  - We don't store timezone information in the database, but all our 
timestamps are relative to UTC nonetheless.

  - The objects code automatically adds the UTC to naive datetime 
objects:

if value.utcoffset() is None:
value = value.replace(tzinfo=iso8601.iso8601.Utc())

so code that is ported to objects may now be using aware datetime 
objects where they were previously using naive objects.

  - Whether we store sub-second resolution timestamps in the database 
appears to be database specific. In my quick tests, we store that 
information in sqlite but not MySQL.

  - However, timestamps added by SQLAlchemy when you do e.g. save() do 
include sub-second information, so some DB API calls may return 
sub-second timestamps even when that information isn't stored in 
the database.

In our REST APIs, you'll essentially see one of three time formats. I'm
calling them 'isotime', 'strtime' and 'xmltime':

  - 'isotime' - this is the result from timeutils.isotime(). It 
includes timezone information (i.e. a 'Z' prefix) but not 
microseconds. You'll see this in places where we stringify the 
datetime objects in the API layer using isotime() before passing 
them to the JSON/XML serializers.

  - 'strtime' - this is the result from timeutils.strtime(). It doesn't 
include timezone information but does include decimal seconds. This 
is what jsonutils.dumps() uses when we're serializing API responses 

  - 'xmltime' or 'str(datetime)' format - this is just what you get 
when you stringify a datetime using str(). If the datetime is tz 
aware or includes non-zero microseconds, then that information will 
be included in the result. This is a significant different versus 
the other two formats where it is clear whether tz and microsecond 
information is included in the string.

but there are some caveats:

  - I don't know how significant it is these days, but timestamps will 
be serialized to strtime format when going over RPC, but won't be 
de-serialized on the remote end. This could lead to a situation 
where the API layer tries and stringify a strtime formatted string
using timeutils.isotime(). (see below for a description of those 
formats)

  - In at least one place - e.g. the 'updated' timestamp for v2
extensions - we hardcode the timestamp as strings in the code and 
don't currently use one of the formats above.


My conclusions from all that:

  1) This sucks

  2) At the very least, we should be clear in our API samples tests 
 which of the three formats we expect - we should only change the 
 format used in a given part of the API after considering any 
 compatibility considerations

  3) We should unify on a single format in the v3 API - IMHO, we should 
 be explicit about use of the UTC timezone and we should avoid 
 including

Re: [openstack-dev] [all] Gerrit New vs. Old Change Views

2014-04-29 Thread Anita Kuno

On 04/29/2014 08:26 AM, Sergey Lukjanov wrote:
 Yup, it sounds like for now the old screen is the only option. I'm now
 trying to work using the new screen and collect some most annoying
 issues.
Khai had linked to an etherpad that wikimedia has been working on to
collect their thoughts on the new screen. You might find some fodder
there: http://etherpad.wikimedia.org/p/new-gerrit-change-view-comments

Thanks,
Anita.
 
 On Tue, Apr 29, 2014 at 3:20 PM, Sean Dague s...@dague.net wrote:
 While the infra team I've seen a lot of questions floating on IRC where
 people are finding that things are missing, not usable. They are mostly
 related to the New change view.

 It's worth noting that among the infra team the New change screen is
 considered unusable (there is a solid jeblair rant in here that I'm sure
 he'll share once the dust settles). However with this version of Gerrit
 we finally get a rest API, so it's possible to do more interesting
 custom UI on top of Gerrit.

 Remember, that before the Gerrit upstream team took the CSS style
 developed for OpenStack, gerrit looked like this -
 http://agentdero.cachefly.net/unethicalblogger.com/images/gerrit_changeoverview.png

 There is a reason that the old change view is the default. :)

 -Sean

 --
 Sean Dague
 http://dague.net


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Infra] Gerrit upgrade

2014-04-29 Thread Jeremy Stanley

On 2014-04-29 07:09:42 -0400 (-0400), Sean Dague wrote:
 Use the old change view.

Specifically, if you browse to
https://review.openstack.org/#/settings/preferences by default
everyone normally starts at Change View: Server Default (Old Screen)
so if you make sure it's set to that (or really just not set to New
Screen) then it should look *mostly* like before.

The new change view is still really not in a state we consider
supportable, but need to collaborate further with upstream Gerrit
developers to improve it there and then backport/upgrade to whatever
fixes we work out with them.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Gerrit New vs. Old Change Views

Anita, thanks, I'll take a look on it.

I just find the very nice pros - new screen detects changes and shows
small notification, it's very useful for folks like me how opening 500
tabs for review and than iterating through them.

On Tue, Apr 29, 2014 at 5:51 PM, Anita Kuno ante...@anteaya.info wrote:
 On 04/29/2014 08:26 AM, Sergey Lukjanov wrote:
 Yup, it sounds like for now the old screen is the only option. I'm now
 trying to work using the new screen and collect some most annoying
 issues.
 Khai had linked to an etherpad that wikimedia has been working on to
 collect their thoughts on the new screen. You might find some fodder
 there: http://etherpad.wikimedia.org/p/new-gerrit-change-view-comments

 Thanks,
 Anita.

 On Tue, Apr 29, 2014 at 3:20 PM, Sean Dague s...@dague.net wrote:
 While the infra team I've seen a lot of questions floating on IRC where
 people are finding that things are missing, not usable. They are mostly
 related to the New change view.

 It's worth noting that among the infra team the New change screen is
 considered unusable (there is a solid jeblair rant in here that I'm sure
 he'll share once the dust settles). However with this version of Gerrit
 we finally get a rest API, so it's possible to do more interesting
 custom UI on top of Gerrit.

 Remember, that before the Gerrit upstream team took the CSS style
 developed for OpenStack, gerrit looked like this -
 http://agentdero.cachefly.net/unethicalblogger.com/images/gerrit_changeoverview.png

 There is a reason that the old change view is the default. :)

 -Sean

 --
 Sean Dague
 http://dague.net


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Timestamp formats in the REST API

2014-04-29 Thread Mark McLoughlin

On Tue, 2014-04-29 at 14:48 +0100, Mark McLoughlin wrote:

 My conclusions from all that:
 
   1) This sucks
 
   2) At the very least, we should be clear in our API samples tests 
  which of the three formats we expect - we should only change the 
  format used in a given part of the API after considering any 
  compatibility considerations
 
   3) We should unify on a single format in the v3 API - IMHO, we should 
  be explicit about use of the UTC timezone and we should avoid 
  including microseconds unless there's a clear use case. In other 
  words, we should use the 'isotime' format.
 
   4) The 'xmltime' format is just a dumb historical mistake and since 
  XML support is now firmly out of favor, let's not waste time 
  improving the timestamp situation in XML.
 
   5) We should at least consider moving to a single format in the v2 
  (JSON) API. IMHO, moving from strtime to isotime for fields like 
  created_at and updated_at would be highly unlikely to cause any 
  real issues for API users.
 
 (Following up this email with some patches that I'll link to, but I want
 to link to this email from the patches themselves)

See here:

  
https://review.openstack.org/#/q/project:openstack/nova+topic:timestamp-format,n,z

Mark.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-04-29 Thread Thomas Goirand

On 04/29/2014 06:42 AM, Jeremy Stanley wrote:
 On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote:
 Just a friendly reminder to add yourself to this list if you are
 interested in participating in the key signing in Atlanta:

 https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit
 [...]
 
 It has a sign-up cutoff of two weeks ago, so I assume that was
 merely a placeholder. Which begs the question how late is too late
 for participants to be able to comfortably print out their copies
 (assuming we do http://keysigning.org/methods/sassaman-efficient
 this time)? Should lock down the page Wednesday May 7th? Sooner?
 
 Keep in mind that this week (April 27 through May 3) is supposed to
 be a vacation week for the project, so people may not be around to
 add themselves until Monday May 5th ;)

Is there a date a place already schedule for the key signing party?

Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Timestamp formats in the REST API

2014-04-29 Thread Miller, Mark M (EB SW Cloud - RD - Corvallis)

On Tue, Apr 29, 2014 at 9:48 AM, Mark McLoughlin mar...@redhat.com wrote:
 Hey

 In this patch:

   https://review.openstack.org/83681

 by Ghanshyam Mann, we encountered an unusual situation where a timestamp
 in the returned XML looked like this:

   2014-04-08 09:00:14.399708+00:00

 What appeared to be unusual was that the timestamp had both sub-second
 time resolution and timezone information. It was felt that this wasn't a
 valid timestamp format and then some debate about how to 'fix' it:

   https://review.openstack.org/87563

 Anyway, this lead me down a bit of a rabbit hole, so I'm going to
 attempt to document some findings.

 Firstly, some definitions:

   - Python's datetime module talk about datetime objects being 'naive'
 or 'aware'

 https://docs.python.org/2.7/library/datetime.html

A datetime object d is aware if d.tzinfo is not None and
 d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None,
 or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns
 None, d is naive.

 (Most people will have encountered this already, but I'm including
 it for completeness)

   - The ISO8601 time and date format specifies timestamps like this:

 2014-04-29T11:37:00Z

 with many variations. One distinguishing aspect of the ISO8601
 format is the 'T' separating date and time. RFC3339 is very closely
 related and serves as easily accessible documentation of the format:

http://www.ietf.org/rfc/rfc3339.txt

   - The Python iso8601 library allows parsing this time format, but
 also allows subtle variations that don't conform to the standard
 like omitting the 'T' separator:

import iso8601
iso8601.parse_date('2014-04-29 11:37:00Z')
   datetime.datetime(2014, 4, 29, 11, 37, tzinfo=iso8601.iso8601.Utc 
 object at 0x214b050)

 Presumably this is for the pragmatic reason that when you stringify
 a datetime object, the resulting string uses ' ' as a separator:

import datetime
str(datetime.datetime(2014, 4, 29, 11, 37))
   '2014-04-29 11:37:00'

 And now some observations on what's going on in Nova:

   - We don't store timezone information in the database, but all our
 timestamps are relative to UTC nonetheless.

   - The objects code automatically adds the UTC to naive datetime
 objects:

 if value.utcoffset() is None:
 value = value.replace(tzinfo=iso8601.iso8601.Utc())

 so code that is ported to objects may now be using aware datetime
 objects where they were previously using naive objects.

   - Whether we store sub-second resolution timestamps in the database
 appears to be database specific. In my quick tests, we store that
 information in sqlite but not MySQL.

   - However, timestamps added by SQLAlchemy when you do e.g. save() do
 include sub-second information, so some DB API calls may return
 sub-second timestamps even when that information isn't stored in
 the database.

 In our REST APIs, you'll essentially see one of three time formats. I'm
 calling them 'isotime', 'strtime' and 'xmltime':

   - 'isotime' - this is the result from timeutils.isotime(). It
 includes timezone information (i.e. a 'Z' prefix) but not
 microseconds. You'll see this in places where we stringify the
 datetime objects in the API layer using isotime() before passing
 them to the JSON/XML serializers.

   - 'strtime' - this is the result from timeutils.strtime(). It doesn't
 include timezone information but does include decimal seconds. This
 is what jsonutils.dumps() uses when we're serializing API responses

   - 'xmltime' or 'str(datetime)' format - this is just what you get
 when you stringify a datetime using str(). If the datetime is tz
 aware or includes non-zero microseconds, then that information will
 be included in the result. This is a significant different versus
 the other two formats where it is clear whether tz and microsecond
 information is included in the string.

 but there are some caveats:

   - I don't know how significant it is these days, but timestamps will
 be serialized to strtime format when going over RPC, but won't be
 de-serialized on the remote end. This could lead to a situation
 where the API layer tries and stringify a strtime formatted string
 using timeutils.isotime(). (see below for a description of those
 formats)

   - In at least one place - e.g. the 'updated' timestamp for v2
 extensions - we hardcode the timestamp as strings in the code and
 don't currently use one of the formats above.


 My conclusions from all that:

   1) This sucks

   2) At the very least, we should be clear in our API samples tests
  which of the three formats we expect - we should only change the
  format used in a given part of the API after considering any
  compatibility considerations

   3) We should unify on a single

[openstack-dev] [Ceilometer] Question of necessary queries for Event implemented on HBase

2014-04-29 Thread Igor Degtiarov

Hi, everybody.

I’ve started to work on implementation of Event in ceilometer on HBase
backend in the edges of blueprint
https://blueprints.launchpad.net/ceilometer/+spec/hbase-events-feature

By now Events has been implemented only in SQL.

You know, using SQL  we can build any query we need.

With HBase it is another story. The data structure is built basing on
queries we need, so

to construct the structure of Event on HBase, it is very important to
answer the question what queries should be implemented to retrieve events
from storage.

I registered bp
https://blueprints.launchpad.net/ceilometer/+spec/hbase-events-structurefor
discussion Events structure in HBase.

For today it is prepared preliminary structure of Events in HBase:

table: Events

- rowkey:  event_id + reversed_timestamp



  - column: event_type = string with description of event

  - [list of columns: trait_id + trait_desc + trait_type=
trait_data]

Structure that is proposed will support next queries:

- event’s generation time

- event id

- event type

- trait: id, description, type

Any thoughts about additional queries that are necessary for Events.

I’ll publish the patch with current implementation soon.

Sincerely,
Igor Degtiarov
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposal: remove the server groups feature

2014-04-29 Thread Qiming Teng

On Mon, Apr 28, 2014 at 10:58:50AM -0600, Chris Friesen wrote:
 On 04/25/2014 03:15 PM, Jay Pipes wrote:
 
 There are myriad problems with the above user experience and
 implementation. Let me explain them.
 
 1. The user isn't creating a server group when they issue a nova
 server-group-create call. They are creating a policy and calling it a
 group. Cognitive dissonance results from this mismatch.
 
 I actually don't think this is true.  From my perspective they are
 actually creating a group, and then when booting servers they can be
 added into the group.
 
 The group happens to have a policy, it is not only a policy.

I tend to agree to this. Server groups today are just a starting point.
A server group can be used for different purposes like load-balancing, 
auto-scaling, high-availability or even a combination of them, just name
a few.  With that said, I would also like to see the policies separated 
from the group itself.  One or more policies can be associated with a
group (just like a 'floating-ip'), but the policies are managed
separately.
 2. There's no way to add an existing server to this group.
 
 In the original API there was a way to add existing servers to the
 group.  This didn't make it into the code that was submitted.  It is
 however supported by the instance group db API in nova.

To disallow putting an apple into a basket of oranges, we will need to
come up with some admission control/validation.  It is complicated, but
doable, IMO.

 3. There's no way to remove members from the group
 
 In the original API there was a way to remove members from the
 group. This didn't make it into the code that was submitted.
 

Just like 'adding new members', 'removing members' can be done if
certain conditions are met.  We can safely assume the users do
understand what they are doing.  I mean, we can leave the high level
policy decisions to users, with nova only providing dumb mechanisms.

 4. There's no way to manually add members to the server group
 
 Isn't this the same as item 2?
 
 5. The act of telling the scheduler to place instances near or away from
 some other instances has been hidden behind the server group API, which
 means that users doing a nova help boot will see a --group option that
 doesn't make much sense, as it doesn't describe the scheduling policy
 activity.

The confusion here is understandable, because we want to consider both
the policies and the mechanisms at the same time.  Maybe we can leave
the policies out of this discussion.

 
 There are many things hidden away that affect server
 booting...metadata matching between host aggregates and flavor extra
 specs, for instance.
 
 As I understand it, originally the concept of server groups was
 more broad.  They supported multiple policies, arbitrary group
 metadata, etc.  The scheduler policy was only one of the things that
 could be associated with a group.  This is why the underlying
 database structure is more complicated than necessary for the
 current set of supported operations.
 
 What we have currently is sort of a dumbed-down version but now
 that we have the basic support we can start adding in additional
 functionality as desired.
 
 Chris
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][QoS] Quick update

2014-04-29 Thread Collins, Sean

Just a couple quick notes, since I've been pinged off-list. The summit
proposal for the QoS API was rejected due to time constraints, but I'm
hoping that we can still meet in Atlanta and discuss the next steps.

In the meantime, I have created a draft spec in neutron-specs, but it's
mostly just a copy  paste of a Google doc, I will be updating it and
submitting it for review.

I've restored some of the patches for the QoS API, but they need to be
rebased and updated.

-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] nova-compute error

2014-04-29 Thread Ben Nemec

This is a development list, and your question sounds usage-related.  I 
suggest asking again on the users list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


Thanks.

-Ben

On 04/29/2014 12:53 AM, abhishek jain wrote:

Hi all

I'm getting follwoing error when trying to run nova-compute service..

  if ret is None: raise libvirtError ('virNodeListDevices() failed',
conn=self)
2014-04-29 00:51:47.153 28127 TRACE nova.openstack.common.threadgroup
libvirtError: this function is not supported by the connection driver:
virNodeNumOfDevices
2014-04-29 00:51:47.153 28127 TRACE nova.openstack.common.threadgroup

Please help regarding this.


Thanks
Abhishek Jain


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Location of Monitoring Checks

2014-04-29 Thread Ben Nemec


On 04/29/2014 03:16 AM, Macdonald-Wallace, Matthew wrote:

Hi all,

I have a patch in flight at the moment [0] to install check_mk server and 
compliment the already merged installation of check_mk agent [1] so my thoughts 
are now turning to how we would recommend adding new service checks.

The concept behind check_mk makes this really simple to do.  You just place a script that outputs status_code 
check_name performance_data message into the agent's local directory 
(/usr/lib/check_mk_agent/local on Ubuntu for example) and it will be picked up the next time an inventory of the system is 
run.

There are two ways that we can recommend doing this:

1) We ask users to update the check_mk_agent T-I-E every time they wish to add 
a new check
2) We ask users to distribute checks from their own T-I-E into the correct 
location

In my opinion, requiring an update to check_mk_agent for every new check is the wrong way 
of doing this as it means that all systems get all checks regardless of function.  Far 
more preferable would be option 2, however I'm open to other ideas, especially if they 
mean that organisations using this don't have to go through the review process if they 
have checks they wish to keep behind the firewall for IP/Licensing reasons.


Agreed.  Option 2 sounds like the only way to go here.  Adding 
instructions on how and where to add a check to the README file and 
maybe having a sample check element that users can look at for reference 
should be sufficient, I would think.




Thanks in advance for any help people can give on this,

Matt

[0] https://review.openstack.org/#/c/87226/
[1] https://review.openstack.org/#/c/81485/


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Ask for help reviewing nova-specs

2014-04-29 Thread Ben Nemec

Please don't send review requests to the list.  The preferred methods 
are discussed here: 
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015264.html


Thanks.

-Ben

On 04/29/2014 04:45 AM, sxmatch wrote:

Hi,guys:

There is a nova-specs add force detach volume to nova
（https://review.openstack.org/#/c/84048/）that need more review.
It has core review +1 by John. I wish it could be merged before May Day.

Thanks your help a lot!
app:ds:May%20Day


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains by name - policy and API issues?

In Keystone, users are assigned to a domain when they are created. This is a 
unique combination. 

-Original Message-
From: Robert Collins [mailto:robe...@robertcollins.net] 
Sent: Monday, April 28, 2014 11:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Heat] [Keystone] [TripleO] Making use of domains 
by name - policy and API issues?

On 29 April 2014 12:27, Dolph Mathews dolph.math...@gmail.com wrote:

 Sure: domain names are unambiguous but user mutable, whereas Heat's 
 approach to using admin tenant name is at risk to both mutability 
 and ambiguity (in a multi-domain deployment).

Isn't domainname/user unambiguous and unique? mutability is really not 
keystones choice.

If keystone won't accept domainname/user then that will force us to either do 
two stack-updates for a single deploy (ugly) or write patches to heat (and 
neutron where the callback-to-nova support has the same issue) to manually try 
a lookup and work around this.

Since its trivial to write such a thunk, what benefit is there to your users - 
e.g. TripleO/heat/nova not have it in keystone itself?

-Rob

--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-04-29 Thread Davanum Srinivas

How about 10:30 AM Break on Wednesday at the Developers Lounge (Do we
have one this time?)

-- dims

On Tue, Apr 29, 2014 at 10:32 AM, Thomas Goirand z...@debian.org wrote:
 On 04/29/2014 06:42 AM, Jeremy Stanley wrote:
 On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote:
 Just a friendly reminder to add yourself to this list if you are
 interested in participating in the key signing in Atlanta:

 https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit
 [...]

 It has a sign-up cutoff of two weeks ago, so I assume that was
 merely a placeholder. Which begs the question how late is too late
 for participants to be able to comfortably print out their copies
 (assuming we do http://keysigning.org/methods/sassaman-efficient
 this time)? Should lock down the page Wednesday May 7th? Sooner?

 Keep in mind that this week (April 27 through May 3) is supposed to
 be a vacation week for the project, so people may not be around to
 add themselves until Monday May 5th ;)

 Is there a date a place already schedule for the key signing party?

 Thomas


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: http://davanum.wordpress.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-04-29 Thread Clint Byrum

Break time is extremely busy in the developers lounge. We can have
others in the room, but we need enough of a space for everyone to stand
in two lines and rotate and be uninterrupted.

Excerpts from Davanum Srinivas's message of 2014-04-29 09:07:12 -0700:
 How about 10:30 AM Break on Wednesday at the Developers Lounge (Do we
 have one this time?)
 
 -- dims
 
 On Tue, Apr 29, 2014 at 10:32 AM, Thomas Goirand z...@debian.org wrote:
  On 04/29/2014 06:42 AM, Jeremy Stanley wrote:
  On 2014-04-26 17:05:41 -0700 (-0700), Clint Byrum wrote:
  Just a friendly reminder to add yourself to this list if you are
  interested in participating in the key signing in Atlanta:
 
  https://wiki.openstack.org/wiki/OpenPGP_Web_of_Trust/Juno_Summit
  [...]
 
  It has a sign-up cutoff of two weeks ago, so I assume that was
  merely a placeholder. Which begs the question how late is too late
  for participants to be able to comfortably print out their copies
  (assuming we do http://keysigning.org/methods/sassaman-efficient
  this time)? Should lock down the page Wednesday May 7th? Sooner?
 
  Keep in mind that this week (April 27 through May 3) is supposed to
  be a vacation week for the project, so people may not be around to
  add themselves until Monday May 5th ;)
 
  Is there a date a place already schedule for the key signing party?
 
  Thomas
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] no meeting this week (2 May)

Since this is the scheduled off week, I thought we would skip the team
meeting on Friday 2 May.

Doug

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] Question about the magic 100M when creating zero-size volume

2014-04-29 Thread Vishvananda Ishaya

This was added long ago to support testing environments without a lot of disk 
space.

Vish

On Apr 29, 2014, at 12:12 AM, Zhangleiqiang (Trump) zhangleiqi...@huawei.com 
wrote:

 Hi, all:
   
   I find in some of the cinder backend volume drivers, there are codes in 
 create_volume as follows:
   
   #cinder.volume.drivers.lvm
   def _sizestr(self, size_in_g):
if int(size_in_g) == 0:
   return '100m'
 
   Similar codes also exist in ibm.gpfs, san.hp.hp_lefthand_cliq_proxy, 
 san.solaris and huawei.ssh_common. I wonder why the 100M is used here, from 
 the git log I cannot find useful info.
 
   Thanks.
 
 
 --
 zhangleiqiang (Trump)
 
 Best Regards
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to use OVS in Nova networking without Neutron?

2014-04-29 Thread Edgar Magana Perdomo (eperdomo)

Using OVS with nova-nework will bring you more issues that what you are 
expected.
Security groups will not work and other L3 capabilities.

Edgar

From: laserjetyang laserjety...@gmail.commailto:laserjety...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, April 28, 2014 at 10:50 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] How to use OVS in Nova networking without Neutron?

I don't think it is supported in OpenStack community right now, however, I 
think nova-network with some modification may work that way, but the code may 
not have big chance to be in community.

On Tue, Apr 29, 2014 at 12:21 PM, ZhengLingyun 
konghuaru...@163.commailto:konghuaru...@163.com wrote:
 Hi list,

I want to use OVS instead of Linux bridge in Nova networking without Neutron.
How to do that?
I use OpenStack Icehouse which is deployed by DevStack on a single host.

Thanks.

Dustin Zheng

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno

Hi Zang

Thank you for your contribution on this!
The private key management is what I want to discuss in the summit.

[1] We are depending DB security, anyway
When we get stolen the private key in the DB, it means we are also
stolen ID/PW for DB.
If we stolen the key, even if we keep the private key secret, the
attacker can connect the NW for anywhere.

[2] How we manage a passcode for encrypting private key?
so even if openvpn supports encripted keys, when we input the passcode?
Vpn process will be launched automatically by neutron-server, so we
need to store it in the memory.
This is same security with plain private key.
For example, most of apache servers using plain private key, I guess.

so the security of ssl-vpn impl depends on db, rpc trasport, file
system security even if we encrypt the private key or not.
may be, we have better way, but I think current design isn't so bad to
prevent get merged.

Best
Nachi

















2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com:
 Hi all:

 Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and Rajesh[2]

 There are secure issues pointed by mark, that ssl private keys are
 stored plain in database and in config files of vpn-agents. As
 Barbican is incubated, we can store certs and their private keys in
 Barbican. But after checking openvpn configurations, I don't think
 there is any way to prevent storing private key in openvpn config
 files without modify the openvpn implementation.

 I have also made several changes, added a optional port field to
 sslvpn-connection table, integrated with service plugin framework
 (I'll follow service flavor framework when it is ready), and completed
 the neutronclient part. It is already developed in our testing
 environment, I'll upload my patch sooner or later.

 [1] https://review.openstack.org/#/c/58897/
 [2] https://review.openstack.org/#/c/70274/

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Kyle Mestery

On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com wrote:
 Hi Zang

 Thank you for your contribution on this!
 The private key management is what I want to discuss in the summit.

Has the idea of using Barbican been discussed before? There are many
reasons why using Barbican for this may be better than developing key
management ourselves.

Thanks,
Kyle

 [1] We are depending DB security, anyway
 When we get stolen the private key in the DB, it means we are also
 stolen ID/PW for DB.
 If we stolen the key, even if we keep the private key secret, the
 attacker can connect the NW for anywhere.

 [2] How we manage a passcode for encrypting private key?
 so even if openvpn supports encripted keys, when we input the passcode?
 Vpn process will be launched automatically by neutron-server, so we
 need to store it in the memory.
 This is same security with plain private key.
 For example, most of apache servers using plain private key, I guess.

 so the security of ssl-vpn impl depends on db, rpc trasport, file
 system security even if we encrypt the private key or not.
 may be, we have better way, but I think current design isn't so bad to
 prevent get merged.

 Best
 Nachi

















 2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com:
 Hi all:

 Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and 
 Rajesh[2]

 There are secure issues pointed by mark, that ssl private keys are
 stored plain in database and in config files of vpn-agents. As
 Barbican is incubated, we can store certs and their private keys in
 Barbican. But after checking openvpn configurations, I don't think
 there is any way to prevent storing private key in openvpn config
 files without modify the openvpn implementation.

 I have also made several changes, added a optional port field to
 sslvpn-connection table, integrated with service plugin framework
 (I'll follow service flavor framework when it is ready), and completed
 the neutronclient part. It is already developed in our testing
 environment, I'll upload my patch sooner or later.

 [1] https://review.openstack.org/#/c/58897/
 [2] https://review.openstack.org/#/c/70274/

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno

Hi Kyle

2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
 On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com wrote:
 Hi Zang

 Thank you for your contribution on this!
 The private key management is what I want to discuss in the summit.

 Has the idea of using Barbican been discussed before? There are many
 reasons why using Barbican for this may be better than developing key
 management ourselves.

No, however I'm +1 for using Barbican. Let's discuss this in
certificate management topic in advanced service session.

 Thanks,
 Kyle

 [1] We are depending DB security, anyway
 When we get stolen the private key in the DB, it means we are also
 stolen ID/PW for DB.
 If we stolen the key, even if we keep the private key secret, the
 attacker can connect the NW for anywhere.

 [2] How we manage a passcode for encrypting private key?
 so even if openvpn supports encripted keys, when we input the passcode?
 Vpn process will be launched automatically by neutron-server, so we
 need to store it in the memory.
 This is same security with plain private key.
 For example, most of apache servers using plain private key, I guess.

 so the security of ssl-vpn impl depends on db, rpc trasport, file
 system security even if we encrypt the private key or not.
 may be, we have better way, but I think current design isn't so bad to
 prevent get merged.

 Best
 Nachi

















 2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com:
 Hi all:

 Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and 
 Rajesh[2]

 There are secure issues pointed by mark, that ssl private keys are
 stored plain in database and in config files of vpn-agents. As
 Barbican is incubated, we can store certs and their private keys in
 Barbican. But after checking openvpn configurations, I don't think
 there is any way to prevent storing private key in openvpn config
 files without modify the openvpn implementation.

 I have also made several changes, added a optional port field to
 sslvpn-connection table, integrated with service plugin framework
 (I'll follow service flavor framework when it is ready), and completed
 the neutronclient part. It is already developed in our testing
 environment, I'll upload my patch sooner or later.

 [1] https://review.openstack.org/#/c/58897/
 [2] https://review.openstack.org/#/c/70274/

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Location of Monitoring Checks

2014-04-29 Thread Gregory Haynes

  Hi all,
 
  I have a patch in flight at the moment [0] to install check_mk server and 
  compliment the already merged installation of check_mk agent [1] so my 
  thoughts are now turning to how we would recommend adding new service 
  checks.
 
  The concept behind check_mk makes this really simple to do.  You just place 
  a script that outputs status_code check_name performance_data 
  message into the agent's local directory 
  (/usr/lib/check_mk_agent/local on Ubuntu for example) and it will be picked 
  up the next time an inventory of the system is run.
 
  There are two ways that we can recommend doing this:
 
  1) We ask users to update the check_mk_agent T-I-E every time they wish to 
  add a new check
  2) We ask users to distribute checks from their own T-I-E into the correct 
  location
 
  In my opinion, requiring an update to check_mk_agent for every new check is 
  the wrong way of doing this as it means that all systems get all checks 
  regardless of function.  Far more preferable would be option 2, however I'm 
  open to other ideas, especially if they mean that organisations using this 
  don't have to go through the review process if they have checks they wish 
  to keep behind the firewall for IP/Licensing reasons.
 
 Agreed.  Option 2 sounds like the only way to go here.  Adding 
 instructions on how and where to add a check to the README file and 
 maybe having a sample check element that users can look at for reference 
 should be sufficient, I would think.
 

++ This is a common pattern in many of the elements. Additionally, It
might be worth exporting a variable in check_mk's environment.d for
other elements to use as the agent local directory if this path isnt
entirely consistent across distros.

 
  Thanks in advance for any help people can give on this,
 
  Matt
 
  [0] https://review.openstack.org/#/c/87226/
  [1] https://review.openstack.org/#/c/81485/
 

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Kyle Mestery

On Tue, Apr 29, 2014 at 12:58 PM, Nachi Ueno na...@ntti3.com wrote:
 Hi Kyle

 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
 On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com wrote:
 Hi Zang

 Thank you for your contribution on this!
 The private key management is what I want to discuss in the summit.

 Has the idea of using Barbican been discussed before? There are many
 reasons why using Barbican for this may be better than developing key
 management ourselves.

 No, however I'm +1 for using Barbican. Let's discuss this in
 certificate management topic in advanced service session.

Agreed, this will be good to nail down in Atlanta in a few weeks.

 Thanks,
 Kyle

 [1] We are depending DB security, anyway
 When we get stolen the private key in the DB, it means we are also
 stolen ID/PW for DB.
 If we stolen the key, even if we keep the private key secret, the
 attacker can connect the NW for anywhere.

 [2] How we manage a passcode for encrypting private key?
 so even if openvpn supports encripted keys, when we input the passcode?
 Vpn process will be launched automatically by neutron-server, so we
 need to store it in the memory.
 This is same security with plain private key.
 For example, most of apache servers using plain private key, I guess.

 so the security of ssl-vpn impl depends on db, rpc trasport, file
 system security even if we encrypt the private key or not.
 may be, we have better way, but I think current design isn't so bad to
 prevent get merged.

 Best
 Nachi

















 2014-04-28 23:02 GMT-07:00 Zang MingJie zealot0...@gmail.com:
 Hi all:

 Currently I'm working on ssl vpn, based on patchsets by Nachi[1] and 
 Rajesh[2]

 There are secure issues pointed by mark, that ssl private keys are
 stored plain in database and in config files of vpn-agents. As
 Barbican is incubated, we can store certs and their private keys in
 Barbican. But after checking openvpn configurations, I don't think
 there is any way to prevent storing private key in openvpn config
 files without modify the openvpn implementation.

 I have also made several changes, added a optional port field to
 sslvpn-connection table, integrated with service plugin framework
 (I'll follow service flavor framework when it is ready), and completed
 the neutronclient part. It is already developed in our testing
 environment, I'll upload my patch sooner or later.

 [1] https://review.openstack.org/#/c/58897/
 [2] https://review.openstack.org/#/c/70274/

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] No Meeting this Week

2014-04-29 Thread Matthew Treinish


Hi Everyone,

Since this is the scheduled off week, I'm going to cancel this week's QA
meeting.

The next meeting will be on May 8th and will be at 22:00 UTC instead of having
two consecutive meetings at the same time. I will send out the usual reminder
email next week.


Thanks,

Matt Treinish

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-04-29 Thread Jeremy Stanley

On 2014-04-29 09:16:53 -0700 (-0700), Clint Byrum wrote:
[...]
 I think Wednesday would be the ideal day, as it has the most overlap
 with the conference and is at least adjacent to if not within most
 design tracks.
[...]

Seconded.

 I suggest we ensure that everyone understands the process and
 brings their print outs on the day-of.
[...]

I've updated the instructions on the sign-up list accordingly.

 I suggest we schedule the event for 5 minutes after the start of
 the break.

Agreed.

 As far as a location, if there are private meeting rooms of a large
 enough size that would be ideal.
[...]
 I don't know who to contact to schedule a meeting room. Anybody?

I'll check with the team handling venue logistics right now and
update this thread with options. I'm also inquiring about the
availability of a projector if we get one of the non-design-session
breakout rooms, and I can bring a digital micro/macroscope which
ought to do a fair job of showing everyone's photo IDs through it if
so (which would enable us to use The 'Sassman-Projected' Method and
significantly increase our throughput via parallelization).
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Use Case Question

2014-04-29 Thread Carlos Garza

   I mis quoted it should be in RFC 5246 not 5264.
On Apr 25, 2014, at 2:50 AM, Carlos Garza 
carlos.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote:

Trevor is referring to our plans on using the SSL session ID of the 
ClientHello to provide session persistence.
See RFC 5264 section 7.4.1.2 which sends an SSL session ID in the clear 
(Unencrypted) so that a load balancer with out the decrypting key can use it to 
make decisions on which
back end node to send the request to.  Users browsers while typically use the 
same session ID for a while between connections.

Also note this is supported in TLS 1.1 as well in the same section according to 
RFC 4346. And in TLS 1.0 RFC2246 as well.

So we have the ability to offer http cookie based persistence as you 
described only if we have the key but if not we can also offer SSL Session Id 
based persistence.



On Apr 24, 2014, at 7:53 PM, Stephen Balukoff 
sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote:

Hi Trevor,

If the use case here requires the same client (identified by session cookie) to 
go to the same back-end, the only way to do this with HTTPS is to decrypt on 
the load balancer. Re-encryption of the HTTP request may or may not happen on 
the back-end depending on the user's needs. Again, if the client can 
potentially change IP addresses, and the session still needs to go to the same 
back-end, the only way the load balancer is going to know this is by decrypting 
the HTTPS request. I know of no other way to make this work.

Stephen


On Thu, Apr 24, 2014 at 9:25 AM, Trevor Vardeman 
trevor.varde...@rackspace.commailto:trevor.varde...@rackspace.com wrote:
Hey,

I'm looking through the use-cases doc for review, and I'm confused about one of 
them.  I'm familiar with HTTP cookie based session persistence, but to satisfy 
secure-traffic for this case would there be decryption of content, injection of 
the cookie, and then re-encryption?  Is there another session persistence type 
that solves this issue already?  I'm copying the doc link and the use case 
specifically; not sure if the document order would change so I thought it would 
be easiest to include both :)

Use Cases:  
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis

Specific Use Case:  A project-user wants to make his secured web based 
application (HTTPS) highly available. He has n VMs deployed on the same private 
subnet/network. Each VM is installed with a web server (ex: apache) and 
content. The application requires that a transaction which has started on a 
specific VM will continue to run against the same VM. The application is also 
available to end-users via smart phones, a case in which the end user IP might 
change. The project-user wishes to represent them to the application users as a 
web application available via a single IP.

-Trevor Vardeman

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PGP keysigning party for Juno summit in Atlanta?

2014-04-29 Thread Jeremy Stanley

On 2014-04-29 08:52:38 +0400 (+0400), Sergey Lukjanov wrote:
 +1 to lock May 7

I've updated the wiki article to note that I'll lock it for further
edits at the end of the (UTC) day on the 7th and generate the
checksummed list from it, then link it there for everyone to
download as quickly as I can do so. I'll also send a signed copy of
the checksummed list in reply to this thread at the same time.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][L3] Agent manager customization

2014-04-29 Thread Bob Melander (bmelande)

Hi Zzelle, Carl and others,

We’ve been doing work on a more modular agent whose responsibilities are 
basically to:
1: apply configurations in devices when Neutron service resources (like Neutron 
Routers) are created or updated.
2: monitor the health of devices hosting such service resources

Our starting point was the l3 agent which we’ve then evolved to become a 
configuration agent.
It can perform configurations in remote devices so it does not have to run 
locally on the device it configures
(this helps to reduce agent reporting traffic and thus the load on the Neutron 
service)
It makes use of device drivers that knows how to instantiate/manipulate service 
resources in devices of the type that the driver handles.
It also introduces what we call service helpers. Such a helper (a python class) 
essentially describes the workflow that should be used to create/update Neutron 
resources of a certain type.
At the moment we have a single service helper for Neutron routing service but 
our thinking is to take this one step further and allow for different service 
helpers for each service.
That would allow for pretty much completely different workflows to be used if a 
Neutron router is implemented in say a device of type A, vs if it is 
implemented in device of type B.

Perhaps something like the config agent could help handling some of the 
complexities you bring up. In case your interested you can have a look at the 
BP for the config agent. The link for blueprint spec is:
https://review.openstack.org/#/c/90729/

We hope to at least briefly be able to bring up the configuration agent in the 
design summit session on the service vm framework (on Friday, shared session 
with Isaku Yamahata) as that is the context in which we started this work.

Thanks,
Bob

From: ZZelle zze...@gmail.commailto:zze...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: torsdag 24 april 2014 00:34
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][L3] Agent manager customization

Hi Carl,


 A clear l3 agent manager interface with hookable methods would clearly 
simplify the understanding, the dev/support.


Difficulties:
1. (un)deployment method names are associated to the triggering event not to 
performed action:
 - router deployment is done by _router_added
 - router gateway deployment/config is  done by  external_gateway_added
 - more generally (un)deployments are done by the associated *_added and 
*_removed methods
It implies to fully understand the behaviour of the L3 agent manager in order 
to check that (un)deployment actions are done and only done by the associated 
triggering event methods.
2. Because docstrings are missing, i needed to double check previous check.

3. Customization testing is not really easy, because inherited manager 
implementation could change.
So i preferred to perform only black box tests to reduce coupling between 
implementation and tests.

4. Support: extending a class without a contract/interface implies to perform 
some adaptations/checks (not so much in practice) simplified by previous tests
But that's the topic !

5. It's not possible currently to change l3 agent manager through configuration
 - so i must develop my own neutron-l3-agent binary implementation in order 
to allow providing a custom manager to main()
 - i must verify my binary was not erased during updates


Awkward:
6. (un)deployment methods get the router RouterInfo using different strategies:
 - _router_added builds it and stores it in self.router_info cache
 - _router_removed get it from self.router_info cache
 - external_gateway/internal_network_added/removed get it through arguments

7._router_added and _process_routers have strange behaviours:
 - _process_routers calls _router_added will verifying to build router 
RouterInfo object
 - _router_added computes the router RouterInfo object and store it in 
self.router_info
 - _process_routers get it back from self.router_info
IMHO, it seems more logical to let
 - _process_routers builds and stores router RouterInfo object and
 - _process_routers pass the object as an argument to _router_added
The same might apply to _router_removed and _process_routers ?


I must share with pcm about L3 Vendor plugins BPs to verify my understanding 
and possible synergies.
But a priori [1] BP seems to be the only synergy candidate.


Cedric


[1] https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation

On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin 
c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote:
Cedric,

I'm just getting back from a short vacation.  Please excuse the delayed reply.

I have a feeling that this subject may have been discussed in the past
before I was very active in Neutron.  So, others may chime in if I'm
missing

Re: [openstack-dev] [nova][neutron] VIF event callbacks implementation

2014-04-29 Thread Dan Smith

 Aside from creating a sort of cyclic dependency between the two, it 
 is my understanding that Neutron is meant to be a stand alone 
 service capable of being consumed by other compute managers (i.e. 
 oVirt). This breaks that paradigm.

snip

 So my question is: Why use API and not RPC?
 
 I saw that there is already a notification system in Neutron that 
 notifies on each port update (among other things) which are
 currently consumed by Ceilometer. Why not have Nova use those
 notifications to decide that a VIF got plugged correctly, floating
 IPs changed, and so on?

To your point above, having either service sit on the other's RPC bus
ties them together far closer than having them consume each other's REST
API, IMHO. Further, Nova's internal RPC mechanics are controlled pretty
tightly for upgrade compatibility and I don't think I'd want another
service sitting on that bus that we have to worry about when we're
coordinating a change across releases (which we do quite often). We
consume Neutron's services via the REST API because that's what is
exposed externally and guaranteed to be stable -- the same goes for
Neutron consuming anything from Nova.

 I believe the rationale here was that nova's API interface is only 
 currently exposed via a rest API over http so leveraging this 
 existing framework seemed like a good place to do it. In addition, 
 there didn't seem to be an obvious advantage to using RPC rather
 than the rest interface. Lastly, this new interface that nova exposes
 is generic and not neutron specific as it can be used for other type
 of notifications that things want to send nova. I added Dan Smith to
 CC to keep me honest here as I believe this was the rationale.

Yeah, we've already got plans in place to get Cinder to use the
interface to provide us more detailed information and eliminate some
polling. We also have a very purpose-built notification scheme between
nova and cinder that facilitates a callback for a very specific
scenario. I'd like to get that converted to use this mechanism as well,
so that it becomes the way you tell nova that things it's waiting for
have happened.

--Dan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] cinder not support query volume/snapshot with regular expression

2014-04-29 Thread Jay Pipes


On 04/29/2014 02:16 AM, Zhangleiqiang (Trump) wrote:

Currently, Nova API achieve this feature based on the database’s REGEX
support. Do you have advice on alternative way to achieve it?


Hi Trump,

Unfortunately, REGEXP support in databases is almost always ridiculously 
slow compared to prefix searches (WHERE col LIKE 'foo%').


Lately, I've been considering that a true tagging system for Nova would 
allow for better-performing and more user-friendly search/winnow 
functions in the Nova API. I'll post a blueprint specification for this 
and hopefully have some time to implement in Juno...


Best,
-jay


zhangleiqiang (Trump)

Best Regards

*From:*laserjetyang [mailto:laserjety...@gmail.com]
*Sent:* Tuesday, April 29, 2014 1:49 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [Cinder] cinder not support query
volume/snapshot with regular expression

It looks to me the Nova API will be dangerous source of DoS attacks due
to the regexp?

On Mon, Apr 28, 2014 at 7:04 PM, Duncan Thomas duncan.tho...@gmail.com
mailto:duncan.tho...@gmail.com wrote:

Regex matching in APIs can be a dangerous source of DoS attacks - see
http://en.wikipedia.org/wiki/ReDoS. Unless this is mitigated sensibly,
I will continue to resist any cinder patch that adds them.

Glob matches might be safer?


On 26 April 2014 05:02, Zhangleiqiang (Trump) zhangleiqi...@huawei.com
mailto:zhangleiqi...@huawei.com wrote:

Hi, all:

I see Nova allows search instances by name, ip and ip6 fields which can 
be normal string and regular expression:

[stack@leiqzhang-stack cinder]$ nova help list

List active servers.

Optional arguments:
--ip ip-regexp  Search with regular expression match by 
IP address
(Admin only).
--ip6 ip6-regexpSearch with regular expression match by 
IPv6 address
 (Admin only).
--name name-regexp  Search with regular expression match by 
name
--instance-name name-regexp Search with regular expression 
match by server name
(Admin only).

I think it is also needed for Cinder when query the 
volume/snapshot/backup by name. Any advice?

--
zhangleiqiang (Trump)

Best Regards


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Duncan Thomas


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] cinder not support query volume/snapshot with regular expression

2014-04-29 Thread Steven Kaufer

Jay Pipes jaypi...@gmail.com wrote on 04/29/2014 02:26:42 PM:

 From: Jay Pipes jaypi...@gmail.com
 To: openstack-dev@lists.openstack.org,
 Date: 04/29/2014 02:27 PM
 Subject: Re: [openstack-dev] [Cinder] cinder not support query
 volume/snapshot with regular expression

 On 04/29/2014 02:16 AM, Zhangleiqiang (Trump) wrote:
  Currently, Nova API achieve this feature based on the database’s REGEX
  support. Do you have advice on alternative way to achieve it?

 Hi Trump,

 Unfortunately, REGEXP support in databases is almost always ridiculously
 slow compared to prefix searches (WHERE col LIKE 'foo%').

 Lately, I've been considering that a true tagging system for Nova would
 allow for better-performing and more user-friendly search/winnow
 functions in the Nova API. I'll post a blueprint specification for this
 and hopefully have some time to implement in Juno...

Jay,

I am interested in this design, please add me as a reviewer when the
blueprint is created.

Thanks!

Steven Kaufer

 Best,
 -jay

  zhangleiqiang (Trump)

  Best Regards

  *From:*laserjetyang [mailto:laserjety...@gmail.com]
  *Sent:* Tuesday, April 29, 2014 1:49 PM
  *To:* OpenStack Development Mailing List (not for usage questions)
  *Subject:* Re: [openstack-dev] [Cinder] cinder not support query
  volume/snapshot with regular expression

  It looks to me the Nova API will be dangerous source of DoS attacks due
  to the regexp?

  On Mon, Apr 28, 2014 at 7:04 PM, Duncan Thomas duncan.tho...@gmail.com
  mailto:duncan.tho...@gmail.com wrote:

  Regex matching in APIs can be a dangerous source of DoS attacks - see
  http://en.wikipedia.org/wiki/ReDoS. Unless this is mitigated sensibly,
  I will continue to resist any cinder patch that adds them.

  Glob matches might be safer?

  On 26 April 2014 05:02, Zhangleiqiang (Trump) zhangleiqi...@huawei.com
  mailto:zhangleiqi...@huawei.com wrote:
  Hi, all:

  I see Nova allows search instances by name, ip and ip6
 fields which can be normal string and regular expression:

  [stack@leiqzhang-stack cinder]$ nova help list

  List active servers.

  Optional arguments:
  --ip ip-regexp  Search with regular
 expression match by IP address
  (Admin only).
  --ip6 ip6-regexpSearch with regular
 expression match by IPv6 address
   (Admin only).
  --name name-regexp  Search with regular
 expression match by name
  --instance-name name-regexp Search with regular
 expression match by server name
  (Admin only).

  I think it is also needed for Cinder when query the
 volume/snapshot/backup by name. Any advice?

  --
  zhangleiqiang (Trump)

  Best Regards

  ___
  OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  --
  Duncan Thomas

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder][Nova][Keystone][docs] Version responses links

2014-04-29 Thread Diane Fleming

I would prefer to link to docs.openstack.org or the API reference pages
with specific links like this:
http://api.openstack.org/api-ref-blockstorage-v2.html,
http://api.openstack.org/api-ref-compute-v2.html, and so on.
The
 issue I have with linking to the specs is that they are likely going
to move back into the project repos, and some projects don't even have a
 spec to link to. All projects have a page on api.openstack.org,
however. 
You could also link to api.openstack.org/api-ref.html, which is the main
page



Diane
--
Diane Fleming
Software Developer II - US

diane.flem...@rackspace.com
Cell  512.323.6799
Office 512.874.1260
Skype drfleming0227
Google-plus diane.flem...@gmail.com






On 4/27/14 10:12 PM, Mike Perez thin...@gmail.com wrote:

On 19:19 Sun 27 Apr , Andreas Jaeger wrote:
 So, my proposal would be:
 * Remove WADL links
 * Have PDF links to go http://docs.openstack.org
 * For those current links to the site http://docs.openstack.org: Take
   care that they point either to a current file or get redirected to
   http://docs.openstack.org/index.html

Andreas,

Thanks for starting this. As I mentioned, I started this with Cinder [1],
but
I was linking directly to the API spec version with the corresponding
version.
I'm curious on what others think the approach should be here.

[1] - https://review.openstack.org/#/c/73856/

-- 
Mike Perez

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] preparing oslo.i18n for graduation

I have exported the gettextutils code and related files to a new git
repository, ready to be imported as oslo.i18n. Please take a few
minutes to look over the files and give it a sanity check.

https://github.com/dhellmann/oslo.i18n

Thanks,
Doug

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [marconi] performance

2014-04-29 Thread Janczuk, Tomasz

Hi Flavio,

Thanks! I also added some comments to the performance test plan at
https://etherpad.openstack.org/p/marconi-benchmark-plans we talked about
yesterday. 

Thanks,
Tomasz

On 4/29/14, 2:52 AM, Flavio Percoco fla...@redhat.com wrote:

On 28/04/14 17:41 +, Janczuk, Tomasz wrote:
Hello,

Have any performance numbers been published for Marconi? I have asked
this question before
(http://lists.openstack.org/pipermail/openstack-dev/2014-March/031004.htm
l) but there were none at that time.



Hi Tomasz,

Some folks in the team are dedicated to working on this and producing
results asap. The details and results will be shared as soon as
possible.

Thanks a lot for your interest, I'll make sure you're in the loop as
soon as we have them.

-- 
@flaper87
Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][Nova][Designate][L3][IPv6] Discussion about Cross-Project Integration of DNS at Summit

2014-04-29 Thread Carl Baldwin

The design summit discussion topic I submitted [1] for my DNS
blueprints [2][3][4] and this one [5] just missed the cut for the
design session schedule.  It stung a little to be turned down but I
totally understand the time and resource constraints that drove the
decision.

I feel this is an important subject to discuss because the end result
will be a better cloud user experience overall.  The design summit
could be a great time to bring together interested parties from
Neutron, Nova, and Designate to discuss the integration that I propose
in these blueprints.

DNS for IPv6 in Neutron is also something I would like to discuss.
Mostly, I'd like to get a good sense for where this is at currently
with the current Neutron dns implementation (dnsmasq) and how it will
fit in.

I've created an etherpad to help us coordinate [6].  If you are
interested, please go there and help me flesh it out.

Carl Baldwin
Neutron L3 Subteam

[1] http://summit.openstack.org/cfp/details/403
[2] https://blueprints.launchpad.net/neutron/+spec/internal-dns-resolution
[3] https://blueprints.launchpad.net/nova/+spec/internal-dns-resolution
[4] https://blueprints.launchpad.net/neutron/+spec/external-dns-resolution
[5] https://blueprints.launchpad.net/neutron/+spec/dns-subsystem
[6] https://etherpad.openstack.org/p/juno-dns-neutron-nova-designate

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [sahara] cancel next team meeting May 1

Ok, so, the May 1 meeting is canceled.

On Fri, Apr 25, 2014 at 5:12 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
 We'll have one more meeting before the summit - May 8 :)

 On Fri, Apr 25, 2014 at 5:09 PM, Matthew Farrellee m...@redhat.com wrote:
 On 04/25/2014 07:23 AM, Sergey Lukjanov wrote:

 Hey folks,

 May 1 is a non-working day in Russia and I'm starting traveling next
 day, so, I'll not be able to chair it.

 So, I'm proposing to cancel this meeting.

 Any thoughts/objections?


 if folks have topics they'd like to cover, use the mailing list

 see you all at summit!

 best,


 matt


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Mirantis Inc.



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Mirantis Inc.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Issues when running unit tests in OpenStack

2014-04-29 Thread John Dennis

You may want to take a peek at this recent thread, there may be
information in it you'll find useful.

http://lists.openstack.org/pipermail/openstack-dev/2014-March/029408.html

-- 
John

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am
not sure if there is a request with code newer than this link - please do
let me know if that is the case.

Thanks,
Regards,
Vijay

On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German
german.eichber...@hp.com wrote:

Sam,

The use cases where pretty complete the last time I checked so let's move
them to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for
the summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I
agree that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at -
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under -
http://git.openstack.org/cgit/openstack/neutron-specs, I have already
files a blue print
https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can
complete the .rst process by tomorrow.

Regards,
-Sam.

-Original Message-
From: Kyle Mestery [mailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this
cycle. As I've told a few people, seeing all the interest from operators
and providers is fantastic, as it gives us valuable input from that side of
things before we embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching
up on the LBaaS documents and emails. There is a lot of great work and
passion by many people. However, the downside of what I've seen is that
there is a logjam around progress here. Given we're two weeks out from the
Summit, I'm going to start running the LBaaS meetings with Eugene to try
and help provide some focus there.
Hopefully we can use this week and next week's meetings to drive to a
consistent Summit agenda and lay the groundwork for LBaaS in Juno and
beyond.

Also, while our new neutron-specs BP repository has been great so far for
developers, based on feedback from operators, it may not be ideal for those
who are not used to contributing using gerrit. I don't want to lose the
voice of those people, so I'm pondering what to do. This is really
affecting the LBaaS discussion at the moment. I'm thinking that we should
ideally try to use Google Docs for these initial discussions and then move
the result of that into a BP on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for
people to collaborate on. I don't want to put Stephen on the spot, but his
document may be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle

On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov enikano...@mirantis.com
wrote:
Hi,

You knew from the action items that came out of the IRC meeting of
April
17 that my team would be working on an API revision proposal. You
also knew that this proposal was to be accompanied by an object model
diagram and glossary, in order to clear up confusion. You were in
that meeting, you saw the action items being created. Heck, you even
added the to prepare API for SSL and L7 directive for my team
yourself!

The implied but not stated assumption about this work was that it
would be fairly evaluated once done, and that we would be given a short
window (ie.
about a week) in which to fully prepare and state our proposal.

Your actions, though, were apparently to produce your own version of
the same in blueprint form without notifying anyone in the group that
you were going to be doing this, let alone my team. How could you
have given my API proposal a fair shake prior to publishing your
blueprint, if both came out on the same day? (In fact, I'm lead to
believe that you and other Neutron LBaaS developers hadn't even
looked at my proposal before the meeting on 4/24, where y'all started
determining product direction, apparently by
edict.)

Therefore, looking honestly at your actions on this and trying to
give you the benefit of the doubt, I still must assume that you never
intended to seriously consider our proposal.

That's strange to hear because the spec on review is a part of what is
proposed in the document made by you and your team.
Once

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Also, a section for the API specification for the newly created SSL
extensions needs to be added to
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Regards,
Vijay

On Tue, Apr 29, 2014 at 1:55 PM, Vijay B os.v...@gmail.com wrote:

Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I
am not sure if there is a request with code newer than this link - please
do let me know if that is the case.

Thanks,
Regards,
Vijay

On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German
german.eichber...@hp.com wrote:

Sam,

The use cases where pretty complete the last time I checked so let's move
them to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for
the summit.

German

Hi,

Regards,
-Sam.

Folks, sorry for the top post here, but I wanted to make sure to gather
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this
cycle. As I've told a few people, seeing all the interest from operators
and providers is fantastic, as it gives us valuable input from that side of
things before we embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been
catching up on the LBaaS documents and emails. There is a lot of great work
and passion by many people. However, the downside of what I've seen is that
there is a logjam around progress here. Given we're two weeks out from the
Summit, I'm going to start running the LBaaS meetings with Eugene to try
and help provide some focus there.
Hopefully we can use this week and next week's meetings to drive to a
consistent Summit agenda and lay the groundwork for LBaaS in Juno and
beyond.

If we go down this path, we need to decide on a single Google Doc for
people to collaborate on. I don't want to put Stephen on the spot, but his
document may be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle

On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov
enikano...@mirantis.com wrote:
Hi,

The implied but not stated assumption about this work was that it
would be fairly evaluated once done, and that we would be given a
short window (ie.
about a week) in which to fully prepare and state our proposal.

Therefore, looking honestly at your actions on this and trying to
give you

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Eichberger, German

Stephen + Sam,

I have added some of the operator use cases. We also created a document earlier 
(https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWc#gid=0)
 listing all the features we consider essential (and everybody voted with real 
world data) for the LB users. I have added them to the document though not 
turned them into nice user stories. I also added a link.

German

From: Stephen Balukoff [mailto:sbaluk...@bluebox.net]
Sent: Monday, April 28, 2014 4:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi guys,

Sorry for all the drama on the list lately.

Kyle: I appreciate the sentiment. I'd also be happy to open up my API doc for 
general editing by people on the internet (and not just comments) if you think 
that would help.

For us new-comers to the OpenStack project environment, what do people usually 
use for discussing potential design changes (and especially large design 
changes)?  (From my perspective, Blue prints seem mostly useful as collections 
of links to other documents, without having an obvious way to discuss things in 
the blueprint directly. Gerrit seems like it's mostly github workflow with CI 
baked in-- ie. useful for specific smaller code changes, but not as much for 
design-level discussions. I suppose etherpads might duplicate much of the 
functionality we're currently using google docs to accomplish (though I don't 
think etherpads have the ability to do spreadsheets, from what I can tell).

As far as the meetings go: It might help if you could share with us what you 
hope to accomplish prior to the summit, and what kinds of things you'd like us 
to be prepared to discuss at the summit. (Is there an LBaaS meeting of some 
kind scheduled there yet?)

For my part, I plan on concentrating on filling out more use cases and then 
returning to the software load balancer virtual appliance porting project 
that's been on the back-burner for way too long for me.

Samuel and German: I've gone ahead and added around 20 new use cases to the 
google doc you linked. More will be on the way, but I'm happy to add these to 
gerrit myself if you'd prefer, so long as I can see how you're doing this for 
the first use cases and can follow your template. Let me know if you'd like me 
to change what I've been doing here, eh! Note also that so far these are only 
user use cases; It doesn't look like admin/operator use cases have been 
filled out at all yet.

Thanks,
Stephen



On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.commailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery 
[mailto:mest...@noironetworks.commailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also,

Re: [openstack-dev] [tripleo] Location of Monitoring Checks

2014-04-29 Thread Robert Collins

Or have a check-mk.d directory and pull stuff on from there automatically
On 30 Apr 2014 04:03, Gregory Haynes g...@greghaynes.net wrote:

   Hi all,
  
   I have a patch in flight at the moment [0] to install check_mk server
 and compliment the already merged installation of check_mk agent [1] so my
 thoughts are now turning to how we would recommend adding new service
 checks.
  
   The concept behind check_mk makes this really simple to do.  You just
 place a script that outputs status_code check_name performance_data
 message into the agent's local directory
 (/usr/lib/check_mk_agent/local on Ubuntu for example) and it will be picked
 up the next time an inventory of the system is run.
  
   There are two ways that we can recommend doing this:
  
   1) We ask users to update the check_mk_agent T-I-E every time they
 wish to add a new check
   2) We ask users to distribute checks from their own T-I-E into the
 correct location
  
   In my opinion, requiring an update to check_mk_agent for every new
 check is the wrong way of doing this as it means that all systems get all
 checks regardless of function.  Far more preferable would be option 2,
 however I'm open to other ideas, especially if they mean that organisations
 using this don't have to go through the review process if they have checks
 they wish to keep behind the firewall for IP/Licensing reasons.
 
  Agreed.  Option 2 sounds like the only way to go here.  Adding
  instructions on how and where to add a check to the README file and
  maybe having a sample check element that users can look at for reference
  should be sufficient, I would think.
 

 ++ This is a common pattern in many of the elements. Additionally, It
 might be worth exporting a variable in check_mk's environment.d for
 other elements to use as the agent local directory if this path isnt
 entirely consistent across distros.

  
   Thanks in advance for any help people can give on this,
  
   Matt
  
   [0] https://review.openstack.org/#/c/87226/
   [1] https://review.openstack.org/#/c/81485/
  

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Eichberger, German

Vijay,

SSL and certificate management is a major requirement from a cloud operator 
perspective. The VPN part of Neutron is looking into using Barbican and I am 
surprised that LB is going a different way/implementing their own store. Just 
for the record I prefer Barbican ☺

Furthermore, we are still discussing the API and have several proposals so I am 
not sure how the SSL API/implementation you are proposing fits into that.

German

From: Vijay B [mailto:os.v...@gmail.com]
Sent: Tuesday, April 29, 2014 2:30 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Also, a section for the API specification for the newly created SSL extensions 
needs to be added to https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.

Regards,
Vijay

On Tue, Apr 29, 2014 at 1:55 PM, Vijay B 
os.v...@gmail.commailto:os.v...@gmail.com wrote:
Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not 
sure if there is a request with code newer than this link - please do let me 
know if that is the case.

Thanks,
Regards,
Vijay

On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.commailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery 
[mailto:mest...@noironetworks.commailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of
 April
 17 that my team would be working on an API revision proposal. You
 also knew that this proposal was to be accompanied by an object model
 diagram and glossary, in order to clear up confusion. You were in
 that meeting, you saw the action items being created. Heck, you even
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it
 would be fairly evaluated

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Stephen Balukoff

Per Samuel's request, I have set my API proposal document to be edit-able
by all.

Also, my work priorities have changed somewhat in preparation for the
summit in two weeks, so I may not be able to add more use cases prior to
the summit.


On Tue, Apr 29, 2014 at 3:55 AM, Samuel Bercovici samu...@radware.comwrote:

 Hi,

 I think it is a good idea to have the use cases in a different document
 that API proposals (Stephen's, included)
 Once we declare the uses cases done for Juno, I will move it to the BP
 repository.
 I would also like to see operator's use cases flushed out in the document.

 Stephen, could you please open the document also for editing?

 Regards,
 -Sam.




 -Original Message-
 From: Kyle Mestery [mailto:mest...@noironetworks.com]
 Sent: Tuesday, April 29, 2014 5:27 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

 On Mon, Apr 28, 2014 at 6:23 PM, Stephen Balukoff sbaluk...@bluebox.net
 wrote:
  Hi guys,
 
  Sorry for all the drama on the list lately.
 
 Not a problem. Like I said, the passion from all sides is great, and I'm
 especially happy to see all the operators engaging with Neutron for LBaaS.

  Kyle: I appreciate the sentiment. I'd also be happy to open up my API
  doc for general editing by people on the internet (and not just
  comments) if you think that would help.
 
 My main reason for asking this was in case the gerrit bar was too high for
 new people to Neutron and LBaaS in particular. I want to make sure we
 capture everyone's ideas and allow everyone a chance to comment.
 The gerrit BP process does this nicely, but I just want to ensure it's not
 too high of a bar for people new to the entire process.

  For us new-comers to the OpenStack project environment, what do people
  usually use for discussing potential design changes (and especially
  large design changes)?  (From my perspective, Blue prints seem mostly
  useful as collections of links to other documents, without having an
  obvious way to discuss things in the blueprint directly. Gerrit seems
  like it's mostly github workflow with CI baked in-- ie. useful for
  specific smaller code changes, but not as much for design-level
  discussions. I suppose etherpads might duplicate much of the
  functionality we're currently using google docs to accomplish (though
  I don't think etherpads have the ability to do spreadsheets, from what I
 can tell).
 
 I think it's fine to use the gdoc for now, with the idea being we will
 then converge on work items formed into multiple BPs out of the gdoc.
 So perhaps it does make sense to use your document as the communal
 starting point for this. But I'm open to what others may say as well.

  As far as the meetings go: It might help if you could share with us
  what you hope to accomplish prior to the summit, and what kinds of
  things you'd like us to be prepared to discuss at the summit. (Is
  there an LBaaS meeting of some kind scheduled there yet?)
 
 I've given LBaaS 2 40 minute sessions. What I'd like us to do is come to
 come to a consensus on what needs discussing in person vs. what everyone is
 agreeing on and we don't need to discuss in those sessions. If we need time
 to discuss the object model and API in Atlanta, that's fine too.

  For my part, I plan on concentrating on filling out more use cases and
  then returning to the software load balancer virtual appliance porting
  project that's been on the back-burner for way too long for me.
 
 Perfect! How about if we try to close the use case gap for this week's
 LBaaS meeting. Then, next week we can at least make a stab at the object
 model and API which satisfies as many use cases as we come up with.

  Samuel and German: I've gone ahead and added around 20 new use cases
  to the google doc you linked. More will be on the way, but I'm happy
  to add these to gerrit myself if you'd prefer, so long as I can see
  how you're doing this for the first use cases and can follow your
  template. Let me know if you'd like me to change what I've been doing
  here, eh! Note also that so far these are only user use cases; It
  doesn't look like admin/operator use cases have been filled out at all
 yet.
 
 Getting the admin/operator use cases in there would be good as well
 Stephen.

 Thanks,
 Kyle

  Thanks,
  Stephen
 
 
 
 
  On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German
  german.eichber...@hp.com wrote:
 
  Sam,
 
  The use cases where pretty complete the last time I checked so let's
  move them to gerrit so we can all vote.
 
  Echoing Kyle I would love to see us focusing on getting things ready
  for the summit.
 
  German
 
  -Original Message-
  From: Samuel Bercovici [mailto:samu...@radware.com]
  Sent: Monday, April 28, 2014 11:44 AM
  To: OpenStack Development Mailing List (not for usage questions)
  Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API
  proposal
 
  Hi,
 
  I

Re: [openstack-dev] [solum] [heat] Environments Working Group

2014-04-29 Thread Roshan Agrawal

Per decision in the the Solum weekly IRC meeting today, we will have the 
environment working group discussion via ML/etherpad. 

GOAL: develop a POV on
1. Which OpenStack program/projects should Environments live under
2. What projects does Environments depend on (Heat, Keystone, OpenStack 
congress, etc.)
3. What discussions do we need to drive in the OpenStack Atlanta summit to get 
Environments added to relevant project roadmaps

Etherpad for discussion: https://etherpad.openstack.org/p/Environments . Do 
jump in and share your input on etherpad and ML

We will still go ahead and have a placeholder meeting for Wed May 7th 9 am US 
Central time, just in case we need it.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Clint Byrum

Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
 Hi Kyle
 
 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
  On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com wrote:
  Hi Zang
 
  Thank you for your contribution on this!
  The private key management is what I want to discuss in the summit.
 
  Has the idea of using Barbican been discussed before? There are many
  reasons why using Barbican for this may be better than developing key
  management ourselves.
 
 No, however I'm +1 for using Barbican. Let's discuss this in
 certificate management topic in advanced service session.
 

Just a suggestion: Don't defer that until the summit. Sounds like you've
already got some consensus, so you don't need the summit just to rubber
stamp it. I suggest discussing as much as you can right now on the mailing
list, and using the time at the summit to resolve any complicated issues
including any a or b things that need crowd-sourced idea making. You
can also use the summit time to communicate your requirements to the
Barbican developers.

Point is: just because you'll have face time, doesn't mean you should
use it for what can be done via the mailing list.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] SSL VPN Implemenatation

2014-04-29 Thread Nachi Ueno

Hi Clint

Thank you for your suggestion. Your point get taken :)

 Kyle
This is also a same discussion for LBaaS
Can we discuss this in advanced service meeting?

 Zang
Could you join the discussion?



2014-04-29 15:48 GMT-07:00 Clint Byrum cl...@fewbar.com:
 Excerpts from Nachi Ueno's message of 2014-04-29 10:58:53 -0700:
 Hi Kyle

 2014-04-29 10:52 GMT-07:00 Kyle Mestery mest...@noironetworks.com:
  On Tue, Apr 29, 2014 at 12:42 PM, Nachi Ueno na...@ntti3.com wrote:
  Hi Zang
 
  Thank you for your contribution on this!
  The private key management is what I want to discuss in the summit.
 
  Has the idea of using Barbican been discussed before? There are many
  reasons why using Barbican for this may be better than developing key
  management ourselves.

 No, however I'm +1 for using Barbican. Let's discuss this in
 certificate management topic in advanced service session.


 Just a suggestion: Don't defer that until the summit. Sounds like you've
 already got some consensus, so you don't need the summit just to rubber
 stamp it. I suggest discussing as much as you can right now on the mailing
 list, and using the time at the summit to resolve any complicated issues
 including any a or b things that need crowd-sourced idea making. You
 can also use the summit time to communicate your requirements to the
 Barbican developers.

 Point is: just because you'll have face time, doesn't mean you should
 use it for what can be done via the mailing list.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] TripleO and Docker session etherpad

2014-04-29 Thread James Slagle

Hi, I thought I'd send out the link to the etherpad I've put together
for the summit session I proposed on TripleO and Docker. If there's
any initial discussion or something you'd like to see added, please
reply here or add directly to the etherpad.

https://etherpad.openstack.org/p/juno-summit-tripleo-and-docker

-- 
-- James Slagle
--

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Carlos Garza


On Apr 27, 2014, at 8:35 AM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:

On Fri, Apr 25, 2014 at 4:03 AM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:

Speaking of SSL - we have a few few project-wise issues such as lack of secure 
storage, lack of secure messaging, requirement to have opensource impl of SSL 
API (which yet to be added).
There's also a patch on review that is worth looking at, because someone has 
already put efforts into both design and code.
And before throwing away all those efforts we need to be sure it completely not 
suitable with the rest of API.


Where are these proposed patches your referring too. I don't seem them in 
openstack-neutron or in neutron-spec or the icehouse code in github? The 
closest thing I find is radware mentioning it as apart of the restClient driver.




3. L7 is also a separate work, it will not be accounted in 'API improvement' 
blueprint. You can sync with Samuel for this as we already have pretty detailed 
blueprints on that.

Please provide an example of how multiple pools will actually be used without 
L7.
As said above, the bp targets just the baseline for L7: removing 'root object' 
role from the Pool, to actually allow multiple pools in configuration when L7 
rules are added.


And again: Let's move the discussion off the mailing list where it's been 
happening over to the system where apparently others have been pressing forward 
without the obvious knowledge or consent of the people having the discussion. 
Oh, and by the way, because we've already written code here, a lot of what you 
propose is tacitly no longer up for discussion.

4. Attribute differences in REST resources.
This falls into two categories:
- existing attributes that should belong to one or another resource,

The devil's in the details here. I was very specific about which attributes 
belong to which objects because getting this wrong has serious implications for 
use cases. (For example, if neutron_subnet is an attribute of a pool, then 
this implies all members of the pool must be in the same neutron_subnet. And 
this breaks the use case that was described on the mailing list during the SSL 
re-encryption discussion where some members are in the same subnet, and some 
are across the internet on the other side of a VPN or otherwise.)
Right. I should have said it's a work item for me - to look closely through 
your doc and address the differences. Also, that is exactly the kind of work 
item where gerrit helps a lot.


You also need to define which attributes are immutable after creation of the 
object, and which can be changed with later updates (and how). This also has 
implications for use cases.
Well, this is usually defined in the code, I can add this to the spec as well. 
I hoped to avoid duplicate work.



If your proposal doesn't define this level of detail, then your proposal isn't 
addressing the use cases and is therefore incomplete.
I'm working on that.


- attributes that should be added (e.g. they didn't exist in current API)

Right. As I said last week, my intention was to try to address as many concerns 
and feature requests from the mailing list discussions, wiki pages, and google 
documents / spreadsheets as possible. I was hoping to take a stab at HA as 
well, but the result of that discussion so far is that we're nowhere near 
having any idea how to accomplish this in a way that is going to be generically 
possible for all operators.

I mean: You all do realize that if there's a key missing feature that one 
operator absolutely needs in order to continue their business operations, that 
isn't addressed in our proposals... then that operator is NOT going to use our 
product, right?

And that doesn't mean you need to offer all features out of the gate-- but you 
ought to have put some thought into how you're going to do it when the time 
comes. This proposal is trying to be that plan for how we're eventually going 
to do it. It will, of course, be developed incrementally.
So, what are we arguing about? I'm just doing the small part that fixes 
relationship issue with the obj model.


It is true that I haven't had the time to fill out all the use cases we thought 
about, or that became apparent from mailing list discussions as we were writing 
our API revision proposal--  our main drive was to get the proposal out the 
door. My plan was (and still is) to back-fill these use cases in the right 
place (which I'm no longer sure is the google doc that Samuel created, or the 
gerrit system) once we got the API proposal out. So I do apologize that I'm 
making reference to stuff that has been considered but not shared thus far and 
realize that not having it in the shared document weakens my position. I had to 
sleep.

The first class is better to be addressed in the blueprint review. The second 
class could be a small action items/blueprints or even bugs.
Example:
  1) custom_503 - that attribute

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi German,

Thanks for bringing up the VPN SSL implementation - we just took a look at
the blueprint:

https://docs.google.com/file/d/0B4kh-7VVPWlPOWlTM0QzNDJucjg/edit

and it matches the design we would take with the SSL entity portion of the
effort, in that we would like to make them first class citizens as opposed
to being defined by the LBaaS plugin.

I think that these two threads/efforts (SSL VPN and SSL LBaaS) should be
merged - I will start a new thread to this effect, since the current thread
deals with way too many things.

I concur with you regarding using Barbican to store the actual certs and
keys. I am yet to use it though, and plan to do so within this week to
evaluate its current state of maturity. Since Sam has already put in effort
towards the sql implementation of storage, and there are use cases that
prefer using sql vs barbican, I am of the view that making it configurable
to use either would be optimal. Other than that, my review comments were to
do about how to treat entities in the actual implementation - keeping the
SSL entities separate from LBaaS would help us move them later to keystone,
for I think that is where they should reside. I would like to have the ML's
views on this. BTW I haven't actually proposed a new API implementation yet
- for now, I'm just highlighting that the specification at
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL doesn't define it at all,
even though it lists the CLIs (which haven't been implemented yet in the
gerrit request at https://review.openstack.org/#/c/74031). We'd need at
least the API spec to test out the patch fully. We can figure the APIs out
by looking at the code, but it would be simpler to just have the API spec
listed out like in the OS API reference guides.

Sam's patch basically defines the new extensions for the SSL entities
inside the loadbalancer plugin. I prefer that they be implemented outside
of it. REST API wise, the only difference would be that today when I invoke
Sam's patch's SSL extension to list the ssl_certificates, it would look
thus:

stack@sslds1:~/devstack$ curl -i -X GET http://192.168.45.55:9696/
*v2.0/lb/ssl_certificates* -H User-Agent: python-keystoneclient -H
X-Auth-Token: $TOKEN

HTTP/1.1 200 OK

Content-Type: application/json; charset=UTF-8

Content-Length: 24

Date: Sat, 26 Apr 2014 04:42:48 GMT


{ssl_certificates: []}

stack@sslds1:~/devstack$



and if implemented outside, it would be GET http://192.168.45.55:9696/
*v2.0/ssl_certificates *or similar. However, code wise, it would make a
difference during any refactoring effort.



Regards,
Vijay





On Tue, Apr 29, 2014 at 3:04 PM, Eichberger, German 
german.eichber...@hp.com wrote:

  Vijay,



 SSL and certificate management is a major requirement from a cloud
 operator perspective. The VPN part of Neutron is looking into using
 Barbican and I am surprised that LB is going a different way/implementing
 their own store. Just for the record I prefer Barbican J



 Furthermore, we are still discussing the API and have several proposals so
 I am not sure how the SSL API/implementation you are proposing fits into
 that.



 German



 *From:* Vijay B [mailto:os.v...@gmail.com]
 *Sent:* Tuesday, April 29, 2014 2:30 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API
 proposal



 Also, a section for the API specification for the newly created SSL
 extensions needs to be added to
 https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL.



 Regards,

 Vijay



 On Tue, Apr 29, 2014 at 1:55 PM, Vijay B os.v...@gmail.com wrote:

 Hi Sam, Evgeny,



 I've reviewed https://review.openstack.org/#/c/74031 with my comments. I
 am not sure if there is a request with code newer than this link - please
 do let me know if that is the case.



 Thanks,

 Regards,

 Vijay



 On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
 german.eichber...@hp.com wrote:

 Sam,

 The use cases where pretty complete the last time I checked so let's move
 them to gerrit so we can all vote.

 Echoing Kyle I would love to see us focusing on getting things ready for
 the summit.

 German


 -Original Message-
 From: Samuel Bercovici [mailto:samu...@radware.com]
 Sent: Monday, April 28, 2014 11:44 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

 Hi,

 I was just working to push the use cases into the new format .rst but I
 agree that using google doc would be more intuitive.
 Let me know what you prefer to do with the use cases document:
 1. leave it at google docs at -
 https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
 2. Move it to the new format under -
 http://git.openstack.org/cgit/openstack/neutron-specs, I have already
 files a blue print
 https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and can
 complete the .rst process by tomorrow.

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

2014-04-29 Thread Carlos Garza

   This blueprint was marked abandoned.

On Apr 29, 2014, at 3:55 PM, Vijay B 
os.v...@gmail.commailto:os.v...@gmail.com
 wrote:

Hi Sam, Evgeny,

I've reviewed https://review.openstack.org/#/c/74031 with my comments. I am not 
sure if there is a request with code newer than this link - please do let me 
know if that is the case.

Thanks,
Regards,
Vijay


On Mon, Apr 28, 2014 at 2:12 PM, Eichberger, German 
german.eichber...@hp.commailto:german.eichber...@hp.com wrote:
Sam,

The use cases where pretty complete the last time I checked so let's move them 
to gerrit so we can all vote.

Echoing Kyle I would love to see us focusing on getting things ready for the 
summit.

German

-Original Message-
From: Samuel Bercovici [mailto:samu...@radware.commailto:samu...@radware.com]
Sent: Monday, April 28, 2014 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Hi,

I was just working to push the use cases into the new format .rst but I agree 
that using google doc would be more intuitive.
Let me know what you prefer to do with the use cases document:
1. leave it at google docs at - 
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
2. Move it to the new format under - 
http://git.openstack.org/cgit/openstack/neutron-specs, I have already files a 
blue print https://blueprints.launchpad.net/neutron/+spec/lbaas-use-cases and 
can complete the .rst process by tomorrow.

Regards,
-Sam.






-Original Message-
From: Kyle Mestery 
[mailto:mest...@noironetworks.commailto:mest...@noironetworks.com]
Sent: Monday, April 28, 2014 4:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal

Folks, sorry for the top post here, but I wanted to make sure to gather 
people's attention in this thread.

I'm very happy to see all the passion around LBaaS in Neutron for this cycle. 
As I've told a few people, seeing all the interest from operators and providers 
is fantastic, as it gives us valuable input from that side of things before we 
embark on designing and coding.
I've also attended the last few LBaaS IRC meetings, and I've been catching up 
on the LBaaS documents and emails. There is a lot of great work and passion by 
many people. However, the downside of what I've seen is that there is a logjam 
around progress here. Given we're two weeks out from the Summit, I'm going to 
start running the LBaaS meetings with Eugene to try and help provide some focus 
there.
Hopefully we can use this week and next week's meetings to drive to a 
consistent Summit agenda and lay the groundwork for LBaaS in Juno and beyond.

Also, while our new neutron-specs BP repository has been great so far for 
developers, based on feedback from operators, it may not be ideal for those who 
are not used to contributing using gerrit. I don't want to lose the voice of 
those people, so I'm pondering what to do. This is really affecting the LBaaS 
discussion at the moment. I'm thinking that we should ideally try to use Google 
Docs for these initial discussions and then move the result of that into a BP 
on neutron-specs. What do people think of that?

If we go down this path, we need to decide on a single Google Doc for people to 
collaborate on. I don't want to put Stephen on the spot, but his document may 
be a good starting point.

I'd like to hear what others think on this plan as well.

Thanks,
Kyle


On Sun, Apr 27, 2014 at 6:06 PM, Eugene Nikanorov 
enikano...@mirantis.commailto:enikano...@mirantis.com wrote:
 Hi,


 You knew from the action items that came out of the IRC meeting of
 April
 17 that my team would be working on an API revision proposal. You
 also knew that this proposal was to be accompanied by an object model
 diagram and glossary, in order to clear up confusion. You were in
 that meeting, you saw the action items being created. Heck, you even
 added the to prepare API for SSL and L7 directive for my team yourself!

 The implied but not stated assumption about this work was that it
 would be fairly evaluated once done, and that we would be given a short 
 window (ie.
 about a week) in which to fully prepare and state our proposal.

 Your actions, though, were apparently to produce your own version of
 the same in blueprint form without notifying anyone in the group that
 you were going to be doing this, let alone my team. How could you
 have given my API proposal a fair shake prior to publishing your
 blueprint, if both came out on the same day? (In fact, I'm lead to
 believe that you and other Neutron LBaaS developers hadn't even
 looked at my proposal before the meeting on 4/24, where y'all started
 determining product direction, apparently by
 edict.)


 Therefore, looking honestly at your actions on this and trying to
 give you the benefit of the doubt, I still must assume that you

[openstack-dev] [Neutron] [LBaaS][VPN] SSL cert implementation for LBaaS and VPN

Hi,

It looks like there are areas of common effort in multiple efforts that are
proceeding in parallel to implement SSL for LBaaS as well as VPN SSL in
neutron.

Two relevant efforts are listed below:


https://review.openstack.org/#/c/74031/   (
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL)

https://review.openstack.org/#/c/58897/   (
https://blueprints.launchpad.net/openstack/?searchtext=neutron-ssl-vpn)



Both VPN and LBaaS will use SSL certificates and keys, and this makes it
better to implement SSL entities as first class citizens in the OS world.
So, three points need to be discussed here:

1. The VPN SSL implementation above is putting the SSL cert content in a
mapping table, instead of maintaining certs separately and referencing them
using IDs. The LBaaS implementation stores certificates in a separate
table, but implements the necessary extensions and logic under LBaaS. We
propose that both these implementations move away from this and refer to
SSL entities using IDs, and that the SSL entities themselves are
implemented as their own resources, serviced either by a core plugin or a
new SSL plugin (assuming neutron; please also see point 3 below).

2. The actual data store where the certs and keys are stored should be
configurable at least globally, such that the SSL plugin code will
singularly refer to that store alone when working with the SSL entities.
The data store candidates currently are Barbican and a sql db. Each should
have a separate backend driver, along with the required config values. If
further evaluation of Barbican shows that it fits all SSL needs, we should
make it a priority over a sqldb driver.

3. Where should the primary entries for the SSL entities be stored? While
the actual certs themselves will reside on Barbican or SQLdb, the entities
themselves are currently being implemented in Neutron since they are being
used/referenced there. However, we feel that implementing them in keystone
would be most appropriate. We could also follow a federated model where a
subset of keys can reside on another service such as Neutron. We are fine
with starting an initial implementation in neutron, in a modular manner,
and move it later to keystone.


Please provide your inputs on this.


Thanks,
Regards,
Vijay
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] BBG edit of new API proposal