date:20150611

On 2015-06-11 07:51:55 +0200 (+0200), Philipp Marek wrote:
[...]
 I still stand by my opinion (as voiced in Vancouver) that for such
 one-off things (that contributors are not likely to repeat over
 and over again) it might make sense to have -infra simply *do*
 them[3].
[...]

To reiterate my response from the summit, it's a neat idea but not
one the Infra team has the bandwidth to entertain at the moment. As
you've noticed we're understaffed and while we're continually trying
to grow the team it takes many months to a year or more of full-time
exposure to our current systems to bring new people up to speed to
help us run it. Also we don't actually have a holistic view of the
underlying tests being run by the jobs... for that you need to
elicit assistance from the QA team who maintain DevStack/Tempest and
did the plugin design for things like out-of-tree driver testing,
and also the project teams for the software at which these drivers
and backends are targeted.

So while I and others are happy to have our CI run jobs to test
OpenStack drivers for other free software backends, don't expect the
actual work and learning curve to necessarily be any less than
building your own CI system from scratch (just different).

 It doesn't make sense to require people to learn about things they
 will never use again - and the amount of time spent answering the
 questions, diagnosing problems and so on is quite a bit higher
 than doing it simply right the first time.

This is, I think, also a common misconception. The people who write
these jobs to run in our CI need to stick around or induct
successors to help maintain them and avoid bitrot as our systems
constantly change and evolve. I know the same goes for the drivers
themselves... if people don't keep them current with the OpenStack
software into which they're integrating, support will quickly be
dropped due to quality control concerns.

 And if it's *that* often needed, why not write a small script
 that, given a name, does the needed changes, so that only a commit
  review is needed?
[...]

Definitely something that people who have experience writing these
could collaborate on contributing. As I mentioned, the Infra team
doesn't have the complete picture, but the people who have sweated
and bled to get their drivers tested and integrated do, at least to
a greater extent than we do.

This is all to say I understand the frustration, but I don't have a
simple solution for it unfortunately.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Looking for help getting git-review to work over https

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at 
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't 
working (times out with Could not connect to gerrit).  I've confirmed that I 
can reach other external sites on port 443.

Can someone give me a hand with this?

--
David M. Karr | ATT | Service Standards - Open Platform for Network Function 
Virtualization
(425) 580-4547 work
(206) 909-0664 cell
(425) 892-5432 cell


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][reseller] New way to get a project scoped token by name

2015-06-11 Thread Raildo Mascena

Hi Folks,

As we have discussed in the last Keystone meeting, we created an etherpad
with the alternatives to solve this problem:
https://etherpad.openstack.org/p/reseller-project-token
We have also decided to take a vote to choose the best option in the next
Keystone Meeting (#openstack-meeting - June 16th - 18:00 UTC).

It would be great if you could take a look before the meeting, so we could
discuss and improve this document before the vote.

Best regards,


On Tue, Jun 9, 2015 at 12:12 PM Dolph Mathews dolph.math...@gmail.com
wrote:

 On Mon, Jun 8, 2015 at 10:44 PM, Jamie Lennox jamielen...@redhat.com
 wrote:



 - Original Message -
  From: David Chadwick d.w.chadw...@kent.ac.uk
  To: openstack-dev@lists.openstack.org
  Sent: Saturday, 6 June, 2015 6:01:10 PM
  Subject: Re: [openstack-dev] [keystone][reseller] New way to get a
 project scoped token by name
 
 
 
  On 06/06/2015 00:24, Adam Young wrote:
   On 06/05/2015 01:15 PM, Henry Nash wrote:
   I am sure I have missed something along the way, but can someone
   explain to me why we need this at all.  Project names are unique
   within a domain, with the exception of the project that is acting as
   its domain (i.e. they can only every be two names clashing in a
   hierarchy at the domain level and below).  So why isn’t specifying
   “is_domain=True/False” sufficient in an auth scope along with the
   project name?
  
   The limitation of  Project names are unique within a domain is
   artificial and somethi8ng we should not be enforcing.  Names should
 only
   be unique within parent project.
 
  +++1

 I said the exact same thing as Henry in the other thread that seems to be
 on the same topic. You're correct the limitation of Project names are
 unique within a domain is completely artificial, but it's a constraint
 that allows us to maintain the auth systems we currently have and will not
 harm the reseller model (because they would be creating new domains).

 It's also a constraint that we can relax later when multitenancy is a bit
 more established and someone has a real issue with the limitation - it's
 not something we can ever claw back again if we allow some looking up
 projects by name with delimiters.

 I think for the time being it's an artificial constraint we should
 maintain.


 +1





  
   This whole thing started by trying to distinguish a domain from a
   project within that domain that both have the same name. We can
 special
   case that, but it is not a great solution.
  
  
  
  
   Henry
  
   On 5 Jun 2015, at 18:02, Adam Young ayo...@redhat.com
   mailto:ayo...@redhat.com wrote:
  
   On 06/03/2015 05:05 PM, Morgan Fainberg wrote:
   Hi David,
  
   There needs to be some form of global hierarchy delimiter - well
   more to the point there should be a common one across OpenStack
   installations to ensure we are providing a good and consistent (and
   more to the point inter-operable) experience to our users. I'm
   worried a custom defined delimiter (even at the domain level) is
   going to make it difficult to consume this data outside of the
   context of OpenStack (there are applications that are written to
 use
   the APIs directly).
   We have one already.  We are working JSON, and so instead of project
   name being a string, it can be an array.
  
   Nothing else is backwards compatible.  Nothing else will ensure we
   don;t break exisiting deployments.
  
   Moving forward, we should support DNS notation, but it has to be an
   opt in
  
  
   The alternative is to explicitly list the delimiter in the project
 (
   e.g. {hierarchy: {delim: ., domain.project.project2}} ).
 The
   additional need to look up the delimiter / set the delimiter when
   creating a domain is likely to make for a worse user experience
 than
   selecting one that is not different across installations.
  
   --Morgan
  
   On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
   d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
  
  
  
   On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
   
You mean creating some kind of delimiter attribute in the
 domain
entity? That seems like a good idea, although it does not
   solve the
problem Morgan's mentioned that is the global hierarchy
 delimiter.
  
   There would be no global hierarchy delimiter. Each domain would
   define
   its own and this would be carried in the JSON as a separate
   parameter so
   that the recipient can tell how to parse hierarchical names
  
   David
  
   
Henrique
   
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
   mailto:d.w.chadw...@kent.ac.uk
   mailto:d.w.chadw...@kent.ac.uk escreveu:
   
   
   
On 02/06/2015 23:34, Morgan Fainberg wrote:
 Hi Henrique,

 I don't think we need to specifically call out that we

Re: [openstack-dev] [congress] table with named parameters in rule's left side ?

2015-06-11 Thread Tim Hinrichs

Hi Radek,

1. You can't use column references on any table except those created by a
datasource, mainly because Congress doesn't know the name of the columns
for those tables.  We've kicked around the idea of letting policy-writers
declare the column names of any table, but it's trickier than it sounds.

2. Even if we solved (1), there's not much point in using column-references
in the head (left-hand-side) of a rule because you always need to include
all of the columns anyway.  That restriction is baked deeply into the
semantics of the language: if you leave out a column in the head the size
of the table is infinite.  The only benefit to column-references in the
head would be enabling you to specify the columns in any order.

3. I've thought about tweaking the semantics of Datalog so that it includes
both tuples and dictionaries.  But that is a major effort.

4. We don't actually allow column-references even within execute[
action(...)] because of (2).

5.  In your example, can you write it without the column references?  I
don't see the predeploy_modify rule to understand why you need column
references in the query.

 predeploy_modify(uuid,uuid,'add_property', 5, name=image”,
value=uuid)

Tim



On Thu, Jun 11, 2015 at 6:44 AM Pospisil, Radek radek.pospi...@hp.com
wrote:

  Hello,



 Is it possible to have named parameters on rule’s left side, for example:



 1.   predeploy_modify(eid,oid,add_property,5, name=”image”,
 value=pvalue) :- …. Glancev2:images(name=pvalue,…)

 2.   predeploy_modify(eid,oid,add_object, 10, type=”monitoring”,
 port=8190, path=”/aa/bb”) :- ….



 My Usecase is following – I want to use Congress to provide me list of
 ‘actions’ that I have to do on Murano environment prior it is deployed –
 for example:

 · I want to enforce/use specific image for given component(s) in
 environment, so I set corresponding property (example 1)

 · I want to add an object (monitoring) with properties to
 environment  (example 2)



 Thus generally “I want to query for one rule with variable set/dictionary
 of arguments” – for example using simulation API:

 $ openstack congress policy simulate test 'predeploy_modify()' '' action

 Result will be

 predeploy_modify(uuid,uuid,'add_property', 5, name=image”,
 value=uuid)

 predeploy_modify(uuid,uuid,'add_object', 10, type=monitoring,
 port=…, path=…)







 The problem is that if I do (as an example):



 $  openstack congress policy rule create test a(o,p,q=4) :- b(o),b(p)

 ERROR: openstack Syntax error for rule::Compiler found errors:Atom a(q=4)
 uses named parameters but the columns for table a have not been declared.

 Atom a(q=4) uses named parameters but the columns for table a have not
 been declared. (HTTP 400) (Request-ID:
 req-b05683e6-766a-4be8-a238-5811eb6f7125)





 So is it possible to use named parameters on not-declared tables?

 I know that it is possible to do for “execute[ action(…) ] :- “, where
 positional and keyword/named set of parameters is passed to action-executor.





   Regards,



 Radek

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][python3] use of six.iteritems()

2015-06-11 Thread gordon chung

 it is just me, or are these differences pretty negligible considering 
 this is the 1 million item dictionary, which in itself is a unicorn 
 in openstack code or really most code anywhere? 
 
 as was stated before, if we have million-item dictionaries floating 
 around, that code has problems. I already have to wait full seconds 
 for responses to come back when I play around with Neutron + Horizon in 
 a devstack VM, and that's with no data at all. 100ms extra for a 
 hypothetical million item structure would be long after the whole app 
 has fallen over from having just ten thousand of anything, much less a 
 million. 

my concern isn't the 1million item dictionary -- i think we're all just using 
that as a simple test -- it's the 100 concurrent actions against a 10,000 item 
dictionary or the  1000 concurrent actions against at 1000 item dictionary... 
when tracking htop to see memory consumption, items() consistently doubled the 
memory consumption of iteritems().

again, i just want to reiterate, i'm not saying don't use items(), i just think 
we should not blindly use items() just as we shouldn't blindly use 
iteritems()/viewitems()

 
 My only concern with items() is that it is semantically different in 
 Py2k / Py3k. Code that would otherwise have a dictionary changed 
 size issue under iteritems() / py3k items() would succeed under py2k 
 items(). If such a coding mistake is not covered by tests (as this is 
 a data-dependent error condition), it would manifest as a sudden error 
 condition on Py3k only. 
 
  
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Follow up actions from the Summit: please help

2015-06-11 Thread Matt Riedemann




On 6/5/2015 4:47 AM, John Garbutt wrote:

Hi,

So in the interests of filling up your inbox yet further...

We have lots of etherpads from the summit:
https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Nova

I have extracted all the action items here:
https://etherpad.openstack.org/p/YVR-nova-liberty-summit-action-items

Please do add any actions that might be missing.

Matt Riedemann wins the prize[1] for the first[2][3] completed action
item, by releasing python-novaclient with the volume actions
deprecated.


I will take any and all prizes, virtual or not.



Its has been noted that I greedily took most of the actions for
myself. The name is purely the person who gets to make sure the action
happens. If you want to help (please do help!), contact the person
named, who might be able to hand over that task.

Thanks,
John

[1] its a virtual trophy, here you go: --|
[2] may not have been the first, but whatever
[3] no, there is no prize for the last person

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Thanks,

Matt Riedemann


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][python3] use of six.iteritems()

2015-06-11 Thread Victor Stinner


Hi,

Le 10/06/2015 02:15, Robert Collins a écrit :

python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.items(): pass'
10 loops, best of 3: 76.6 msec per loop



python2.7 -m timeit -s 'd=dict(enumerate(range(100)))' 'for i in
d.iteritems(): pass'
100 loops, best of 3: 22.6 msec per loop


.items() is 3x as slow as .iteritems(). Hum, I don't have the same 
results. Try attached benchmark. I'm using my own wrapper on top of 
timeit, because timeit is bad at calibrating the benchmark :-/ timeit 
gives unreliable results.


Results on with CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz:

[ 10 keys ]
713 ns: iteritems
922 ns (+29%): items

[ 10^3 keys ]
42.1 us: iteritems
59.4 us (+41%): items


[ 10^6 keys (1 million) ]
89.3 ms: iteritems
442 ms (+395%): items

In my benchmark, .items() is 5x as slow as .iteritems(). The code to 
iterate on 1 million items takes almost an half second. IMO adding 300 
ms to each request is not negligible on an application. If this delay is 
added multiple times (multiple loops iterating on 1 million items), we 
may reach up to 1 second on an user request :-/


Anyway, when I write patches to port a project to Python 3, I don't want 
to touch *anything* to Python 2. The API, the performances, the 
behaviour, etc. must not change.


I don't want to be responsible of a slow down, and I don't feel able to 
estimate if replacing dict.iteritems() with dict.items() has a cost on a 
real application.


As Ihar wrote: it must be done in a separated patch, by developers 
knowning well the project.


Currently, most developers writing Python 3 patches are not heavily 
involved in each ported project.


There is also dict.itervalues(), not only dict.iteritems().

for key in dict.iterkeys() can simply be written for key in dict:.

There is also xrange() vs range(), the debate is similar:
https://review.openstack.org/#/c/185418/

For Python 3, I suggest to use from six.moves import range to get the 
Python 3 behaviour  on Python 2: range() always create an iterator, it 
doesn't create a temporary list. IMO it makes the code more readable 
because for i in xrange(n): becomes for i in range(n):. six is not 
written outside imports and range() is better than xrange() for 
developers starting to learn Python.


Victor

Micro-benchmark for the Python operation key in dict. Run it with:

./python.orig benchmark.py script bench_str.py --file=orig
./python.patched benchmark.py script bench_str.py --file=patched
./python.patched benchmark.py compare_to orig patched

Download benchmark.py from:

https://bitbucket.org/haypo/misc/raw/tip/python/benchmark.py

import gc

def consume_items(dico):
for key, value in dico.items():
pass


def consume_iteritems(dico):
for key, value in dico.iteritems():
pass


def run_benchmark(bench):
for nkeys in (10, 10**3, 10**6):
bench.start_group('%s keys' % nkeys)
dico = {str(index): index for index in range(nkeys)}

bench.compare_functions(
('iteritems', consume_iteritems, dico),
('items', consume_items, dico),
)
dico = None
gc.collect()
gc.collect()

if __name__ == __main__:
import benchmark
benchmark.main()
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

2015-06-11 Thread Richard Raseley


Flavio Percoco wrote:

Greetings,

I'm reaching out to our puppet community looking for help on creating
Zaqar's puppet manifests. We've started doing lots of work to help the
community adopt Zaqar and it'd be a shame to get at the end of the
road without having OPs friendly deployment tools.

I tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Flavio,

Apologies for not yet replying to your email dated June 4th.

I have time set aside tomorrow (Friday from 1PM - 4PM) to begin review 
of the work that's already done and start enumerating what the next 
steps are. Look for some updated information from me either tomorrow 
afternoon or over the weekend (which I'll share here for visibility).


What TZ are you in (in case I need to poke you with some questions)?

Regards,

Richard

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][python3] use of six.iteritems()

2015-06-11 Thread Jay Pipes


On 06/11/2015 01:16 AM, Robert Collins wrote:

But again - where in OpenStack does this matter the slightest?


Precisely. I can't think of a single case where we are iterating over 
anywhere near the number of dictionary items that we would see any 
impact whatsoever.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [congress] table with named parameters in rule's left side ?

2015-06-11 Thread Pospisil, Radek

Hello,

Is it possible to have named parameters on rule's left side, for example:


1.   predeploy_modify(eid,oid,add_property,5, name=image, value=pvalue) 
:-  Glancev2:images(name=pvalue,...)

2.   predeploy_modify(eid,oid,add_object, 10, type=monitoring, 
port=8190, path=/aa/bb) :- 

My Usecase is following - I want to use Congress to provide me list of 
'actions' that I have to do on Murano environment prior it is deployed - for 
example:

* I want to enforce/use specific image for given component(s) in 
environment, so I set corresponding property (example 1)

* I want to add an object (monitoring) with properties to environment  
(example 2)

Thus generally I want to query for one rule with variable set/dictionary of 
arguments - for example using simulation API:
$ openstack congress policy simulate test 'predeploy_modify()' '' action
Result will be
predeploy_modify(uuid,uuid,'add_property', 5, name=image, value=uuid)
predeploy_modify(uuid,uuid,'add_object', 10, type=monitoring, port=..., 
path=...)



The problem is that if I do (as an example):

$  openstack congress policy rule create test a(o,p,q=4) :- b(o),b(p)
ERROR: openstack Syntax error for rule::Compiler found errors:Atom a(q=4) uses 
named parameters but the columns for table a have not been declared.
Atom a(q=4) uses named parameters but the columns for table a have not been 
declared. (HTTP 400) (Request-ID: req-b05683e6-766a-4be8-a238-5811eb6f7125)


So is it possible to use named parameters on not-declared tables?
I know that it is possible to do for execute[ action(...) ] :- , where 
positional and keyword/named set of parameters is passed to action-executor.


  Regards,

Radek
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

2015-06-11 Thread Flavio Percoco


Greetings,

I'm reaching out to our puppet community looking for help on creating
Zaqar's puppet manifests. We've started doing lots of work to help the
community adopt Zaqar and it'd be a shame to get at the end of the
road without having OPs friendly deployment tools.

I tried to work on this myself and then Jay Clark helped out a bit.
Here's the code[0], which is unfortunately not complete.

This said, I realize packaging is important and I'm happy to say that
there's a package for fedora/centos and Zigo is working on debian's
(Zigo, I know you're blocked by something I need to do, it's coming
;).

So, can we get some help from the puppet team during Liberty to create
these manifests?

It goes without saying that we're more than happy to help if needed.

[0] https://github.com/jasontclark/puppet-zaqar

Cheers,
Flavio

P.S: Puppet is just a start, in the future it'd be awesome to have
support for other deployment tools.

--
@flaper87
Flavio Percoco


pgpMSjHHaIRwL.pgp
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] grenade with external plugins for the big tent - how to use

2015-06-11 Thread Kyle Mestery

On Thu, Jun 11, 2015 at 6:11 AM, Sean Dague s...@dague.net wrote:

 Yesterday we landed the infrastructure for Grenade external plugins -
 https://review.openstack.org/#/c/185050/

 The first user of this is the Heat project, with a patch that's nearly
 ready to land (still sorting out an issue because heat's cli commands
 aren't console entry points) - https://review.openstack.org/#/c/188148/.
 Much appreciation to the Heat team for patience in getting here, and for
 helping sort out all the infrastructure.

 For additional projects to work the basic pattern is as follows:

 * create a custom grenade job for your project
 * write a grenade plugin following the instructions here -
 https://github.com/openstack-dev/grenade/blob/master/PLUGINS.rst - put
 it in your project tree.
 * export the following in your project-config definition

 export GRENADE_PLUGINRC enable_grenade_plugin PROJECTNAME
 git://git.openstack.org/openstack/PROJECTNAME

 And... you should be good to go. Additional questions on moving forward,
 or clarifications in the documentation, can be handled on this thread or
 in the #openstack-qa channel.


This is really pretty awesome! Very excited that this will allow projects
to host their own grenade plugins in their own repositories. Similar to the
devstack plugins, I think this is a huge win! Great work!

Kyle


 -Sean

 --
 Sean Dague
 http://dague.net

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How does instance's tap device macaddress generate?

2015-06-11 Thread changzhi

Hi, I know that neutron port's mac address was generated by neutron.conf and 
default value is fa:16:3e which from base_mac configuration. I don't know how 
the tap device's mac address generates and why tap device mac address was 
fe:16:3e:xxx. I think that tap device mac address was generated by libvirt. 


Thx
changzhi
 
 
-- Original --
From:  Radek Smigielskiradek.smigiel...@ymail.com;
Date:  Thu, Jun 11, 2015 07:26 PM
To:  OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.org; 

Subject:  Re: [openstack-dev] How does instance's tap device macaddress 
generate?

 
 On Thursday, 11 June 2015, 12:00:46, Neil Jerram neil.jer...@metaswitch.com 
 wrote:
  On 11/06/15 10:47, changzhi wrote:
  Hi, all.
  I create a vm and it's neutron port's mac address is
  fa:16:3e:3f:02:ff. I see fa:16:3e:3f:02:ff inside 
 vm when I run
  ifconfig eth0. Why does vm's tap device's mac address 
 is
  fe:16:3e:3f:02:ff? Why different between neutron port's mac 
 address
  and tap device's mac address? Does libvirt create instance tap device
  and its mac address is generated randomly?
 
  Thx
  zhi
 
 There are two MAC addresses, one at each end of the link between the 
 host and the VM.
 
 ---+
   Host  |   +---+
 |   | VM|
  tap12345-CD --- eth0   |
   fa:16:3e:56:71:42 |   | fa:16:3e:3f:02:ff |
 |   |   |
 |   +---+
 ---+
 
 I believe that both of these addresses are randomly generated, although 
 I'm not sure exactly which components do that.
 
 Does that help at all?
 
 Thanks,
 Neil



In neutron.conf you've got base_mac option and fa:16:3e is the default value.

# Base MAC address. The first 3 octets will remain unchanged. If the
# 4h octet is not 00, it will also be used. The others will be
# randomly generated.
# 3 octet
# base_mac = fa:16:3e:00:00:00
# 4 octet
# base_mac = fa:16:3e:4f:00:00





Cheers,
Radosław Śmigielski

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet][zaqar] Help needed creating Zaqar manifests for puppet.

Hey,

On 06/11/2015 09:29 AM, Flavio Percoco wrote:
 Greetings,
 
 I'm reaching out to our puppet community looking for help on creating
 Zaqar's puppet manifests. We've started doing lots of work to help the
 community adopt Zaqar and it'd be a shame to get at the end of the
 road without having OPs friendly deployment tools.

+1

 
 I tried to work on this myself and then Jay Clark helped out a bit.
 Here's the code[0], which is unfortunately not complete.

It's a good start and it will help us to understand how to configure it.

 
 This said, I realize packaging is important and I'm happy to say that
 there's a package for fedora/centos and Zigo is working on debian's
 (Zigo, I know you're blocked by something I need to do, it's coming
 ;).
 
 So, can we get some help from the puppet team during Liberty to create
 these manifests?

So we have some folks developping tools [1] to bootstrap Puppet
OpenStack modules with basic bits (we are so lazy) and zaqar could
benefit of this tool. I think we can help you to generate the basic
structure of the module and maybe you could help in porting your bits to
the new compliant module.

On my side, I can take care of 1/ make sure the repo is on Stackforge
(for start, then it will move under OpenStack namespace once done) 2/
help in unit/functional testing (rspec, beaker).


 It goes without saying that we're more than happy to help if needed.
 
 [0] https://github.com/jasontclark/puppet-zaqar
 
 Cheers,
 Flavio
 
 P.S: Puppet is just a start, in the future it'd be awesome to have
 support for other deployment tools.
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

[1] https://github.com/enovance/puppet-openstack-cookiecutter (now
eNovance but moving to Stackforge:
https://review.openstack.org/#/c/188929/ )
-- 
Emilien Macchi



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [third-party] Weekly Third Party CI Working Group meeting change

2015-06-11 Thread Kurt Taylor

Following feedback for increasing working group participation from
Vancouver summit[1] and discussions in the weekly meetings[2], we have
decided to move the Wednesday working group meeting times and reduce their
frequency. The Monday Office Hours meetings will remain unchanged.

The options for moving the meeting so that it would no longer conflict with
Neutron and Cinder meetings, and still be in accessible hours for those
that participate, were very few. The proposal is to move the working group
meeting from Wednesday to Tuesday, and to drop the 0400 UTC meeting. For
our APAC friends seeking assistance, there is still the Monday Office Hours
meeting at 0800 UTC.

The proposed time is bi-weekly (every other week) on even weeks, Tuesdays
at 1700 UTC. I have already reserved that time since our options were so
limited.[3] Unless there is major objection, the meetings will start on
Tuesday, June 23rd. Note that this skips next week since we are dropping
the 0400 meeting time. The meetings will continue bi-weekly: June 23rd,
July 7th, July 21st, August 4th...

I will send out reminders to make sure that everyone remembers this
transition.

Thanks!
Kurt Taylor (krtaylor)

[1] https://etherpad.openstack.org/p/liberty-ci-loops-bof
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] https://review.openstack.org/#/c/190221
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][python3] use of six.iteritems()

2015-06-11 Thread Sean Dague

On 06/11/2015 09:02 AM, Jay Pipes wrote:
 On 06/11/2015 01:16 AM, Robert Collins wrote:
 But again - where in OpenStack does this matter the slightest?
 
 Precisely. I can't think of a single case where we are iterating over
 anywhere near the number of dictionary items that we would see any
 impact whatsoever.
 
 Best,
 -jay

+1.

This is a massive premature optimization which just makes all the code
gorpy for no real reason.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][L3] L3 routed network segments

2015-06-11 Thread Neil Jerram


Hi Carl et al.,

I see from [1] that L3 routed network segments are on the Neutron L3 
subteam's roadmap for Liberty, and I wanted to say that I'm very 
interested in this work, and - if there isn't someone else already - 
happy to take the lead on making it happen.


I'm aware already of several parties interested in this work, and 
discussion between those parties has been proceeding at [2].  If there 
is anyone else interested - i.e. in networks that are predominantly L3 
routed, and/or where L2 broadcast is partitioned into subsets of the 
overall network - please do take a look at that bug [2] and add your 
thoughts there, or comment in response to this email.


I'm afraid I've not previously been attending L3 subteam IRC meetings - 
something which I now see was a mistake! - but I plan to do that from 
now on.  For today's meeting, though, I'm afraid I have to leave at the 
half way point.  Therefore, if you (Carl) think it would be useful to 
raise or discuss this during the meeting, I'd appreciate if that could 
be scheduled during the first half hour.


Many thanks,
Neil


[1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam
[2] https://bugs.launchpad.net/neutron/+bug/1458890

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Nominating Joshua Hesketh for infra-root

2015-06-11 Thread Paul Belanger


On 06/11/2015 12:54 PM, James E. Blair wrote:

The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access).  Read all about it here:

   http://docs.openstack.org/infra/system-config/project.html#teams

Joshua has been a valuable member of infra-core for some time, having a
high degree of familiarity with Zuul and related systems and an
increasing interest in other operational aspects of the project
infrastructure.  His eagerness to contribute is presently tempered by
most of the infra-root team sleeping[1] during large parts of his day.
I look forward to Joshua being able to approve changes with confidence.

Joshua, if you are interested, please propose your SSH key to
system-config, and thanks again for all of your work!


+1

Congrats Joshua.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Manila] Network path between admin network and shares

2015-06-11 Thread Rodrigo Barbieri

Hello all,

There has been a lot of discussion around Share Migration lately. This
feature has two main code paths:

- Driver Migration: optimized migration of shares from backend A to backend
B where both backends belong to the same driver vendor. The driver is
responsible for migrating and just returns a model update dictionary with
necessary changes to DB entry.

- Generic Migration: This is the universal fallback for migrating a share
from backend A to backend B, from any vendor to any vendor. In order to do
this we have the approach where a machine in the admin network mounts both
shares (source and destination) and copy the files. The problem is that it
has been unusual so far in Manila design for a machine in the admin network
to access shares which are served inside the cloud, a network path must
exist for this to happen.

I was able to code this change for the generic driver in the Share
Migration prototype (https://review.openstack.org/#/c/179791/).

We are not sure if all driver vendors are able to accomplish this. We would
like to ask you to reply to this email if you are not able (or even not
sure) to create a network path from your backend to the admin network so we
can better think on the feasability of this feature.

More information in blueprint:
https://blueprints.launchpad.net/manila/+spec/share-migration


Regards,
-- 
Rodrigo Barbieri
Computer Scientist
Federal University of São Carlos
+55 (11) 96889 3412
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][L3] Modular L3 Discussion

2015-06-11 Thread Carl Baldwin

Hi all,

Cross posting to openstack-dev and openstack-operators

We discussed supporting multiple types of routers within a Neutron in
the L3 meeting this morning [1].  The team would like more feedback
from the community in order to refine use cases and also to consider
possible approaches to achieved these use cases.  The team would like
to gather feedback on an etherpad [2] created for this purpose.  If
this is something that you have been yearning for or thinking about
trying to implement, please provide your feedback.  This is still
early in the discussion, the best time for your feedback to matter.

Paul Carver and Isaku Yamahata are two contacts you could approach
directly if you would like to have a discussion before capturing your
feedback on the etherpad.  They are also welcome to follow up to this
email if I missed any important point here.

Carl

[1] 
http://eavesdrop.openstack.org/meetings/neutron_l3/2015/neutron_l3.2015-06-11-15.04.log.html#l-23
[2] https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Manila] Ask for help on supportting the 3-rd party CI for HDFS driver

2015-06-11 Thread Alex Meade

Hi Chen Li,

You are correct in that setting up a CI system is not a trivial task. IMO
it would make sense to have this eventually tested with infras
infrastructure but as Jeremy mentioned, they don't have the bandwidth to do
the setup. Below are some links to get started if you all are interested in
setting up a CI system. If this is not possible I recommend bringing it up
in the Manila weekly meeting so Manila folks can figure out how to get the
HDFS system tested and perhaps this is work that Manila core can accomplish.

OpenStack Third Party CI requirements:
http://docs.openstack.org/infra/system-config/third_party.html

Third Party CI meetings: https://wiki.openstack.org/wiki/Meetings/ThirdParty
(Mondays at 1500 UTC and Tuesdays at 0800 UTC are the meetings to get help
with CI setup)

Tools for setting up CI:
https://github.com/openstack-infra/puppet-openstackci/ (this is just
getting started)
https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers (Cinder
specific but helpful)

-Alex

On Wed, Jun 10, 2015 at 3:48 AM, Li, Chen chen...@intel.com wrote:

  Hello Manila,



 There is a HDFS driver in Manila summited by our team in Kilo, so I guess
 we do own this driver in Manila for current situation.



 But, CI systems are really new to us, and we heard from other teams that
 they took almost one year to implement a CI for going through all the
 company processes and building all related staff for it.
 And , the biggest issue we have is there is not enough resource to
 actually implement and maintain the CI as that is not allowed by the team’s
 strategy.


 We strongly believe the HDFS driver will be really useful in
 Manila/Openstack, and might be used by other Openstack projects such as
 Sahara/Cognitive which are big data related projects in the near future,
 thus we don’t want to see the driver to be remove.



 Do we have a volunteer to take over the CI for HDFS driver as it is an
 open source distributed storage system which actually has no vendor
 dependency ?


 Looking forward to your reply.



 Thanks.

 -chen



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

2015-06-11 Thread ZZelle

Hi David,


Following git config options are supported by git-review (
https://review.openstack.org/116035)

   git config --global gitreview.scheme https
   git config --global gitreview.port 443

BUT the feature was merged after 1.24 (it's highlighted by your git review
-vs)
so the feature is currently only available on the git-review master branch
(which
is quite stable, i use it every day).


Cedric/ZZelle@irc


On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID dk0...@att.com wrote:

   I followed the instructions for installing and configuring corkscrew,
 similar to what you provided here.  The result seems to indicate it did
 something, but the overall result is the same:

 2015-06-11 13:07:25.866568 Running: git log --color=never --oneline
 HEAD^1..HEAD

 2015-06-11 13:07:25.869309 Running: git remote

 2015-06-11 13:07:25.872742 Running: git config --get gitreview.username

 No remote set, testing ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git

 2015-06-11 13:07:25.874869 Running: git push --dry-run ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git --all

 The authenticity of host '[review.openstack.org]:29418 (no hostip for
 proxy command)' can't be established.

 RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.

 Are you sure you want to continue connecting (yes/no)? yes

 ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not
 work.

 Could not connect to gerrit.

 Enter your gerrit username:

 ---



 *From:* Paul Michali [mailto:p...@michali.net]
 *Sent:* Thursday, June 11, 2015 11:09 AM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Looking for help getting git-review to
 work over https



 Do you know if you have SSH access to the outside world through the
 firewall?



 Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing,
 created a .ssh/config file with:



 Host review.openstack.org

 ProxyCommand corkscrew proxy-host 80 %h %p



 The proxy host is one that allows HTTP/HTTPS to outside world and
 corkscrew tunnels the SSH through to port 80.



 HTHs,



 PCM



 On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID dk0...@att.com wrote:

   Thanks for replying.



 % git review -vs

 2015-06-11 09:30:38.396076 Running: git log --color=never --oneline
 HEAD^1..HEAD

 2015-06-11 09:30:38.399021 Running: git remote

 2015-06-11 09:30:38.401033 Running: git config --get gitreview.username

 No remote set, testing ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git

 2015-06-11 09:30:38.402988 Running: git push --dry-run ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git --all

 ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not
 work.

 Could not connect to gerrit.

 Enter your gerrit username:



 This output is interesting, because I followed the instructions to set the
 scheme and port to https and 443, which can be seen from:

 % git config --global -l

 user.name=David Karr

 user.email=dk0...@att.com

 gitreview.scheme=https

 gitreview.port=443



 Concerning the question ‘Do you have gerrit remote already configured?’,
 I guess I’d have to say I don’t know. I’ve followed instructions for
 setting up my pub key, but I’m not sure exactly what is entailed in “gerrit
 remote”.



 I can get to https://review.openstack.org/ from my browser and from the
 command line with curl.



 The “ls-remote” command returns without error (or any other output).



 *From:* Yuriy Taraday [mailto:yorik@gmail.com]
 *Sent:* Thursday, June 11, 2015 9:19 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Looking for help getting git-review to
 work over https



 On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.com wrote:

 I could use some help with setting up git-review in a slightly unfriendly
 firewall situation.

 I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks
 the non-standard ssh port.  I'm following the instructions at
 http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't
 working (times out with Could not connect to gerrit).  I've confirmed
 that I can reach other external sites on port 443.

 Can someone give me a hand with this?





 Hello.



 - Can you please post all output from git review -vs?

 - Do you have gerrit remote already configured?

 - Do you have access to https://review.openstack.org/ from your browser?

 - Can you access it from command line (via curl -I
 https://review.openstack.org/; for example)?

 - Does git ls-remote https://review.openstack.org/openstack/nova 
 /dev/null produce and error?

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:

[openstack-dev] [nova] File injection, config drive and cloud-init

2015-06-11 Thread Mark Boo

Hello,

I've been doing some research about file injection in VM instances at boot
time, I found[1] that there are several ways of doing it, including
mounting images[2] (using guestfs, loops and nbd), using config drive
(creating a device and making it available to mount it in the instance) and
using the metadata service (cloud-init).

However I also found that file injection was disabled by default in the
Icehouse release[3]:
File injection is now disabled by default in OpenStack Compute. Instead it
is recommended that the ConfigDrive and metadata server facilities are used
to modify guests at launch. To enable file injection modify the inject_key
and inject_partition configuration keys in /etc/nova/nova.conf and restart
the Compute services. The file injection mechanism is likely to be disabled
in a future release.

In addition, the blueprint[4] about this mentions that this could be
deprecated in the future:

With ConfigDrive and Metadata service combined there is no need for
fiddling inside VM images at deployment time - images can consult metadata
locally (configdrive) or network (metadata service).
Disabling it by default is thus sane, and we can review whether to
deprecate and remove it entirely in future.


I've also asked in #openstack-operators (thanks to folks there for pointing
out all this useful information) for the most used way for injecting files
in instances and (IIRC) they said that cloud-init + config drive were the
common methods.

Now my questions are:

- Is this (file injection using image mounting) likely to be deprecated at
some point in the future?
- What functionality is missing (if any) in config drive / metadata service
solutions to completely replace file injection?
- Which of them is the fastest and most secure?

I would appreciate any comment or corrections in my research about this
topic, I'm still learning about Openstack :-)

[1] -
https://kimizhang.wordpress.com/2014/03/18/how-to-inject-filemetassh-keyroot-passworduserdataconfig-drive-to-a-vm-during-nova-boot/
[2] - https://www.berrange.com/posts/2012/11/15/692/
[3] -
https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse#OpenStack_Compute_.28Nova.29
[4] -
https://blueprints.launchpad.net/nova/+spec/disable-file-injection-by-default

--
Simental Magana Marcos
GPG unsigned
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Hi Matthew,

Thanks for your reply, please see inline:

On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
 Hi Emilien,
 
 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.

What kind of problems?
You also could have used forks of modules, applied your patches and done
rebase from time to time when you like.
Using a Puppetfile in your installer and you're all set.
The maintenance problems thing does not sound right to me here, I
think it's more expensive to maintain files than git repositories.

 Secondly, I'd like to point out that Fuel is not so different from
 what other teams are doing. At the Summit, I heard from others who all
 maintain internal Gerrits and internal forks of the modules.

True, and most of people are using forks which is totally fine in term
of authorship respect.

 The difference is that Fuel is being worked on in the open in StackForge.
 Anyone is free to contribute to Fuel as he or she wishes, take our
 patches, or review changesets.

Should not it be the way around?
Puppet OpenStack modules provide the original code. If there is a bug,
it has to be fixed in the modules. Puppet OpenStack developers don't
have time/bandwidth and moreover don't want to periodically have a look
at Fuel git history. I'm not sure this is the best solution for the
community.

 Starting in October 2014, the Fuel team has adopted a policy that we
 cannot merge any patches into the core Puppet OpenStack modules of
 Fuel without submitting a patch or at least a bug upstream. Our
 reviewers block patches consistently. The truth is that the upstream
 modules are quite excellent and we don't need to make changes so
 often. Our goal is to work with upstream modules or in the issue where
 upstream integration is impossible, we place that config in our own
 separate modules.

I'm sure you do respect this policy. The reality (and again I won't
blame any patch, you can find them on Gerrit) is that most of patches
are not merged and in staled status. If I can suggest something, the
policy should be more upstream first where you submit a patch
upstream, you backport it downstream, and in the until it's merged you
should make sure it land upstream after community review process.
The last step is I think the problem I'm mentioning here and part of the
root cause of this topic.

 The point you raised about fixing bugs in Fuel and not in Puppet
 OpenStack is definitely valid and something we need to collaborate on.
 The first and easiest option when a bug is applicable to both, we
 could use Launchpad to assign bugs to both Fuel project and
 puppet-$project so it gains visibility. If a bug is discovered in
 Puppet OpenStack after it's been reported and/or fixed in Fuel, then
 it would be best to ping someone in #fuel-dev on IRC and we can try to
 figure out how to get this applied upstream correctly. Our best
 results come from fixing upstream and I want to make sure that is
 clear.

Again, I'm not sure this is the right direction. The official channel
for Puppet OpenStack modules is #puppet-openstack and this is the place
to be when you're involved in the Puppet OpenStack community.
I would suggest to rewrite this thing in if a bug is discovered in
Puppet OpenStack after it's been reported or fixed in Fuel, then folks
(from both groups) should collaborate on Puppet OpenStack official
channel to fix it upstream.
IMHO, Fuel IRC channel should relate to Fuel specific things.

As a example, RDO has #rdo-puppet talking about Puppet OpenStack
downstream (packstack, etc) things and use #puppet-openstack for
upstream related bugs. I think this is the way to go if we want to
improve our collaboration.

 If you have specific bugs or commits you'd like to discuss, let's work
 them out. I believe I can get the Fuel Library team to agree to do a
 walk through all the open bugs in Puppet OpenStack and see if we have
 any related fixes or bug reports.

Like I already said, I won't share any patch/bug because I don't want to
blame anyone here, this is not the goal. Going thru Launchpad and
Gerrit, you'll easily see what I mean.

At this stage, it's pretty clear we still need more discussion.

 Best Regards,
 Matthew Mosesohn
 
 On Thu, Jun 11, 2015 at

Re: [openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

2015-06-11 Thread Nikhil Manchanda

Hi Thomas:

I just checked and I don't see suds as a requirement for trove.
I don't think it should be a requirement for the trove debian package,
either.

Thanks,
Nikhil


On Thu, Jun 11, 2015 at 3:03 AM, Davanum Srinivas dava...@gmail.com wrote:

 Thomas,

 oslo.vmware (master) moved to suds-jurko for both python2 and python3.
 we deleted references in nova and other places directly to suds and
 rely on transitively loading the suds-jurko specified from
 oslo.vmware. cinder (master) has a reference to suds-jurko as well.

 -- dims

 On Thu, Jun 11, 2015 at 3:26 AM, Thomas Goirand z...@debian.org wrote:
  Hi,
 
  The current maintainer of suds in Debian sent bug reports against all
  packages depending on it. We would like to get rid of suds completely.
 
  See:
 
  https://bugs.debian.org/788080
  https://bugs.debian.org/788081
  https://bugs.debian.org/788083
  https://bugs.debian.org/788085
  https://bugs.debian.org/788088
 
  Affected projects are: cinder, nova, trove, ironic, and finally
 oslo.vmware.
 
  So, are we moving to suds-jurko? Or anything else?
 
  Cheers,
 
  Thomas Goirand (zigo)
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Davanum Srinivas :: https://twitter.com/dims

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova] [oslo] [neutron][cross-project] Split Policy rules into two parts.

I am not able to say whether this works for Nova. Surely works for Neutron
- from a functional perspective at least.

I still don't know however whether this choice is the best way to proceed,
and perhaps you can help me understand better.

Role checks are always expressed through policy.json and can be enforced in
middleware. Does this mean that there is also a centralized policy.json, or
will we keep per-project policy files even for role checks?

Scope checks - ie: application-specific checks - can be enforced in any way
the application developers wish. They can use policy.json, be hardcoded or,
if they wish ask Pythia, the Oracle of Delphi. From an operator
perspective, this means that every project can enforce policies in a
different way. Is this going to be practical and maintainable? I can't
speak for operators, but I would like to understand a bit better what this
implies for them.

Salvatore







On 11 June 2015 at 17:47, Adam Young ayo...@redhat.com wrote:

  Sean had a really good point when he mentioned that the Developers know
 what need to be enforced, and I think this is why he suggested that the
 base policy implementation be in Python code, not the policy JSON DSL.

 The main thrust of the dynamic policy has been to get the role-to-api
 assignment more flexible.  However, there is another side to each policy
 rule; figureing out where the project (nee' tenant) id is in the request;
 is it part of the URL, part of the request body, or in the object returned
 from the database.  This part really should be handled by the developer
 working on the policy rule, and it should not be changed.

 So...what if we say that we split policy into two checks;  a role check,
 and a scope check.  Both checks must pass in order for the user to get
 access to the API.  The Scope check is not going to be dynamic;  once set,
 they will pretty much stay set.   It might be done using the policy.json,
 or done in code, but it will be separate from the role check.


 The Neutron policy checks for things like

 shared: field:networks:shared=True, shared_firewalls:
 field:firewalls:shared=True, shared_firewall_policies:
 field:firewall_policies:shared=True, shared_subnetpools:
 field:subnetpools:shared=True,

 Would be handled by the dev teams later policy check; anything that
 requires actually fetching the object from the database is postponed to
 this stage.


 The role check will come from the policy.json file.  This will allow the
 operator to fine tune how roles are handled.  Any thing else that can be
 explicitly checked based on the token will be fair game, but not API
 specific values;  no database fetch will be performed at this point.  The
 assumption is that this policy check could be generic enough to be
 performed in middleware, and might even be enforced based on the URL
 instead of the pseudo random namespacing we do now.

 Does this suggestion work for Nova?  I think it will make the overall
 policy much easier to maintain in the field.

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Quota enforcement

Aloha!

As you know I pushed spec [1] during the Kilo lifecycle, but given the lazy
procrastinator that I am, I did not manage to complete in time for the
release.

This actually gave me a chance to realise that the spec that I pushed and
had approved did not make a lot of sense. Even worse, there were some false
claims especially when it comes to active-active DB clusters such as mysql
galera.

Thankfully nobody bothered to look at that - possibly because it renders
horribly in HTML - and that spared me a public shaming.

I have been then following a different approach. And a set of patches,
including a devref one [2], if up for review [3]. This hardly completes the
job: more work is required on the testing side, both as unit and functional
tests.

As for the spec, since I honestly would like to spare myself the hassle of
rewriting it, I would kindly ask our glorious drivers team if they're ok
with me submitting a spec in the shorter format approved for Liberty
without going through the RFE process, as the spec is however in the Kilo
backlog.

For testing I wonder what strategy do you advice for implementing
functional tests. I could do some black-box testing and verifying quota
limits are correctly enforced. However, I would also like to go a bit
white-box and also verify that reservation entries are created and removed
as appropriate when a reservation is committed or cancelled.
Finally it would be awesome if I was able to run in the gate functional
tests on multi-worker servers, and inject delays or faults to verify the
systems behaves correctly when it comes to quota enforcement.

Do these kinds of test even make sense? And are they feasible at all? I
doubt we have any framework for injecting anything in neutron code under
test.

Finally, please note I am using DB-level locks rather than non-locking
algorithms for making reservations. I can move to a non-locking algorithm,
Jay proposed one for nova for Kilo, and I can just implement that one, but
first I would like to be convinced with a decent proof (or sort of) that
the extra cost deriving from collision among workers is overshadowed by the
cost for having to handle a write-set certification failure and retry the
operation.

Please advice.

Regards,
Salvatore

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo-backlog/better-quotas.html
[2] https://review.openstack.org/#/c/190798/
[3]
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

2015-06-11 Thread Matt Fischer

We as a community don't do a great job watching bugs, so personally I'd
prefer that fuel developers just push patches, filing a bug too if you
want. (Note: we do need to improve our bug tracking!) However, I don't
think that asking puppet openstack devs to ask in the fuel channel if a
given bug is fixed in fuel is a very sustainable model. I'm not sure of
many projects where the upstream polls downstream to ask whether they've
fixed bugs. Can we come up with a way to collaborate more that everyone
likes? I think there's a lot of value in it for everyone, we all get a
better product out of it.


On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn mmoses...@mirantis.com
wrote:

 Hi Emilien,

 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.


 Secondly, I'd like to point out that Fuel is not so different from
 what other teams are doing. At the Summit, I heard from others who all
 maintain internal Gerrits and internal forks of the modules. The
 difference is that Fuel is being worked on in the open in StackForge.
 Anyone is free to contribute to Fuel as he or she wishes, take our
 patches, or review changesets.



 Starting in October 2014, the Fuel team has adopted a policy that we
 cannot merge any patches into the core Puppet OpenStack modules of
 Fuel without submitting a patch or at least a bug upstream. Our
 reviewers block patches consistently. The truth is that the upstream
 modules are quite excellent and we don't need to make changes so
 often. Our goal is to work with upstream modules or in the issue where
 upstream integration is impossible, we place that config in our own
 separate modules.

 The point you raised about fixing bugs in Fuel and not in Puppet
 OpenStack is definitely valid and something we need to collaborate on.
 The first and easiest option when a bug is applicable to both, we
 could use Launchpad to assign bugs to both Fuel project and
 puppet-$project so it gains visibility. If a bug is discovered in
 Puppet OpenStack after it's been reported and/or fixed in Fuel, then
 it would be best to ping someone in #fuel-dev on IRC and we can try to
 figure out how to get this applied upstream correctly. Our best
 results come from fixing upstream and I want to make sure that is
 clear.

 If you have specific bugs or commits you'd like to discuss, let's work
 them out. I believe I can get the Fuel Library team to agree to do a
 walk through all the open bugs in Puppet OpenStack and see if we have
 any related fixes or bug reports.

 Best Regards,
 Matthew Mosesohn

 On Thu, Jun 11, 2015 at 2:34 PM, Sanjay Upadhyay san...@gmail.com wrote:
  +1 for the thread, I would also like to hear from Mirantis on this.
 
  The Fork on fuel/puppet has been actively seen patching and
 consolidation.It
  seems like parallel effort why not merge it.
 
  regards
  /sanjay
 
  On Thu, Jun 11, 2015 at 9:12 AM, Emilien Macchi emil...@redhat.com
 wrote:
 
  Hi,
 
  Before reading this e-mail, please keep in mind:
 
  * I have a lot of admiration for Fuel and since I'm working on OpenStack
  Installers (at eNovance and now Red Hat), Fuel is something I always
  consider a good product.
  * This e-mail is about Fuel and Puppet, nothing about Mirantis.
  * I'm writing on behalf of my thoughts, and not on our group.
  * I'm using open mailing-list for open discussion. There is not bad
  spirit in this e-mail and I want to have a productive thread.
 
  I have some concerns I would like to share with you and hopefully find
  some solutions together.
 
  Since I've been working on Puppet OpenStack (2 years now), I see some
  situations that happen - according to me - too often:
 
  * A bug is reported in both Fuel Library and the Puppet module having
  trouble. A patch is provided in Fuel Library (your fork of Puppet
  OpenStack modules) but not in Puppet upstream module. That means you fix
  the bug for Fuel, and not for Puppet OpenStack community. It does not
  happen all the time but quite often.
 
  * A patch is submitted in a Puppet module and quite often does not land
  because there is no activity, no tests or is abandonned later because
  fixed in Fuel Library. I've noticed the patch is fixed in Fuel Library
  though.
 
  *

Re: [openstack-dev] Looking for help getting git-review to work over https

On 2015-06-11 19:53:25 + (+), KARR, DAVID wrote:
 Ok, the output from git remote -v is this:
 --
 originhttps://github.com/openstack/horizon.git (fetch)
 originhttps://github.com/openstack/horizon.git (push)
 ---
 
 So there's obviously nothing to remove.  As usual, running git
 review -sv times out on the ssh:29418 request.  Are the
 gitreview.scheme and gitreview.port properties completely
 ignored here?

I don't recall seeing what git-review version you're running, but
keep in mind that HTTPS Gerrit support only really showed up in
git-review 1.24 (the latest release on pypi.python.org) so if you're
running an older version that that it's probably not going to do
what you want here regardless. There are also I think some further
improvements for it in the master Git branch since the last release
(we're long overdue to tag another one) so you might consider giving
that a try too.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

 -Original Message-
 From: Jeremy Stanley [mailto:fu...@yuggoth.org]
 Sent: Thursday, June 11, 2015 1:11 PM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] Looking for help getting git-review to
 work over https

 On 2015-06-11 19:53:25 + (+), KARR, DAVID wrote:
  Ok, the output from git remote -v is this:
  --
  origin  https://github.com/openstack/horizon.git (fetch)
  origin  https://github.com/openstack/horizon.git (push)
  ---

  So there's obviously nothing to remove.  As usual, running git
  review -sv times out on the ssh:29418 request.  Are the
  gitreview.scheme and gitreview.port properties completely
  ignored here?

 I don't recall seeing what git-review version you're running, but
 keep in mind that HTTPS Gerrit support only really showed up in
 git-review 1.24 (the latest release on pypi.python.org) so if
 you're
 running an older version that that it's probably not going to do
 what you want here regardless. There are also I think some further
 improvements for it in the master Git branch since the last release
 (we're long overdue to tag another one) so you might consider
 giving
 that a try too.

I have version 1.24.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git --all
The authenticity of host '[review.openstack.org]:29418 (no hostip for proxy 
command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.namehttp://user.name=David Karr
user.email=dk0...@att.commailto:dk0...@att.com
gitreview.scheme=https
gitreview.port=443

Concerning the question ‘Do you have gerrit remote already configured?’, I 
guess I’d have to say I don’t know. I’ve followed instructions for setting up 
my pub key, but I’m not sure exactly what is entailed in “gerrit remote”.

I can get to https://review.openstack.org/ from my browser and from the command 
line with curl.

The “ls-remote” command returns without error (or any other output).

From: Yuriy Taraday [mailto:yorik@gmail.commailto:yorik@gmail.com]
Sent: Thursday, June 11, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https


On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.commailto:dk0...@att.com 
wrote:

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at 
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but this still isn't 
working (times out with Could not connect to gerrit).  I've confirmed that I 
can reach other external sites on port 443.

Can someone give me a hand with this?





Hello.



- Can you please post all output from git review -vs?

- Do you have gerrit remote already configured?

- Do you have access to https://review.openstack.org/ from your browser?

- Can you access it from command line (via curl -I 
https://review.openstack.org/; for example)?

- Does git ls-remote https://review.openstack.org/openstack/nova  /dev/null 
produce and error?
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

2015-06-11 Thread Armando M.

+1

On 11 June 2015 at 12:42, Carl Baldwin c...@ecbaldwin.net wrote:

 +1

 On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton blak...@gmail.com wrote:
  Hello all!
 
  As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
  Takashi to be a member of the control plane core reviewer team.
 
  He has been extensively reviewing the entire codebase[2] and his
 feedback on
  patches related to the reference implementation has been very useful.
 This
  includes everything ranging from the AMPQ API to OVS flows.
 
  Existing cores that have spent time working on the reference
 implementation
  (agents and AMQP code), please vote +1/-1 for his addition to the team.
  Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been
  reviewing things in these areas recently so I would like to hear from you
  specifically.
 
  1.
 
 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
  2. http://stackalytics.com/report/contribution/neutron-group/90
 
 
  Cheers
  --
  Kevin Benton
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

I see.  I would guess a footnote on the instructions about this would be 
useful. Is https://github.com/openstack-infra/git-review the proper location to 
get the buildable source?  I don’t see any obvious build instructions there.

From: ZZelle [mailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 2:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Hi David,

Following git config options are supported by git-review 
(https://review.openstack.org/116035)
   git config --global gitreview.scheme https
   git config --global gitreview.port 443
BUT the feature was merged after 1.24 (it's highlighted by your git review -vs)
so the feature is currently only available on the git-review master branch 
(which
is quite stable, i use it every day).

Cedric/ZZelle@irc

On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
The authenticity of host 
'[review.openstack.orghttp://review.openstack.org]:29418 (no hostip for 
proxy command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.netmailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.namehttp://user.name=David Karr
user.email=dk0...@att.commailto:dk0...@att.com
gitreview.scheme=https
gitreview.port=443

Concerning the question ‘Do you have gerrit remote already configured?’, I 
guess I’d have to say I don’t know. I’ve followed instructions for setting up 
my pub key, but I’m not sure exactly what is entailed in “gerrit remote”.

I can get to https://review.openstack.org/ from my browser and from the command 
line with curl.

The “ls-remote” command returns without error (or any other output).

From: Yuriy Taraday [mailto:yorik@gmail.commailto:yorik@gmail.com]
Sent: Thursday, June 11, 2015 9:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.commailto:dk0...@att.com 
wrote:

I could use some help with setting up git-review in a slightly unfriendly 
firewall situation.

I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the 
non-standard ssh port.  I'm following the instructions at

Re: [openstack-dev] [puppet] [fuel] more collaboration request

2015-06-11 Thread Alex Schultz

Hey Matt  other OpenStack folks,

I agree that pinging #fuel-dev would not be scalable for every
request. But I think it was more of if someone notices something is
fixed in fuel-library but not in an OpenStack puppet library, then by
all means come and poke someone so we can try and get it in to
upstream if we failed to do so.  As for the inclusion of the OpenStack
puppet modules within fuel-library, I also am not a fan of the way it
is done today, but I'm new here so I can't speak for previous
decisions.  It would be nice if it followed a similar model to how the
OpenStack python libraries are consumed. Leveraging something like
Librarian where we can just increment version numbers or swap out
repositories would be a nice option.  That being said, there's a lot
more tooling that is required in order to get to that and it's hard to
prioritize things like that.  Puppet modules aren't traditionally
packaged via rpms/debs/etc so it's kinda of hard to do that dependency
checking like we do for all the OpenStack services.  I, personally and
I'm sure there are others, would welcome any assistance or ideas on
the best way to do something like that.  I think this is where some
community help would be much appreciated so that we can get to that
point.  I'd be happy to help with trying to push some of these ideas
forward.  I think there are probably others who detest having to
manually pull in module updates every few months and battle test and
merge issues, so anything to make everyones' lives easier would be
welcomed.

Thanks,
-Alex Schultz

On Thu, Jun 11, 2015 at 4:03 PM, Matt Fischer m...@mattfischer.com wrote:
 We as a community don't do a great job watching bugs, so personally I'd
 prefer that fuel developers just push patches, filing a bug too if you want.
 (Note: we do need to improve our bug tracking!) However, I don't think that
 asking puppet openstack devs to ask in the fuel channel if a given bug is
 fixed in fuel is a very sustainable model. I'm not sure of many projects
 where the upstream polls downstream to ask whether they've fixed bugs. Can
 we come up with a way to collaborate more that everyone likes? I think
 there's a lot of value in it for everyone, we all get a better product out
 of it.


 On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn mmoses...@mirantis.com
 wrote:

 Hi Emilien,

 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.


 Secondly, I'd like to point out that Fuel is not so different from
 what other teams are doing. At the Summit, I heard from others who all
 maintain internal Gerrits and internal forks of the modules. The
 difference is that Fuel is being worked on in the open in StackForge.
 Anyone is free to contribute to Fuel as he or she wishes, take our
 patches, or review changesets.



 Starting in October 2014, the Fuel team has adopted a policy that we
 cannot merge any patches into the core Puppet OpenStack modules of
 Fuel without submitting a patch or at least a bug upstream. Our
 reviewers block patches consistently. The truth is that the upstream
 modules are quite excellent and we don't need to make changes so
 often. Our goal is to work with upstream modules or in the issue where
 upstream integration is impossible, we place that config in our own
 separate modules.

 The point you raised about fixing bugs in Fuel and not in Puppet
 OpenStack is definitely valid and something we need to collaborate on.
 The first and easiest option when a bug is applicable to both, we
 could use Launchpad to assign bugs to both Fuel project and
 puppet-$project so it gains visibility. If a bug is discovered in
 Puppet OpenStack after it's been reported and/or fixed in Fuel, then
 it would be best to ping someone in #fuel-dev on IRC and we can try to
 figure out how to get this applied upstream correctly. Our best
 results come from fixing upstream and I want to make sure that is
 clear.

 If you have specific bugs or commits you'd like to discuss, let's work
 them out. I believe I can get the Fuel Library team to agree to do a
 walk through all the open bugs in Puppet OpenStack and see if we have
 any related fixes or bug reports.

 Best Regards,
 Matthew Mosesohn

 On Thu, Jun 11, 2015 at

Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

On 06/12/2015 12:34 AM, Thomas Goirand wrote:
 On 06/10/2015 11:23 PM, Mike Bayer wrote:


 On 6/10/15 5:18 PM, Thomas Goirand wrote:
 On 06/10/2015 04:52 PM, Mike Bayer wrote:
 whew!  :)
 Do you know why it fails with Kilo?

 https://review.openstack.org/#/c/190062/

 I noticed this, I don't know very well how the requirements get
 distributed around but seems like it is not happening here:

 http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/logs/grenade.sh.txt.gz

 pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5 
 (/usr/local/lib/python2.7/dist-packages), 
 Requirement.parse('SQLAlchemy=0.9.99,=0.9.7'), set(['oslo.db']))
 
 Yeah, so we are bitten by over-restricting requirements in oslo.db.
 Nothing which can't be fixed, IMO.
 
 Would it be ok to first fix oslo.db, and then unrestrict in
 global-requirements.txt? Is this the way to go?
 
 I really would love to see this fixed in the Kilo branch, because no
 mater what, SQLAlchemy 1.0.x will be uploaded to Sid, and I'd prefer
 that it doesn't just break hard Kilo which is there...
 
 Cheers,
 
 Thomas Goirand (zigo)

FYI:

https://review.openstack.org/#/c/190848/

(I don't have the CI result as of writing...)

Thomas


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

2015-06-11 Thread Dmitry Borodaenko

First of all, thank you Emilien for bringing this up, and thank you Matt for
confirming our commitment to collaborate with puppet-openstack and other
Puppet modules that Fuel developers consider upstream.

I'd like to add some more concrete examples of what Fuel team has
already done, is doing, and what more we can do to improve our
collaboration with other Puppet developers.

As Matt has pointed out, sharing bugfixes for forked Puppet modules is
already a requirement for all Fuel developers:

https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Fuel_library_for_puppet_manifests

Here are the key bits that are specifically designed to simplify
reconciling of changes between Fuel and its upstream:

1) If you are adding a module that is the work of another project and
is already tracked in separate repo (...) review should also contain the
commit hash from the upstream repo in the commit message. Using this
reference to upstream commit, you can cleanly and automatically isolate
Fuel specific changes to that module into a patch series with two useful 
properties:

   a) You can associate each deviant line with a commit in fuel-library
   repository that would refer to specific LP bug or blueprint and
   otherwise explain the change.

   b) The whole patch series can be cleanly applied on top of the
   specified commit in upstream git. This means you can automatically
   graft a branch made out of the patch series onto upstream git, and
   then use git rebase to make that branch mergeable with the current
   upstream git head.

2) submit patch to upstream module first, and once merged or +2
recieved from a core reviewer, the patch should be backported to Fuel
library as well. Aside from the obvious benefit of immediate
contribution to upstream, this rule helps to keep Fuel specific changes
confined within Fuel-specific modules, and discourages arbitrary
deviations of forked modules from upstream.

It's important to understand that Fuel's How to contribute guide is
not just a set of recommendations for external contributors: it is the
primary definition of the engineering process that all Fuel developers,
within and without Mirantis, are expected to follow. If you come across
a violation of these rules in Fuel, it is a bug, you're more than
welcome to report it Launchpad, and Fuel developers will address it.

I understand that even with these rules in place the process isn't
perfect, even if it were followed flawlessly. If you have ideas on what
else we can tweak to make upstream's life easier, please share, we're
always looking for ways to improve our processes.

I hope you understand that there are some tradeoffs that are not worth
considering. While we can (and do) set aside some time in every release
to reconcile our local changes with upstream, we can't allow any
external factors to affect our ability to meet our own deadlines. For
example, we can and should push all our local changes to upstream, but
we can't hold back a fix for a Critical bug in Fuel until it is found
acceptable by upstream. We can further minimize the delta between our
fork and an upstream module, even eliminate the delta altogether when
possible, but we have to keep a copy of the module in a repository that
we control. We can and should make a more efficient use of the time our
engineers spend interacting with upstream, but only as long as that does
not subtract from the effort we put into Fuel project's priorities.

At the same time, it's important for Fuel developers to understand that
even though Fuel source code is publicly available and tracking and
minimizing deviation from upstream is encoded in our engineering
process, it doesn't mean there's no room for improvement. Saying don't
worry, be happy, we've got it under control, the ball is on your side
is not good enough.

P.S. There's been more emails on the thread while I was writing this,
and some points raised are not covered in this email, I'll try to
address them in another followup.

-- 
Dmitry Borodaenko



On Thu, Jun 11, 2015 at 05:36:57PM +0300, Matthew Mosesohn wrote:
 Hi Emilien,
 
 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.
 
 Secondly, I'd like to point out that Fuel is not

Re: [openstack-dev] Looking for help getting git-review to work over https

This is just going swimmingly.
% sudo python setup.py install
Download error on https://pypi.python.org/simple/pbr/: [Errno 110] Connection 
timed out -- Some packages may not be found!
Couldn't find index page for 'pbr' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno 110] Connection timed 
out -- Some packages may not be found!
No local packages or download links found for pbr

Do I have to do something special to set the proxy for this?  I have 
“http_proxy” and “https_proxy” already set.

From: ZZelle [mailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Indeed, the doc[1] is unclear

git-review can be installed using: python setup.py install or pip install .


[1]http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https

On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I see.  I would guess a footnote on the instructions about this would be 
useful. Is https://github.com/openstack-infra/git-review the proper location to 
get the buildable source?  I don’t see any obvious build instructions there.

From: ZZelle [mailto:zze...@gmail.commailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 2:01 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Hi David,


Following git config options are supported by git-review 
(https://review.openstack.org/116035)
   git config --global gitreview.scheme https
   git config --global gitreview.port 443
BUT the feature was merged after 1.24 (it's highlighted by your git review -vs)
so the feature is currently only available on the git-review master branch 
(which
is quite stable, i use it every day).


Cedric/ZZelle@irc


On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
The authenticity of host 
'[review.openstack.orghttp://review.openstack.org]:29418 (no hostip for 
proxy command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.netmailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.namehttp://user.name=David Karr

[openstack-dev] [neutron] Microversioning work questions and kick-start

As most of you already know, work is beginning to move forward on the
micro-versioned Neutron API, for which a specification is available at [1]

From a practical perspective there is one non-negligible preliminary issue
that needs attention. then Neutron API URI prefix includes the full version
number - currently 2.0. For instance:

 http://neutron_server:9696/v2.0/networks.json

This clearly makes a microversioned approach a bit weird - if you have to
use, for instance, 2.0 as a URI prefix for API version 2.12.
On the one hand it might make sense to start the micro-versioned API as a
sort of clean slate, possibly using a version-agnostic URI prefix or no
prefix at all; also as pointed out by some community members it will give a
chance to validate this versioned API approach.
This will have however the drawback that both the unversioned,
extension-based so-called 2.0 API will keep living and evolving
side-by-side with the versioned API, and then switching to the versioned
API will not be transparent to clients.
It would be good to receive some opinions from the developer and user
community on the topic.

Furthermore, another topic that has been brought up is whether plugins
should be allowed to control the version of the API server, like specifying
minimum and maximum version. My short answer is no, because the plugin
should implement the API, not controlling it. Also, the spec provides a
facility for plugins to disable features if they are unable to support them.

Finally, I received queries from several community members that would be
keen on helping supporting this microversioning effort. I wonder if the PTL
and the API lieutenants would ok with agreeing to have a team of developers
meeting regularly, working towards implementing this feature, and report
progress and/or issues to the general Neutron meeting.

Salvatore

[1] https://review.openstack.org/#/c/136760/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

2015-06-11 Thread Kevin Benton

What gateway address do you give to regular clients via dhcp when you have
multiple?

On Jun 11, 2015 12:29 PM, Shraddha Pandhe spandhe.openst...@gmail.com
wrote:

 Hi,
 Currently, the Subnets in Neutron and Nova-Network only support one
gateway. For provider networks in large data centers, quite often, the
architecture is such a way that multiple gateways are configured per
subnet. These multiple gateways are typically spread across backplanes so
that the production traffic can be load-balanced between backplanes.
 This is just my use case for supporting multiple gateways, but other
folks might have more use cases as well and also want to take the
community's opinion about this feature. Is this something that's going to
help a lot of users?
 I want to open up a discussion on this topic and figure out the best way
to handle this.
 1. Should this be done in a same way as dns-nameserver, with a separate
table with two columns: gateway_ip, subnet_id.
 2. Should Gateway field be converted to a List instead of String?
 I have also opened a bug  for Neutron here:
https://bugs.launchpad.net/neutron/+bug/1464361


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

Making progress.  I didn’t realize I had to reset proxy vars after sudo.

From: KARR, DAVID
Sent: Thursday, June 11, 2015 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

***Security Advisory: This Message Originated Outside of ATT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
This is just going swimmingly.
% sudo python setup.py install
Download error on https://pypi.python.org/simple/pbr/: [Errno 110] Connection 
timed out -- Some packages may not be found!
Couldn't find index page for 'pbr' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno 110] Connection timed 
out -- Some packages may not be found!
No local packages or download links found for pbr

Do I have to do something special to set the proxy for this?  I have 
“http_proxy” and “https_proxy” already set.

From: ZZelle [mailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Indeed, the doc[1] is unclear
git-review can be installed using: python setup.py install or pip install .

[1]http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https

On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I see.  I would guess a footnote on the instructions about this would be 
useful. Is https://github.com/openstack-infra/git-review the proper location to 
get the buildable source?  I don’t see any obvious build instructions there.

From: ZZelle [mailto:zze...@gmail.commailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 2:01 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Hi David,

Following git config options are supported by git-review 
(https://review.openstack.org/116035)
   git config --global gitreview.scheme https
   git config --global gitreview.port 443
BUT the feature was merged after 1.24 (it's highlighted by your git review -vs)
so the feature is currently only available on the git-review master branch 
(which
is quite stable, i use it every day).

Cedric/ZZelle@irc

On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
The authenticity of host 
'[review.openstack.orghttp://review.openstack.org]:29418 (no hostip for 
proxy command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.netmailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run

Re: [openstack-dev] Looking for help getting git-review to work over https

I managed to install pip, but I don’t understand what “pip install git-review” 
is doing.  It doesn’t appear to be replacing the already installed git-review.

From: ZZelle [mailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Indeed, the doc[1] is unclear

git-review can be installed using: python setup.py install or pip install .

[1]http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https

On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I see.  I would guess a footnote on the instructions about this would be 
useful. Is https://github.com/openstack-infra/git-review the proper location to 
get the buildable source?  I don’t see any obvious build instructions there.

From: ZZelle [mailto:zze...@gmail.commailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 2:01 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Hi David,

Following git config options are supported by git-review 
(https://review.openstack.org/116035)
   git config --global gitreview.scheme https
   git config --global gitreview.port 443
BUT the feature was merged after 1.24 (it's highlighted by your git review -vs)
so the feature is currently only available on the git-review master branch 
(which
is quite stable, i use it every day).

Cedric/ZZelle@irc

On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
The authenticity of host 
'[review.openstack.orghttp://review.openstack.org]:29418 (no hostip for 
proxy command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.netmailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:

This output is interesting, because I followed the instructions to set the 
scheme and port to https and 443, which can be seen from:
% git config --global -l
user.namehttp://user.name=David Karr
user.email=dk0...@att.commailto:dk0...@att.com
gitreview.scheme=https
gitreview.port=443

Concerning the question ‘Do you have gerrit remote already configured?’, I 
guess I’d have to say I don’t know. I’ve followed instructions for setting up 
my pub key, but I’m not sure exactly what is entailed in “gerrit remote”.

I can get to https://review.openstack.org/ from my browser

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Hi,

Before you read me, please remember I know almost nothing about puppet. :)

On 06/11/2015 11:03 PM, Matt Fischer wrote:
 We as a community don't do a great job watching bugs, so personally I'd
 prefer that fuel developers just push patches, filing a bug too if you
 want. (Note: we do need to improve our bug tracking!) However, I don't
 think that asking puppet openstack devs to ask in the fuel channel if a
 given bug is fixed in fuel is a very sustainable model. I'm not sure of
 many projects where the upstream polls downstream to ask whether they've
 fixed bugs. Can we come up with a way to collaborate more that everyone
 likes? I think there's a lot of value in it for everyone, we all get a
 better product out of it.
 
 
 On Thu, Jun 11, 2015 at 8:36 AM, Matthew Mosesohn
 The point you raised about fixing bugs in Fuel and not in Puppet
 OpenStack is definitely valid and something we need to collaborate on.
 The first and easiest option when a bug is applicable to both, we
 could use Launchpad to assign bugs to both Fuel project and
 puppet-$project so it gains visibility. If a bug is discovered in
 Puppet OpenStack after it's been reported and/or fixed in Fuel, then
 it would be best to ping someone in #fuel-dev on IRC and we can try to
 figure out how to get this applied upstream correctly. Our best
 results come from fixing upstream and I want to make sure that is
 clear.

Matt,

I appreciate a lot who you are, and all the help you've given me so far,
but what you are asking here is wrong. You shouldn't ask Emilien to
track the work of the Fuel team, and ping them on IRC to contribute
back. It should be up to them to directly fix upstream *first*, and
*then* fix back in Fuel.

 If you have specific bugs or commits you'd like to discuss, let's work
 them out. I believe I can get the Fuel Library team to agree to do a
 walk through all the open bugs in Puppet OpenStack and see if we have
 any related fixes or bug reports.

It shouldn't be the way either. The team working on fuel-library should
be pro-active and doing the contributions, Emilien shouldn't have to
discuss a specific bug of commits. I believe also that Emilien's
reasoning goes beyond just one or 2 commits, it's a general thinking.

On 06/11/2015 04:36 PM, Matthew Mosesohn wrote:
 I can see why you might be unhappy with Fuel's actions with regards to
 the OpenStack Puppet modules. You could make this argument about many
 components in Fuel. The heart of the matter is that we bundle the
 upstream OpenStack Puppet modules with all the other modules,
 developed both upstream and by Fuel's developers in one single git
 repository. This decision, along with all the other decisions to put
 Fuel's components under its own repositories, was intended to add
 stability and granular control to the product. I'm not saying it's the
 most community-oriented approach, but Fuel would have never evolved
 and matured without it. The attribution in commits is lost because our
 directory namespace differs such that it can't just be merged cleanly.
 Revisiting submodules is an option, but it led to maintenance problems
 in the past.

This isn't the only place where we have a huge git repository doing
everything. This IMO is a big mistake, which give us more work because
we have to duplicate what's upstream and constantly rebase. This is yet
another technical dept... This only works because we have a lot of
Mirantis employee doing the work, so the inefficiency is counter
balanced by the work force. But as you know, we're always pushing to the
very limit of everyone to release a new version of MOS and Fuel, so
maybe now is the time to rethink the way we work.

To move forward, I really believe we (as in: Mirantis) should be:
1/ Rework fuel-library to use multiple git for puppet, and maybe work
out a way to package these individually.
2/ Using unmodified version of upstream puppet as much as possible
3/ Work *only* on upstream puppet and not on a separate fork

As a lot of the changes that I propose, this would be a one-off painful
effort to kill this technical dept, but on the long run, we would really
benefits from such reorganization.

If we don't do the above, it's going to be business as usual, no mater
how much efforts Mirantis engineer will put on: the pressure we have to
deliver Fuel/MOS should shift from the fork to what's upstream.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to SQLAlchemy 1.0.x

On 06/10/2015 11:23 PM, Mike Bayer wrote:
 
 
 On 6/10/15 5:18 PM, Thomas Goirand wrote:
 On 06/10/2015 04:52 PM, Mike Bayer wrote:
 whew!  :)
 Do you know why it fails with Kilo?

 https://review.openstack.org/#/c/190062/
 
 I noticed this, I don't know very well how the requirements get
 distributed around but seems like it is not happening here:
 
 http://logs.openstack.org/62/190062/2/check/check-grenade-dsvm/d4597a4/logs/grenade.sh.txt.gz
 
 pkg_resources.ContextualVersionConflict: (SQLAlchemy 1.0.5 
 (/usr/local/lib/python2.7/dist-packages), 
 Requirement.parse('SQLAlchemy=0.9.99,=0.9.7'), set(['oslo.db']))

Yeah, so we are bitten by over-restricting requirements in oslo.db.
Nothing which can't be fixed, IMO.

Would it be ok to first fix oslo.db, and then unrestrict in
global-requirements.txt? Is this the way to go?

I really would love to see this fixed in the Kilo branch, because no
mater what, SQLAlchemy 1.0.x will be uploaded to Sid, and I'd prefer
that it doesn't just break hard Kilo which is there...

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Networking] Support for multiple gateways in neutron/nova-net subnets for provider networks

2015-06-11 Thread Shraddha Pandhe

The idea is to round-robin between gateways by using some sort of mod
operation

So logically it can look something like:

idx = len(gateways) % ip
gateway = gateways[idx]


This is just one idea. I am open to more ideas.




On Thu, Jun 11, 2015 at 3:10 PM, Kevin Benton blak...@gmail.com wrote:

 What gateway address do you give to regular clients via dhcp when you have
 multiple?

 On Jun 11, 2015 12:29 PM, Shraddha Pandhe spandhe.openst...@gmail.com
 wrote:
 
  Hi,
  Currently, the Subnets in Neutron and Nova-Network only support one
 gateway. For provider networks in large data centers, quite often, the
 architecture is such a way that multiple gateways are configured per
 subnet. These multiple gateways are typically spread across backplanes so
 that the production traffic can be load-balanced between backplanes.
  This is just my use case for supporting multiple gateways, but other
 folks might have more use cases as well and also want to take the
 community's opinion about this feature. Is this something that's going to
 help a lot of users?
  I want to open up a discussion on this topic and figure out the best way
 to handle this.
  1. Should this be done in a same way as dns-nameserver, with a separate
 table with two columns: gateway_ip, subnet_id.
  2. Should Gateway field be converted to a List instead of String?
  I have also opened a bug  for Neutron here:
 https://bugs.launchpad.net/neutron/+bug/1464361
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova] [oslo] [neutron][cross-project] Split Policy rules into two parts.

2015-06-11 Thread Adam Young


On 06/11/2015 05:35 PM, Salvatore Orlando wrote:
I am not able to say whether this works for Nova. Surely works for 
Neutron - from a functional perspective at least.


I still don't know however whether this choice is the best way to 
proceed, and perhaps you can help me understand better.


Role checks are always expressed through policy.json and can be 
enforced in middleware. Does this mean that there is also a 
centralized policy.json, or will we keep per-project policy files even 
for role checks?
The focus of the centralized policy has always been the role 
management.  I don't propose changing course on that.  We want the role 
names to be consistant across all the projects.


I see the starting lapproach being that users get one of two roles by 
default;  Administrator or Member.  While these will still be scoped to 
the project, only the role assignment itself would be checked by the 
dynamic policy.  The scope would be checked by static policy.




Scope checks - ie: application-specific checks - can be enforced in 
any way the application developers wish. They can use policy.json, be 
hardcoded or, if they wish ask Pythia, the Oracle of Delphi. From an 
operator perspective, this means that every project can enforce 
policies in a different way. Is this going to be practical and 
maintainable? I can't speak for operators, but I would like to 
understand a bit better what this implies for them.


If the project already has logic doing the policy check using oslo, and 
they want to keep using oslo, they can do so.  Relaly,only Keystone has 
any deep need to do so.  The rules that I saw in Nova were simple enough 
that they could be checked in oslo or with simple python code.  The 
limiting thing here is that the object in the database needs to be 
checked against the scope anyway;  it doesn't matter if the scope on my 
token matches the scope on my roject as specified in the URL, if the 
object fetched back does not belong to that project.  How this check is 
done differes from project to project, it is just essential that the 
check be done.


For a project that is not doing the check, and needs to start doing so, 
it probably makes sense to use oslo.policy.



Thanks for the questions





Salvatore







On 11 June 2015 at 17:47, Adam Young ayo...@redhat.com 
mailto:ayo...@redhat.com wrote:


Sean had a really good point when he mentioned that the Developers
know what need to be enforced, and I think this is why he
suggested that the base policy implementation be in Python code,
not the policy JSON DSL.

The main thrust of the dynamic policy has been to get the
role-to-api assignment more flexible.  However, there is another
side to each policy rule; figureing out where the project (nee'
tenant) id is in the request;  is it part of the URL, part of the
request body, or in the object returned from the database.  This
part really should be handled by the developer working on the
policy rule, and it should not be changed.

So...what if we say that we split policy into two checks; a role
check, and a scope check.  Both checks must pass in order for the
user to get access to the API.  The Scope check is not going to be
dynamic;  once set, they will pretty much stay set.   It might be
done using the policy.json, or done in code, but it will be
separate from the role check.


The Neutron policy checks for things like

|shared: field:networks:shared=True, shared_firewalls:
field:firewalls:shared=True, shared_firewall_policies:
field:firewall_policies:shared=True, shared_subnetpools:
field:subnetpools:shared=True,

Would be handled by the dev teams later policy check; anything
that requires actually fetching the object from the database is
postponed to this stage.
|



The role check will come from the policy.json file.  This will
allow the operator to fine tune how roles are handled.  Any thing
else that can be explicitly checked based on the token will be
fair game, but not API specific values;  no database fetch will be
performed at this point.  The assumption is that this policy check
could be generic enough to be performed in middleware, and might
even be enforced based on the URL instead of the pseudo random
namespacing we do now.

Does this suggestion work for Nova?  I think it will make the
overall policy much easier to maintain in the field.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [nova] File injection, config drive and cloud-init

2015-06-11 Thread Michael Still

Hi!

On Fri, Jun 12, 2015 at 7:07 AM, Mark Boo mrkzm...@gmail.com wrote:

[snip]

 Now my questions are:

 - Is this (file injection using image mounting) likely to be deprecated at
 some point in the future?

Yes, we've been building up to that for a long time and I can't see is
not doing it. Its important because file injection is much harder to
make secure. We've had security vulnerabilities around file injection
in the past, and while I don't know of any at the moment we've decided
its best just to move to the other two mechanisms.

 - What functionality is missing (if any) in config drive / metadata service
 solutions to completely replace file injection?

None that I am aware of. In fact, these two other options provide you
with more data than you'd get with file injection.

 - Which of them is the fastest and most secure?

I don't think there's a speed difference between the two of them --
they both use the same backend to gather the data to expose. That
said, I think config drive is popular because its simple -- everyone
knows how to use a local disks.

Cheers,
Michael

-- 
Rackspace Australia

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https

2015-06-11 Thread ZZelle

Indeed, the doc[1] is unclear


git-review can be installed using: python setup.py install or pip install .


[1]
http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https

On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID dk0...@att.com wrote:

  I see.  I would guess a footnote on the instructions about this would be
 useful. Is https://github.com/openstack-infra/git-review the proper
 location to get the buildable source?  I don’t see any obvious build
 instructions there.



 *From:* ZZelle [mailto:zze...@gmail.com]
 *Sent:* Thursday, June 11, 2015 2:01 PM

 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Looking for help getting git-review to
 work over https



 Hi David,


 Following git config options are supported by git-review (
 https://review.openstack.org/116035)

git config --global gitreview.scheme https
git config --global gitreview.port 443

 BUT the feature was merged after 1.24 (it's highlighted by your git review
 -vs)
 so the feature is currently only available on the git-review master branch
 (which

 is quite stable, i use it every day).





 Cedric/ZZelle@irc





 On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID dk0...@att.com wrote:

   I followed the instructions for installing and configuring corkscrew,
 similar to what you provided here.  The result seems to indicate it did
 something, but the overall result is the same:

 2015-06-11 13:07:25.866568 Running: git log --color=never --oneline
 HEAD^1..HEAD

 2015-06-11 13:07:25.869309 Running: git remote

 2015-06-11 13:07:25.872742 Running: git config --get gitreview.username

 No remote set, testing ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git

 2015-06-11 13:07:25.874869 Running: git push --dry-run ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git --all

 The authenticity of host '[review.openstack.org]:29418 (no hostip for
 proxy command)' can't be established.

 RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.

 Are you sure you want to continue connecting (yes/no)? yes

 ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not
 work.

 Could not connect to gerrit.

 Enter your gerrit username:

 ---



 *From:* Paul Michali [mailto:p...@michali.net]
 *Sent:* Thursday, June 11, 2015 11:09 AM


 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Looking for help getting git-review to
 work over https



 Do you know if you have SSH access to the outside world through the
 firewall?



 Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing,
 created a .ssh/config file with:



 Host review.openstack.org

 ProxyCommand corkscrew proxy-host 80 %h %p



 The proxy host is one that allows HTTP/HTTPS to outside world and
 corkscrew tunnels the SSH through to port 80.



 HTHs,



 PCM



 On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID dk0...@att.com wrote:

   Thanks for replying.



 % git review -vs

 2015-06-11 09:30:38.396076 Running: git log --color=never --oneline
 HEAD^1..HEAD

 2015-06-11 09:30:38.399021 Running: git remote

 2015-06-11 09:30:38.401033 Running: git config --get gitreview.username

 No remote set, testing ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git

 2015-06-11 09:30:38.402988 Running: git push --dry-run ssh://
 dk0...@review.openstack.org:29418/openstack/horizon.git --all

 ssh://dk0...@review.openstack.org:29418/openstack/horizon.git did not
 work.

 Could not connect to gerrit.

 Enter your gerrit username:



 This output is interesting, because I followed the instructions to set the
 scheme and port to https and 443, which can be seen from:

 % git config --global -l

 user.name=David Karr

 user.email=dk0...@att.com

 gitreview.scheme=https

 gitreview.port=443



 Concerning the question ‘Do you have gerrit remote already configured?’,
 I guess I’d have to say I don’t know. I’ve followed instructions for
 setting up my pub key, but I’m not sure exactly what is entailed in “gerrit
 remote”.



 I can get to https://review.openstack.org/ from my browser and from the
 command line with curl.



 The “ls-remote” command returns without error (or any other output).



 *From:* Yuriy Taraday [mailto:yorik@gmail.com]
 *Sent:* Thursday, June 11, 2015 9:19 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] Looking for help getting git-review to
 work over https



 On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.com wrote:

 I could use some help with setting up git-review in a slightly unfriendly
 firewall situation.

 I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks
 the non-standard ssh port.  I'm following the instructions at
 http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https
 , for configuring git-review to use https on port 443, but

Re: [openstack-dev] Looking for help getting git-review to work over https

2015-06-11 Thread Asselin, Ramy

Try creating/updated ~/.pip/pip.conf

With contents:

[global]
proxy = http://your_proxy:port/

From: KARR, DAVID [mailto:dk0...@att.com]
Sent: Thursday, June 11, 2015 4:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

This is just going swimmingly.
% sudo python setup.py install
Download error on https://pypi.python.org/simple/pbr/: [Errno 110] Connection 
timed out -- Some packages may not be found!
Couldn't find index page for 'pbr' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno 110] Connection timed 
out -- Some packages may not be found!
No local packages or download links found for pbr

Do I have to do something special to set the proxy for this?  I have 
“http_proxy” and “https_proxy” already set.

From: ZZelle [mailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 3:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Indeed, the doc[1] is unclear
git-review can be installed using: python setup.py install or pip install .

[1]http://docs.openstack.org/infra/manual/developers.html#accessing-gerrit-over-https

On Thu, Jun 11, 2015 at 11:16 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I see.  I would guess a footnote on the instructions about this would be 
useful. Is https://github.com/openstack-infra/git-review the proper location to 
get the buildable source?  I don’t see any obvious build instructions there.

From: ZZelle [mailto:zze...@gmail.commailto:zze...@gmail.com]
Sent: Thursday, June 11, 2015 2:01 PM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Hi David,

Following git config options are supported by git-review 
(https://review.openstack.org/116035)
   git config --global gitreview.scheme https
   git config --global gitreview.port 443
BUT the feature was merged after 1.24 (it's highlighted by your git review -vs)
so the feature is currently only available on the git-review master branch 
(which
is quite stable, i use it every day).

Cedric/ZZelle@irc

On Thu, Jun 11, 2015 at 10:14 PM, KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
I followed the instructions for installing and configuring corkscrew, similar 
to what you provided here.  The result seems to indicate it did something, but 
the overall result is the same:
2015-06-11 13:07:25.866568 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 13:07:25.869309 Running: git remote
2015-06-11 13:07:25.872742 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 13:07:25.874869 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all
The authenticity of host 
'[review.openstack.orghttp://review.openstack.org]:29418 (no hostip for 
proxy command)' can't be established.
RSA key fingerprint is 28:c6:42:b7:44:d2:48:64:c1:3f:31:d8:1b:6e:3b:63.
Are you sure you want to continue connecting (yes/no)? yes
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 did not work.
Could not connect to gerrit.
Enter your gerrit username:
---

From: Paul Michali [mailto:p...@michali.netmailto:p...@michali.net]
Sent: Thursday, June 11, 2015 11:09 AM

To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Looking for help getting git-review to work over 
https

Do you know if you have SSH access to the outside world through the firewall?

Did you setup a proxy? I setup 'corkscrew' under Ubuntu. After installing, 
created a .ssh/config file with:

Host review.openstack.orghttp://review.openstack.org
ProxyCommand corkscrew proxy-host 80 %h %p

The proxy host is one that allows HTTP/HTTPS to outside world and corkscrew 
tunnels the SSH through to port 80.

HTHs,

PCM

On Thu, Jun 11, 2015 at 12:44 PM KARR, DAVID 
dk0...@att.commailto:dk0...@att.com wrote:
Thanks for replying.

% git review -vs
2015-06-11 09:30:38.396076 Running: git log --color=never --oneline HEAD^1..HEAD
2015-06-11 09:30:38.399021 Running: git remote
2015-06-11 09:30:38.401033 Running: git config --get gitreview.username
No remote set, testing 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
2015-06-11 09:30:38.402988 Running: git push --dry-run 
ssh://dk0...@review.openstack.org:29418/openstack/horizon.githttp://dk0...@review.openstack.org:29418/openstack/horizon.git
 --all

Re: [openstack-dev] [cinder] Rebranded Volume Drivers

2015-06-11 Thread Nikesh Kumar Mahalka

Hi,
We now have a working CI on below patches:
https://review.openstack.org/#/c/187707/
https://review.openstack.org/#/c/187853/

@jgriffith: we will sure start to give back to community.Thanks for
pointing this out.

Regards
Nikesh

On Thu, Jun 4, 2015 at 1:46 PM, Alex Meade mr.alex.me...@gmail.com wrote:

 Agreed, I'd also like to mention that rebranded arrays may differ slightly
 in functionality as well so the CIs would need to run against a physical
 rebranded device. These differences also justify the need for letting
 rebranded drivers in.

 -Alex

 On Thu, Jun 4, 2015 at 4:41 PM, Mike Perez thin...@gmail.com wrote:

 Sounds like the community would like CI's regardless, and I agree.

 Just because the driver code works for one backend solution, doesn't
 mean it's going to work with some other.

 Lets continue with code reviews with these patches only if they have a
 CI reporting, unless someone has a compelling reason we should not let
 any rebranded drivers in.

 --
 Mike Perez


 On Wed, Jun 3, 2015 at 10:32 AM, Mike Perez thin...@gmail.com wrote:
  There are a couple of cases [1][2] I'm seeing where new Cinder volume
  drivers for Liberty are rebranding other volume drivers. This involves
  inheriting off another volume driver's class(es) and providing some
  config options to set the backend name, etc.
 
  Two problems:
 
  1) There is a thought of no CI [3] is needed, since you're using
  another vendor's driver code which does have a CI.
 
  2) IMO another way of satisfying a check mark of being OpenStack
  supported and disappearing from the community.
 
  What gain does OpenStack get from these kind of drivers?
 
  Discuss.
 
  [1] - https://review.openstack.org/#/c/187853/
  [2] - https://review.openstack.org/#/c/187707/4
  [3] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
 
  --
  Mike Perez

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-11 Thread Rochelle Grober

Just want to add that for logging purposes, consistency, as Devananda explains 
and Adrian and Sean agree, is really important. The number of fields in a 
header response should be consistent.  If the field is not always used, a 
placeholder should be put in (usually a “-“ in logs).  Makes parsing these 
things much easier.

Thanks for both consistency and for specific instance related info in the 
message bodies.  The operators also appreciate this.

--Rocky

From: Xu, Hejie [mailto:hejie...@intel.com]
Sent: Thursday, June 11, 2015 02:10
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion 
guideline in API-WG

Salvatore, thanks for the info, will try to review as soon as possible. Hope we 
get consistent implementation.

From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, June 10, 2015 4:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion 
guideline in API-WG

As a further data point, Neutron has been trying to introduce microversioning 
for a while, without success so far.

Given the sheer amount of backends the management layer integrates with, and 
the constant need for the various subteams to experiment with the API, the 
proposal [1] has probably some differences with the proposed guideline.

Since the proposal is not yet approved nor implemented, perhaps it would be 
worth looking at those differences, and get your advice on whether it might be 
better if neutron adheres to the current guideline proposal or whether it might 
be the case to include Neutron's requirements in the current guideline proposal.

Salvatore

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

On 10 June 2015 at 06:28, Xu, Hejie 
hejie...@intel.commailto:hejie...@intel.com wrote:
I updated the Microversion specification in API-WG 
https://review.openstack.org/187112

The new patchset adds min/max version headers as Ironic used:
X-Openstack-[PROJECT]-API-Minimum-Version
X-Openstack-[PROJECT]-API-Maximum-Version

And new response body for invalid version request.

  {
versionFault: {
  max_version: 5.2,
  min_version: 2.1,
  description: Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2.
}
  }

Which for backward compatible can add the existed fields in the response also. 
For example, the nova response is

  {
versionFault: {
  max_version: 5.2,
  min_version: 2.1,
  description: Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2.
},
computeFault: {
  message: Version 5.3 is not supported by the API. \
  Minimum is 2.1 and maximum is 5.2.,
  code: 406
}
  }

The “computeFault” fields is included by current implementation, we can still 
add here, hope deprecated in the future.

And the “experimental” flag in the X-OpenStack-Nova-API-Version header was 
deleted. It mentioned in the nova-spec but
It didn’t implement. And I didn’t saw the same thing in the ironic. For current 
all the things satisfied all the cases. If we
“experimental” flag still usefull, we can propose separately.

Thanks
Alex

From: Devananda van der Veen 
[mailto:devananda@gmail.commailto:devananda@gmail.com]
Sent: Monday, June 8, 2015 1:59 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion 
guideline in API-WG



On Jun 5, 2015 4:36 AM, Sean Dague s...@dague.netmailto:s...@dague.net 
wrote:

 On 06/05/2015 01:28 AM, Adrian Otto wrote:
 
  On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
  devananda@gmail.commailto:devananda@gmail.com 
  mailto:devananda@gmail.commailto:devananda@gmail.com wrote:
 
 
  On Jun 4, 2015 12:00 AM, Xu, Hejie 
  hejie...@intel.commailto:hejie...@intel.com
  mailto:hejie...@intel.commailto:hejie...@intel.com wrote:
  
   Hi, guys,
  
   I’m working on adding Microversion into the API-WG’s guideline which
  make sure we have consistent Microversion behavior in the API for user.
   The Nova and Ironic already have Microversion implementation, and as
  I know Magnum https://review.openstack.org/#/c/184975/ is going to
  implement Microversion also.
  
   Hope all the projects which support( or plan to) Microversion can
  join the review of guideline.
  
   The Mircoversion specification(this almost copy from nova-specs):
  https://review.openstack.org/#/c/187112
   And another guideline for when we should bump Mircoversion
  https://review.openstack.org/#/c/187896/
  
   As I know, there already have a little different between Nova and
  Ironic’s implementation. Ironic return min/max version when the requested
   version doesn’t support in server by http-headers. There isn’t such
  thing in nova. But that is something for version negotiation we need
  for nova also.
   Sean have pointed out we should use response body instead

[openstack-dev] [puppet] [Swift] Multiple proxy recipes will create out of sync rings

2015-06-11 Thread Mark Kirkwood


I've looking at using puppet-swift to deploy a swift cluster.

Firstly - without 
http://git.openstack.org/cgit/stackforge/puppet-swift/tree/tests/site.pp 
I would have struggled a great deal more to get up and running, so a big 
thank you for a nice worked example of how to do multiple nodes!


However I have stumbled upon a problem - with respect to creating 
multiple proxy nodes. There are some recipes around that follow on from 
the site.pp above and explicitly build 1 proxy (e.g 
https://github.com/CiscoSystems/puppet-openstack-ha/blob/folsom_ha/examples/swift-nodes.pp)


Now the problem is - each proxy node does a ring builder create, so ends 
up with *different* builder (and therefore) ring files. This is not 
good, as the end result is a cluster with all storage nodes and *one* 
proxy with the same set of ring files, and *all* other proxies with 
*different* ring (and builder) files.


I have used logic similar to the attached to work around this, i.e only 
create rings if we are the 'ring server', otherwise get 'em via rsync.


Thoughts?

Regards

Mark
  # create the ring if we are the ring server
  if $ipaddress_eth0 == ringserver_local_net_ip {
class { 'swift::ringbuilder':
  # the part power should be determined by assuming 100 partitions per drive
  part_power = '18'
  replicas   = '2'
  min_part_hours = 1
  require= Class['swift'],
}

# sets up an rsync db that can be used to sync the ring DB
class { 'swift::ringserver':
  local_net_ip = $ipaddress_eth0,
}

# exports rsync gets that can be used to sync the ring files
@@swift::ringsync { ['account', 'object', 'container']:
  ring_server = $ipaddress_eth0,
}
  } else {
# collect resources for synchronizing the ring databases
Swift::Ringsync||
  }

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Issue with pymysql

It is however interesting that both lock wait timeouts and missing
savepoint errors occur in operations pertaining the same table -
securitygroups in this case.
I wonder if the switch to pymysl has not actually uncovered some other bug
in Neutron.

I have no opposition to a revert, but since this will affect most projects,
it's probably worth finding some time to investigate what is triggering
this failure when sqlalchemy is backed by pymysql before doing that.

Salvatore

On 12 June 2015 at 03:32, Eugene Nikanorov enikano...@mirantis.com wrote:

 Hi neutrons,

 I'd like to draw your attention to an issue discovered by rally gate job:

 http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE

 I don't have bandwidth to take a deep look at it, but first impression is
 that it is some issue with nested transaction support either on sqlalchemy
 or pymysql side.
 Also, besides errors with nested transactions, there are a lot of Lock
 wait timeouts.

 I think it makes sense to start with reverting the patch that moves to
 pymysql.

 Thanks,
 Eugene.


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team

2015-06-11 Thread Akihiro Motoki

+1

2015-06-11 23:34 GMT+09:00 Henry Gessau ges...@cisco.com:

 As one of the Lieutenants [1] for the API and DB areas under the PTL, I
 would
 like to propose Ann Kamyshnikova as a member of the Neutron API and DB core
 reviewer team.

 Ann has been a long time contributor in Neutron showing expertise
 particularly
 in database matters. She has also worked with and contributed code to the
 oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor to
 the
 Neutron database healing effort that was completed in the Juno cycle.

 Her deep knowledge of databases and backends, and her expertise with
 oslo.db,
 sqlalchemy and alembic will be very important in this area. Ann is a
 trusted
 member of our community and her review stats [2][3][4] place her
 comfortably
 with other Neutron core reviewers. She consistently catches database issues
 early when patches are submitted for review, and shows dedication to
 helping
 developers understand and perfect their database-related changes.

 Existing Neutron core reviewers from the API and DB area of focus, please
 vote
 +1/-1 for the addition of Ann to the core reviewer team. Specifically, I'm
 looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and
 Carl.


 [1]

 http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
 [2]

 https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
 [3] http://stackalytics.com/report/contribution/neutron-group/90
 [4] http://stackalytics.com/?user_id=akamyshnikovametric=marks




 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cloudpulse] Reminder: Team meeting June 11

2015-06-11 Thread Vinod Pandarinathan (vpandari)

Hi,

Meeting: Thursday at 1600 
UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=16min=00sec=0 
in #openstack-meeting-3
Agenda:  https://wiki.openstack.org/wiki/Meetings/cloudpulse

Thanks
Vinod.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Can not connect to host review.openstack.orgport 29418

2015-06-11 Thread changzhi

Thx for your help. I resolve this problem by change gerrit url. Command like 
this:
git remote set-url gerrit 
https://changzhi:gT1w.openstack.org/stackforge/tacker

-- Original --
From:  Tom Fifieldt...@openstack.org;
Date:  Thu, Jun 11, 2015 11:56 AM
To:  openstack-devopenstack-dev@lists.openstack.org; 

Subject:  Re: [openstack-dev] Can not connect to host review.openstack.orgport 
29418

On 11/06/15 11:33, 苌智 wrote:
 I met problem when run git review. It says that  ssh: connect to host
 review.openstack.org port 29418: No route to host . There is no
 response when I run telnet review.openstack.org 29418. And my screen
 only displays Trying 104.130.159.134 Does anyone meets the same
 problem as me? 

Still working for me.

Based on greatfire.org, it currently appears to be blocked by China
country-level firewall.

In this case, changing access from SSH to HTTPS could help avoid the
block, like in Clark's email:

http://lists.openstack.org/pipermail/openstack-dev/2014-September/045385.html

Regards,

Tom

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Global Requirements] Adding apscheduler to global requirements

2015-06-11 Thread BORTMAN, Limor (Limor)

Hi all
can anybody please take a look on my PR[1]?

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

Thanks Limor

-Original Message-
From: BORTMAN, Limor (Limor) [mailto:limor.bort...@alcatel-lucent.com] 
Sent: Wednesday, June 03, 2015 2:28 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Global Requirements] Adding apscheduler to global 
requirements

From: Renat Akhmerov rakhme...@mirantis.com
Subject: Re: [openstack-dev] [Global Requirements] Adding apscheduler to global 
requirements
Date: 3 Jun 2015 16:48:08 GMT+6
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org

Thanks Doug, got it.

Limor, can you please explain why exactly do you need this library?
This is the only live library I found that enable creating scheduled job in 
seconds granularity.
I am planning on using : BackgroundScheduler 
(apscheduler.schedulers.background).
Doug, Does Oslo have this ability?

Renat Akhmerov
@ Mirantis Inc.



On 02 Jun 2015, at 18:45, Doug Hellmann d...@doughellmann.com wrote:

Excerpts from Renat Akhmerov's message of 2015-06-02 18:26:40 +0600:

Any comments from TC on that? What is the typical procedure of accepting new 
libs into global requirements?

There is a requirements management team, and usually we would want a patch to 
the list in openstack/requirements, with some description of the need for the 
package, especially which projects are going to use it and why no existing 
package with similar functionality is suitable. There are more details about 
the evaluation criteria in 
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst

Doug



Thanks

Renat Akhmerov
@ Mirantis Inc.


On 02 Jun 2015, at 18:11, BORTMAN, Limor (Limor) 
limor.bort...@alcatel-lucent.com wrote:

Hi all,
As part as a BP in mistral (Add seconds granularity in cron-trigger execute[1]) 
I would like to add apscheduler (Advanced Python Scheduler[2]) to the openstack 
Global Requirements.

Any objections?

[1] 
https://blueprints.launchpad.net/mistral/+spec/cron-trigger-seconds-granularity
[2] https://apscheduler.readthedocs.org/en/latest/


Thanks Stotland Limor 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Getting rid of suds, which is unmaintained, and which we want out of Debian

Hi,

The current maintainer of suds in Debian sent bug reports against all
packages depending on it. We would like to get rid of suds completely.

See:

https://bugs.debian.org/788080
https://bugs.debian.org/788081
https://bugs.debian.org/788083
https://bugs.debian.org/788085
https://bugs.debian.org/788088

Affected projects are: cinder, nova, trove, ironic, and finally oslo.vmware.

So, are we moving to suds-jurko? Or anything else?

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Adopt mox3

2015-06-11 Thread Jordan Pittier

Hi,
Shouldn't we move to use mock instead ? If mox3 is supported and active,
why would we recommend to use mock ?

Jordan

On Wed, Jun 10, 2015 at 10:17 PM, Davanum Srinivas dava...@gmail.com
wrote:

 Oslo folks, everyone,

 mox3 needs to be maintained since some of our projects use it and we
 have it in our global requirements.

 Here's the proposal from Doug - https://review.openstack.org/#/c/190330/

 Any objections? Please chime in here or on the review.

 thanks,
 dims

 --
 Davanum Srinivas :: https://twitter.com/dims

 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Senlin] Project weekly meeting starts June 16 UTC1300

2015-06-11 Thread Haiwei Xu

Glad to see the schedule is determined. +1 for it.

Regards,
Xuhaiwei

-Original Message-
From: Qiming Teng [mailto:teng...@linux.vnet.ibm.com] 
Sent: Thursday, June 11, 2015 1:12 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Senlin] Project weekly meeting starts June 16 UTC1300

Hi, all,

After some discussions with Senlin developers on the #senlin IRC channel, we 
have decided to hold a weekly IRC meeting for contributors to sync up progress 
and plans. Everyone is welcomed to join the team.

Frequency: Weekly
Weekday: Tuesday
Timeslot: 1300 UTC
Venue: #openstack-meeting

Please feel free to add topics before or at the beginning of the meetings.

Regards,
 Qiming

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [opnfv-tech-discuss] [Tricircle] Polling for weekly team meeting

2015-06-11 Thread Zhipeng Huang

Last reminder, if you are interested, take the poll :)

On Mon, Jun 8, 2015 at 9:45 PM, Zhipeng Huang zhipengh...@gmail.com wrote:

 Hi Iben , if u are interestEd dont forget to participate the time pool :)
 On Jun 5, 2015 11:03 PM, Rodriguez, Iben iben.rodrig...@spirent.com
 wrote:

  Hello Joe,

 This is very cool. A few questions...

 Tricircle seems to deal mostly with the use of many environments and not
 their setup or configuration, is that right?

 We have a few multi-site projects already like pharos and IPv6. Can we
 make an assessment to understand where each one fits in the workflow of the
 platform lifecycle?

 Do the underclouds need to be similar for tricycle to function properly?
 What if some openstack are different from others? Are we just looking for
 api compatability or will certain features or functions also be needed?

 Many thanks for sharing this project. It is good to understand the
 concepts.

 I b e n
 4087824726

 From: Zhipeng Huang
 Sent: Friday, June 5, 07:44
 Subject: [opnfv-tech-discuss] [openstack-dev][Tricircle] Polling for
 weeklyteam meeting
 To: OpenStack Development Mailing List (not for usage questions)
 Cc: opnfv-tech-disc...@lists.opnfv.org

 Hi All,

 The Tricircle Project has been on stackforge for a while, and without
 much activities.

 Now we will completely restructure the code base to make it more
 community open source friendly, less corporate PoC looking hopefully :P

 At the mean time I want to call for attention for people who are
 interested in this project, to participate in a time poll for our weekly
 meeting:

 http://doodle.com/d7fvmgvrwv8y3bqv

 I would recommend UTC 13:00 coz it is the only few time period when all
 the continent are able to be awake (tougher on US tho).

 Please find more info on Tricircle at
 https://github.com/stackforge/tricircle (new code base would come in the
 next few weeks). It mainly aim to solve OpenStack deployment acorss
 multiple sites.

 Also depending on OPNFV Multisite Project's decision, Tricircle might be
 one of the upstream projects of Multisite, which aims at developing
 requirements for NFV multi-NFVI-PoPs VIM deployment. More info :
 https://wiki.opnfv.org/multisite  https://www.opnfv.org/arno

 --

 Zhipeng (Howard) Huang

 Standard Engineer

 IT Standard  Patent/IT Prooduct Line

 Huawei Technologies Co,. Ltd

 Email: huangzhip...@huawei.com

 Office: Huawei Industrial Base, Longgang, Shenzhen

 (Previous)

 Research Assistant

 Mobile Ad-Hoc Network Lab, Calit2

 University of California, Irvine

 Email: zhipe...@uci.edu

 Office: Calit2 Building Room 2402

 OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado

  Spirent Communications e-mail confidentiality.
 
 This e-mail contains confidential and / or privileged information
 belonging to Spirent Communications plc, its affiliates and / or
 subsidiaries. If you are not the intended recipient, you are hereby
 notified that any disclosure, copying, distribution and / or the taking of
 any action based upon reliance on the contents of this transmission is
 strictly forbidden. If you have received this message in error please
 notify the sender by return e-mail and delete it from your system.

 Spirent Communications plc
 Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
 Kingdom.
 Tel No. +44 (0) 1293 767676
 Fax No. +44 (0) 1293 767677

 Registered in England Number 470893
 Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
 9XN, United Kingdom.

 Or if within the US,

 Spirent Communications,
 27349 Agoura Road, Calabasas, CA, 91301, USA.
 Tel No. 1-818-676- 2300




-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard  Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] File injection, config drive and cloud-init

2015-06-11 Thread Ian Wells

On 11 June 2015 at 15:34, Michael Still mi...@stillhq.com wrote:

 On Fri, Jun 12, 2015 at 7:07 AM, Mark Boo mrkzm...@gmail.com wrote:
  - What functionality is missing (if any) in config drive / metadata
 service
  solutions to completely replace file injection?

 None that I am aware of. In fact, these two other options provide you
 with more data than you'd get with file injection.


A config drive is useful if and only if you know to read it and have
software that does so (for packaged Linux, you install the cloud-init
package, usually).  File injection works even if you don't adapt your VM
image.

Conversely, file injection only works on a limited range of disk formats.
-- 
Ian.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Should we add instance action event to live migration?

2015-06-11 Thread Ian Wells

On 11 June 2015 at 12:37, Richard Raseley rich...@raseley.com wrote:

 Andrew Laski wrote:

 There are many reasons a deployer may want to live-migrate instances
 around: capacity planning, security patching, noisy neighbors, host
 maintenance, etc... and I just don't think the user needs to know or
 care that it has taken place.


 They might care, insofar as live migrations will often cause performance
 degradation from a users perspective.


Seconded.  If your app manager is warned that you're going to be live
migrating it can do something about the capacity drop.  I can imagine cases
where a migrating VM would be brutally murdered [1] and replaced because
it's not delivering sufficient performance.
-- 
Ian.

[1] See nova help brutally-murder
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

2015-06-11 Thread Dmitry Borodaenko

On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote:
 On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
  I'm not saying it's the most community-oriented approach, but Fuel
  would have never evolved and matured without it. The attribution in
  commits is lost because our directory namespace differs such that it
  can't just be merged cleanly. Revisiting submodules is an option,
  but it led to maintenance problems in the past.
 What kind of problems?

It was before I got involved with Fuel, but I can offer a guess.
Managing submodules introduces operational overhead and with it more
opportunities for failures and mishaps than a single flat git repo.

Flat repo makes it more difficult to reconcile with upstream modules,
but, when using the process I have described in my previous email to
this thread, not as difficult as one could think. We also reconcile an
average module with upstream much less frequently (no more than once per
Fuel release) than we make commits to that module (many times per
release), which also tilts the overhead balance if favor of using a flat
repo.

 You also could have used forks of modules, applied your patches and done
 rebase from time to time when you like.
 Using a Puppetfile in your installer and you're all set.

We do the apply patches and rebase from time to time part in a single
repo, operating on a subdirectly within it doesn't actually add any
overhead to this part of the workflow, as long as we keep track of sync
commits properly.

 The maintenance problems thing does not sound right to me here, I
 think it's more expensive to maintain files than git repositories.

To sum up, I don't think the difference is that great, or impact of
doing it one way or the other that important. The current layout works
well enough for Fuel team, and as you said yourself, developers of
upstream modules are not likely to pro-actively harvest Fuel for
bugfixes even if we change our repository structure.

  The difference is that Fuel is being worked on in the open in
  StackForge. Anyone is free to contribute to Fuel as he or she
  wishes, take our patches, or review changesets.
 Should not it be the way around?
 Puppet OpenStack modules provide the original code. If there is a bug,
 it has to be fixed in the modules. Puppet OpenStack developers don't
 have time/bandwidth and moreover don't want to periodically have a
 look at Fuel git history. I'm not sure this is the best solution for
 the community.
(...)
 The reality (and again I won't blame any patch, you can find them on
 Gerrit) is that most of patches are not merged and in staled status.
 If I can suggest something, the policy should be more upstream first
 where you submit a patch upstream, you backport it downstream, and in
 the until it's merged you should make sure it land upstream after
 community review process. The last step is I think the problem I'm
 mentioning here and part of the root cause of this topic.

Yes, this right here is the biggest point of contention in the whole
discussion.

The most problematic implication of what you're asking for is the
additional effort that it would require from Fuel developers. When you
say that Puppet OpenStack developers don't have time to look at Fuel git
history for bugfixes, and then observe that actually Fuel developers do
propose their patches to upstream, but those patches are stalled in the
community review process, this indicates that you don't consider taking
over and landing these patches a priority:

http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority

The fact that you have started this thread means that you actually do
care to get these bugfixes into Puppet OpenStack. If that's true, maybe
you can consider a middleground approach: Fuel team agrees to propose
all our changes to upstream (i.e. do a better job at something we've
already committed to unilaterally), and you help us land the patches we
propose, and take over those that get stalled when the submitter from
Fuel team has moved on to other tasks?

A better alternative would be to make all upstream Puppet OpenStack
directly usable in Fuel, but even if we figure out a way to make that
work, it will take a long journey to get there. On the upstream side,
Fuel core reviewers would have to also be upstream core reviewers, and
Fuel CI would have to be allowed to vote on upstream commits. On Fuel
side, we'd have to complete the reconciliation and modularization of all
our forked modules, and move all Fuel CI to openstack-infra. The
potential benefits for both sides are tremendous, but only after we
essentially merge the two projects. Even if that's achievable, is that
something whole Puppet OpenStack community is interested in?

 Again, I'm not sure this is the right direction. The official channel
 for Puppet OpenStack modules is #puppet-openstack and this is the place
 to be when you're involved in the Puppet OpenStack community.
 I would suggest to rewrite this thing in if a

Re: [openstack-dev] [OpenStack-Infra] Nominating Joshua Hesketh for infra-root

2015-06-11 Thread Joshua Hesketh

Thanks all. I promise to not break things too much!

Cheers,
Josh

On Fri, Jun 12, 2015 at 2:54 AM, James E. Blair cor...@inaugust.com wrote:
 The Infrastructure program has a unique three-tier team structure:
 contributors (that's all of us!), core members (people with +2 ability
 on infra projects in Gerrit) and root members (people with
 administrative access).  Read all about it here:

   http://docs.openstack.org/infra/system-config/project.html#teams

 Joshua has been a valuable member of infra-core for some time, having a
 high degree of familiarity with Zuul and related systems and an
 increasing interest in other operational aspects of the project
 infrastructure.  His eagerness to contribute is presently tempered by
 most of the infra-root team sleeping[1] during large parts of his day.
 I look forward to Joshua being able to approve changes with confidence.

 Joshua, if you are interested, please propose your SSH key to
 system-config, and thanks again for all of your work!

 -Jim
 [1] contrary to widely-held belief, this does happen

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ceilometer] Meter rename discussion

2015-06-11 Thread Zhai, Edwin


All,
I'm writing a BP for meter rename @ https://review.openstack.org/#/c/183419/

Simply speaking, we will translate meter querying API for both input and output 
if ender user specify an known renamed meter.


Gordon has a performance concern to translate the output given possible huge 
number of samples returned. We need a lot of search/replace works.


Do you guys think is it acceptable? Comparing the benefits of meter rename with 
this performance concern, we need trade off here.



Best Rgds,
Edwin

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-Infra] Nominating Joshua Hesketh for infra-root

On 2015-06-12 12:42:11 +1000 (+1000), Joshua Hesketh wrote:
 Thanks all. I promise to not break things too much!

All I ask is that you fix whatever you've broken by the time I wake
up. ;)
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [fuel] more collaboration request

Dmitry, thank you for taking your time. Please read inline:

On 06/11/2015 07:12 PM, Dmitry Borodaenko wrote:
First of all, thank you Emilien for bringing this up, and thank you Matt for
confirming our commitment to collaborate with puppet-openstack and other
Puppet modules that Fuel developers consider upstream.

I'd like to add some more concrete examples of what Fuel team has
already done, is doing, and what more we can do to improve our
collaboration with other Puppet developers.

As Matt has pointed out, sharing bugfixes for forked Puppet modules is
already a requirement for all Fuel developers:

https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Fuel_library_for_puppet_manifests

The documentation is good, and well written.

Here are the key bits that are specifically designed to simplify
reconciling of changes between Fuel and its upstream:

1) If you are adding a module that is the work of another project and
is already tracked in separate repo (...) review should also contain the
commit hash from the upstream repo in the commit message. Using this
reference to upstream commit, you can cleanly and automatically isolate
Fuel specific changes to that module into a patch series with two useful
properties:

a) You can associate each deviant line with a commit in fuel-library
repository that would refer to specific LP bug or blueprint and
otherwise explain the change.

b) The whole patch series can be cleanly applied on top of the
specified commit in upstream git. This means you can automatically
graft a branch made out of the patch series onto upstream git, and
then use git rebase to make that branch mergeable with the current
upstream git head.

I spent some time to read Fuel Library, specially its custom manifests
[1] and I don't see any example of these commits. I'm pretty sure I've
missed them, can you give some example?

[1]
https://github.com/stackforge/fuel-library/commits/master/deployment/puppet/openstack/manifests/

2) submit patch to upstream module first, and once merged or +2
recieved from a core reviewer, the patch should be backported to Fuel
library as well. Aside from the obvious benefit of immediate
contribution to upstream, this rule helps to keep Fuel specific changes
confined within Fuel-specific modules, and discourages arbitrary
deviations of forked modules from upstream.

Please let me show you an example of a bug that has been fixed in Fuel,
but not in upstream (puppet-nova here), *after* the new Fuel policy
(mentioned by Matthew, October 2014).

The bug: https://bugs.launchpad.net/fuel/+bug/1378962
Node Libvirt Unique UUID Not Generated On Deployment

Patch in Fuel, merged released: https://review.openstack.org/#/c/128640/
Patch in puppet-nova, with negative feedback, without any +2 and staled
for October 2014: https://review.openstack.org/#/c/131710

This is an example and again, I don't blame anyone here. I respect
people who did the patches and I'm happy it's fixed in Fuel.

It's important to understand that Fuel's How to contribute guide is
not just a set of recommendations for external contributors: it is the
primary definition of the engineering process that all Fuel developers,
within and without Mirantis, are expected to follow. If you come across
a violation of these rules in Fuel, it is a bug, you're more than
welcome to report it Launchpad, and Fuel developers will address it.

I understand that even with these rules in place the process isn't
perfect, even if it were followed flawlessly. If you have ideas on what
else we can tweak to make upstream's life easier, please share, we're
always looking for ways to improve our processes.

Like puppet-murano?
Someone from Fuel team created first the module in Fuel, 6 months ago
[1] and 3 months later someone from Fuel team created an empty
repository in Stackforge [2]. By the way, Puppet OpenStack community
does not have core permissions on this module and it's own by Murano team.

[1]
https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/murano/
[2] https://review.openstack.org/#/c/155688/

Again another example, where I'm very happy to see the module in Fuel
but nothing in Stackforge leveraged by Puppet OpenStack community.

I hope you understand that there are some tradeoffs that are not worth
considering. While we can (and do) set aside some time in every release
to reconcile our local changes with upstream, we can't allow any
external factors to affect our ability to meet our own deadlines. For
example, we can and should push all our local changes to upstream, but
we can't hold back a fix for a Critical bug in Fuel until it is found
acceptable by upstream. We can further minimize the delta between our
fork and an upstream module, even eliminate the delta altogether when
possible, but we have to keep a copy of the module in a repository that
we control. We can and should make a more efficient use of the time our

Re: [openstack-dev] [puppet] [fuel] more collaboration request



On 06/11/2015 10:31 PM, Dmitry Borodaenko wrote:
 On Thu, Jun 11, 2015 at 05:39:28PM -0400, Emilien Macchi wrote:
 On 06/11/2015 10:36 AM, Matthew Mosesohn wrote:
 I'm not saying it's the most community-oriented approach, but Fuel
 would have never evolved and matured without it. The attribution in
 commits is lost because our directory namespace differs such that it
 can't just be merged cleanly. Revisiting submodules is an option,
 but it led to maintenance problems in the past.
 What kind of problems?
 
 It was before I got involved with Fuel, but I can offer a guess.
 Managing submodules introduces operational overhead and with it more
 opportunities for failures and mishaps than a single flat git repo.
 
 Flat repo makes it more difficult to reconcile with upstream modules,
 but, when using the process I have described in my previous email to
 this thread, not as difficult as one could think. We also reconcile an
 average module with upstream much less frequently (no more than once per
 Fuel release) than we make commits to that module (many times per
 release), which also tilts the overhead balance if favor of using a flat
 repo.

What about code history and respect of commit ownership?
I'm personally wondering if it's fair to copy/paste several thousands of
lines of code from another Open-Source project without asking to the
community or notifying the authors before. I know it's Open-Source and
Apache 2.0 but well... :-)

 You also could have used forks of modules, applied your patches and done
 rebase from time to time when you like.
 Using a Puppetfile in your installer and you're all set.
 
 We do the apply patches and rebase from time to time part in a single
 repo, operating on a subdirectly within it doesn't actually add any
 overhead to this part of the workflow, as long as we keep track of sync
 commits properly.
 
 The maintenance problems thing does not sound right to me here, I
 think it's more expensive to maintain files than git repositories.
 
 To sum up, I don't think the difference is that great, or impact of
 doing it one way or the other that important. The current layout works
 well enough for Fuel team, and as you said yourself, developers of
 upstream modules are not likely to pro-actively harvest Fuel for
 bugfixes even if we change our repository structure.
 
 The difference is that Fuel is being worked on in the open in
 StackForge. Anyone is free to contribute to Fuel as he or she
 wishes, take our patches, or review changesets.
 Should not it be the way around?
 Puppet OpenStack modules provide the original code. If there is a bug,
 it has to be fixed in the modules. Puppet OpenStack developers don't
 have time/bandwidth and moreover don't want to periodically have a
 look at Fuel git history. I'm not sure this is the best solution for
 the community.
 (...)
 The reality (and again I won't blame any patch, you can find them on
 Gerrit) is that most of patches are not merged and in staled status.
 If I can suggest something, the policy should be more upstream first
 where you submit a patch upstream, you backport it downstream, and in
 the until it's merged you should make sure it land upstream after
 community review process. The last step is I think the problem I'm
 mentioning here and part of the root cause of this topic.
 
 Yes, this right here is the biggest point of contention in the whole
 discussion.
 
 The most problematic implication of what you're asking for is the
 additional effort that it would require from Fuel developers. When you
 say that Puppet OpenStack developers don't have time to look at Fuel git
 history for bugfixes, and then observe that actually Fuel developers do
 propose their patches to upstream, but those patches are stalled in the
 community review process, this indicates that you don't consider taking
 over and landing these patches a priority:

We don't consider taking the patches? Please go on Gerrit, look at the
patches and tell me if there is no review from Puppet OpenStack
community. Most of the patchs are -1 or not passing unit testing which
means the code can't be merged.

Let me give you examples so you can see Puppet OpenStack folks is doing
reviews on patchs from Fuel team:
https://review.openstack.org/#/c/170485/
https://review.openstack.org/#/c/157004/
https://review.openstack.org/#/c/176924/
https://review.openstack.org/#/c/168848/
https://review.openstack.org/#/c/130937/
https://review.openstack.org/#/c/131710/
https://review.openstack.org/#/c/174811/

And this is only 'in progress' patches. A lot of fixed have been
abandoned upstream. You can easily query them on Gerrit.
 
 http://lifehacker.com/5892948/instead-of-saying-i-dont-have-time-say-its-not-a-priority
 
 The fact that you have started this thread means that you actually do
 care to get these bugfixes into Puppet OpenStack. If that's true, maybe
 you can consider a middleground approach: Fuel team agrees to propose
 all our changes to upstream (i.e. do a better job

Re: [openstack-dev] Looking for help getting git-review to work over https

On 2015-06-11 23:32:58 + (+), KARR, DAVID wrote:
 I managed to install pip, but I don’t understand what “pip install
 git-review” is doing.  It doesn’t appear to be replacing the
 already installed git-review.

`pip install git-review` installs the latest git-review release from
pypi.python.org, but `pip install .` installs the source tree from
your current working directory.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Looking for help getting git-review to work over https