date:20140908


On 09/08/2014 03:46 AM, Dmitry Mescheryakov wrote:

Hello Fuelers,

On the previous meeting a topic was raised on how Fuel doc team should
work with bugs, see [1] for details. We agreed to move the discussion
into the mailing list.

The thing is there are two members in the team at the moment (Meg and
Irina) and they need to distribute work among themselves. The natural
way to distribute load is to assign bugs. But frequently they document
bugs which are in the process of being fixed, so they are already
assigned to an engineer. I.e. a bug needs to be assigned to an
engineer and a tech writer at the same time.

I've proposed to create a separate series 'docs' in launchpad (it is
the thing like '5.0.x', '5.1.x'). If bug affects several series, a
different engineer could be assigned on each of them. So doc team will
be free to assign bugs to themselves within this new series.

Mike Scherbakov and Dmitry Borodaenko objected creating another series
in launchpad. Instead they proposed to mark bugs with tags like
'docs-irina' and 'docs-meg' thus assigning them.

What do you think is the best way to handle this? As for me, I don't
have strong preference there.

One last note: the question applies to two launchpad projects
actually: Fuel and MOS. But naturally we want to do this the same way
in both projects.


Hi Dmitry!

Good question and problem! :) This limitation of Launchpad has bugged me 
for some time (pun intended). It would be great to have the ability to 
assign a bug to more than one person.


I actually think using tags is more appropriate here. Series are 
intended for releasable things. And since we'd never be releasing just 
a docs package, having a docs series doesn't really work. So, though 
it's a bit kludgy, I think using tags is the best solution here.


All the best,
-jay

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

Re: [openstack-dev] [neutron] non-deterministic gate failures due to unclosed eventlet Timeouts

2014-09-08 Thread Thierry Carrez

John Schwarz wrote:
 Long story short: for future reference, if you initialize an eventlet
 Timeout, make sure you close it (either with a context manager or simply
 timeout.close()), and be extra-careful when writing tests using
 eventlet Timeouts, because these timeouts don't implicitly expire and
 will cause unexpected behaviours (see [1]) like gate failures. In our
 case this caused non-deterministic failures on the dsvm-functional test
 suite.

Nice catch, John!

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [cinder] new cinderclient release this week?

2014-09-08 Thread Thierry Carrez

John Griffith wrote:
 Yes, now that RC1 is tagged I'm planning to tag a new cinderclient
 tomorrow.  I'll be sure to send an announcement out as soon as it's up.

You mean, now that juno-3 is tagged ;) RC1 is still a few weeks and a
few dozens bugfixes away.

-- 
Thierry Carrez (ttx)

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

[openstack-dev] oslo.config 1.4.0.0a4 released - juno rc1

The Oslo team is pleased to release version 1.4.0.0a4 of oslo.config, our first 
release candidate for oslo.config for juno.

This release includes:

$ git log --no-merges --oneline 1.4.0.0a3..1.4.0.0a4
6acc2dd Updated from global requirements
a590c2a Log a fixed length string of asterisks for obfuscation
46eabcc Added link to bug tracker and documentation in oslo.config readme
4c1ada2 Bump hacking to version 0.9.2

Please report issues to the NEW oslo.config bug tracker: 
https://bugs.launchpad.net/oslo.config

Doug


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

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

2014-09-08 Thread Dan Smith

 The last few days have been interesting as I watch FFEs come through.
 People post explaining their feature, its importance, and the risk
 associated with it. Three cores sign on for review. All of the ones
 I've looked at have received active review since being posted. Would
 it be bonkers to declare nova to be in permanent feature freeze? If
 we could maintain the level of focus we see now, then we'd be getting
 heaps more done that before.
 
 Agreed. Honestly, this has been a really nice flow. I'd love to figure
 out what part of this focus is capturable for normal cadence. This
 realistically is what I was hoping slots would provide, because I feel
 like we actually move really fast when we call out 5-10 things to go
 look at this week.

The funny thing is, last week I was thinking how similar FF is to what
slots/runways would likely provide. That is, intense directed focus on a
single thing by a group of people until it's merged (or fails). Context
is kept between iterations because everyone is on board for quick
iterations with minimal distraction between them. It *does* work during
FF, as we've seen in the past -- I'd expect we have nearly 100% merge
rate of FFEs. How we arrive at a thing getting focus is different in
slots/runways, but I feel the result could be the same.

Splitting out the virt drivers is an easy way to make the life of a core
much easier, but I think the negative impacts are severe and potentially
irreversible, so I'd rather make sure we're totally out of options
before we exercise it.

--Dan



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

[openstack-dev] oslo.i18n 0.3.0 released - juno rc1

The Oslo team is pleased to announce the release of version 0.3.0 of oslo.i18n, 
our first release candidate for oslo.i18n for juno.

This release includes:

$ git log --oneline --no-merges 0.2.0..0.3.0
08bee34 Imported Translations from Transifex
aa251be Updated from global requirements
106387b Imported Translations from Transifex
688076e Document how to add import exceptions
a4fc251 Remove mention of Message objects from public docs

Please report issues via the NEW launchpad bug tracker: 
https://bugs.launchpad.net/oslo.i18n

Doug


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

[openstack-dev] oslo.messaging 1.4.0.0a5 released - juno rc1

The Oslo team is pleased to announce the release of version 1.4.0.0a5 of 
oslo.messaging, our first release candidate for oslo.messaging for juno.

This release includes:

$ git log --oneline --no-merges 1.4.0.0a4..1.4.0.0a5
6ea3b12 Imported Translations from Transifex
fbee941 An initial implementation of an AMQP 1.0 based messaging driver
a9ec73f Switch to oslo.utils
48a9ba4 Fix Python 3 testing
265b21f Import oslo-incubator context module
f480494 Import oslo-incubator/middleware/base
7381ccd Should not send replies for cast messages
4cb33ec Port to Python 3
710dd17 Sync jsonutils from oslo-incubator
2464ca0 Add parameter to customize Qpid receiver capacity
220ccb8 Make tests pass with random python hashseed
92d5679 Set sample_default for rpc_zmq_host
dd1d6d1 Enable PEP8 check E714
ec9ffdb Enable PEP8 check E265
8151da8 Enable PEP8 check E241
ba5b547 Fix error in example of an RPC server
7fdedda Replace lambda method _
500f1e5 Enable check for E226
63a6d62 Updated from global requirements
bea9723 Add release notes for 1.4.0.0a4
d020cb8 Add release notes for stable/icehouse 1.3.1 release
6684565 Bump hacking to version 0.9.2
5fbb55b Add missing docs for list_opts()

Of special note is the experimental AMQP 1.0 driver.

Please report issues via the launchpad bug tracker: 
https://bugs.launchpad.net/oslo.messaging

Doug


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

[openstack-dev] [python-novaclient] servers list

2014-09-08 Thread Abbass MAROUNI


Hi guys,

I'm working with 'servers.list' call in 'nova.novaclient' and I'm 
getting different server lists depending on whether the user issuing the 
call is and admin or not.
It seems like only an admin user can filter the returned list while a 
non-admin gets a list of all the servers no matter what filter is being 
used.


Is this a know issue ?

Best regards,

--
--
Abbass MAROUNI
VirtualScale


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

[openstack-dev] oslo.serialization 0.2.0 released - juno rc1

The Oslo team is pleased to release version 0.2.0 of oslo.serialization, our 
first release candidate for oslo.serialization for juno.

This release includes:

$ git log --no-merges --oneline 0.1.0..0.2.0
4d61c82 Check for namedtuple_as_object support before using it

Please report issues to the NEW bug tracker: 
https://bugs.launchpad.net/oslo.serialization

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

Re: [openstack-dev] [python-novaclient] servers list


On 09/08/2014 10:27 AM, Abbass MAROUNI wrote:

Hi guys,

I'm working with 'servers.list' call in 'nova.novaclient' and I'm
getting different server lists depending on whether the user issuing the
call is and admin or not.
It seems like only an admin user can filter the returned list while a
non-admin gets a list of all the servers no matter what filter is being
used.

Is this a know issue ?


That would definitely be a bug. Please do report it with the steps you 
are taking to reproduce! :)


Best,
-jay

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

Re: [openstack-dev] [NFV] NFV Meetings

2014-09-08 Thread Steve Gordon

- Original Message -
 From: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org

 Hi,

 Hope you are doing good.
 Did we have a meeting last week?
 I was under the impression it¹s was scheduled to Thursday (as in the wiki)
 but found other meetings in the IRCŠ
 What am I missing?
 Do we have one this week?

Hi Itai,

Yes there was a meeting last Thursday IN #openstack-meeting @ 1600 UTC, the 
minutes are here:

http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-09-04-16.00.log.html

This week's meeting will be on Wednesday at 1400 UTC in #openstack-meeting-alt.

 Also,
 I sent a mail about the sub groups goals as we agreed ten days ago.
 Did you see it?

 Happy to hear your thoughts.

I did see this and thought it was a great attempt to re-frame the discussion (I 
think I said as much in the meeting). I'm personally still mulling over my own 
thoughts on the matter and how to respond. Maybe we will have more opportunity 
to discuss this week?

Thanks,

Steve

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

Re: [openstack-dev] [nova][neutron] default allow security group

2014-09-08 Thread Brian Haley

On 09/05/2014 11:27 AM, Monty Taylor wrote:
 Hi!
 
 I've decided that as I have problems with OpenStack while using it in the
 service of Infra, I'm going to just start spamming the list.
 
 Please make something like this:
 
 neutron security-group-create default --allow-every-damn-thing

Does this work?  Sure, it's a rule in the default group and not a group itself,
but it's a one-liner:

$ neutron security-group-rule-create --direction ingress --remote-ip-prefix
0.0.0.0/0 default

 Right now, to make security groups get the hell out of our way because they do
 not provide us any value because we manage our own iptables, it takes adding
 something like 20 rules.
 
 15:24:05  clarkb | one each for ingress and egress udp tcp over ipv4
 then ipv6 and finaly icmp

I guess you mean 20 rules because there's services using ~20 different ports,
which sounds about right.  If you really didn't care you could have just opened
all of ICMP, TCP and UDP with three rules.

And isn't egress typically wide-open by default?  You shouldn't need any rules
there.

And I do fall in the more security camp - giving someone a publicly-routable
IP address with all ports open is not typically a good idea, I wouldn't want to
hear the complaints from customers on that one...

-Brian

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

[openstack-dev] cliff 1.7.0 released

The Oslo team is pleased to release version 1.7.0 of cliff.

This release includes:

$ git log --oneline --no-merges 1.6.1..1.7.0
42675b2 Add release notes for 1.7.0
86fe20f Fix stable integration tests
bf0c611 Updated from global requirements
ac1347c Clean up default tox environment list
db4eef5 Do not allow wheels for stable tests
6bb6944 Set the main logger name to match the application
c383448 CSV formatter should use system-dependent line ending
e3bec7b Make show option compatible with Python 2.6.
9315a32 Use six.add_metaclass instead of __metaclass__
9f331fb fixed typos found by RETF rules
d150502 The --variable option to shell format is redundant
69966df Expose load_commands publicly
a37ef60 Fix wrong method name assert_called_once
4bdf5fc Updated from global requirements
90ea2b2 Fix pep8 failures on rule E265

Please report issues to the bug tracker: https://bugs.launchpad.net/python-cliff

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

[openstack-dev] stevedore 1.0.0.0a2 released -- juno rc1

The Oslo team is pleased to release version 1.0.0.0a2 of stevedore, our first 
release candidate for stevedore for the OpenStack Juno cycle.

This release includes:

$ git log --oneline --no-merges 1.0.0.0a1..1.0.0.0a2
860bd8f Build universal wheels

Please report issues to the stevedore bug tracker: 
https://bugs.launchpad.net/python-stevedore

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

Re: [openstack-dev] doubling our core review bandwidth

2014-09-08 Thread Alexis Lee

Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400:
  On 09/08/2014 05:17 AM, Steven Hardy wrote:
  I think this may be a sensible move, but only if it's used primarily to
  land the less complex/risky patches more quickly.
 
 2 +2 has been part of OpenStack culture for a long time, and there is a
 good reason for it, it really does keep bugs out.
 
 It should also be clear that the subject of this email really should
 have been merging code faster, because nothing in here doubles the
 review bandwidth, it just provides us with less review coverage.

For these reasons, I'm also wary of changing this in general.

Sometimes I yell in IRC if I +2 something important, this shortens loop
time as hopefully I already understand the patch and can answer
questions.

Single-approvals for small + simple changes could be worth trying.
Perhaps also for large + simple changes like whitespace fixes.


Alexis
-- 
Nova Engineer, HP Cloud.  AKA lealexis, lxsli.

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

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

2014-09-08 Thread Anne Gentle

On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy sha...@redhat.com wrote:

 On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote:
 On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek
 gauvain.pocen...@objectif-libre.com wrote:
 
   Hi,
 
   A bit of background: I'm working on the publication of the HOT
 resources
   reference on docs.openstack.org. This book is mostly autogenerated
 from
   the heat source code, using the sphinx XML output. To avoid
 publishing
   several references (one per released version, as is done for the
   OpenStack config-reference), I'd like to add information about the
   support status of each resource (when they appeared, when they've
 been
   deprecated, and so on).
 
   So the plan is to use the SupportStatus class and its `version`
   attribute (see https://review.openstack.org/#/c/116443/ ). And the
   question is, what information should the version attribute hold?
   Possibilities include the release code name (Icehouse, Juno), or the
   release version (2014.1, 2014.2). But this wouldn't be useful for
 users
   of clouds continuously deployed.
 
   From my documenter point of view, using the code name seems the
 right
   option, because it fits with the rest of the documentation.
 
   What do you think would be the best choice from the heat devs POV?
 
 IMHO it should match the releases and tags
 (https://github.com/openstack/heat/releases).

 +1 this makes sense to me.  Couldn't we have the best of both worlds by
 having some logic in the docs generation code which maps the milestone to
 the release series, so we can say e.g

 Supported since 2014.2.b3 (Juno)



I agree with the matching of releases, but let's set expectations for how
often it'll be generated. That is to say, each tag is a bit much to ask. I
think that even each milestone is asking a bit much. How about each release
and include the final rc tag (2014.2?)

Anne



 This would provide sufficient detail to be useful to both folks consuming
 the stable releases and those trunk-chasing via CD?

 Steve

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

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

Re: [openstack-dev] Kilo Cycle Goals Exercise


On Sep 7, 2014, at 9:27 PM, Anita Kuno ante...@anteaya.info wrote:

 On 09/07/2014 09:12 PM, Angus Salkeld wrote:
 Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
 users happy.
 I don't understand why you would encourage writers of blog posts you
 disagree with by sending them traffic.

silencing users who have issues with your project is a really bad idea.If 
you want to create something great you absolutely need to be obsessed with your 
detractors and the weight of what they have to say.  Because unless they are a 
competitor engaged in outright slander, there will be some truth in it.   
Ignore criticism at your peril.Someone who takes the time to write out an 
even somewhat well reasoned criticism is doing your project a service.

I found the above blog post very interesting as I’d like to get more data on 
what the large, perceived issues are.




 
 Anita.
 
 1) Consistent/easy upgrading.
 all projects should follow a consistent model to the way they approach
 upgrading.
 it should actually work.
 - REST versioning
 - RPC versioning
 - db (data) migrations
 - ordering of procedures and clear documentation of it.
[this has been begged for by operators, but not sure how we have
 delivered]
 
 2) HA
  - ability to continue operations after been restated
  - functional tests to prove the above?
 
 3) Make it easier for small business to give OpenStack a go
  - produce standard docker images as part of ci with super simple
 instructions on running them.
 
 -Angus
 
 
 
 On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon joe.gord...@gmail.com wrote:
 
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].
 
 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of what
 they think the project wide Kilo cycle goals should be and post them on
 this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.
 
 
 best,
 Joe Gordon
 
 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
 [1]
 http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] doubling our core review bandwidth

2014-09-08 Thread Sean Dague

On 09/08/2014 11:07 AM, Alexis Lee wrote:
 Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400:
 On 09/08/2014 05:17 AM, Steven Hardy wrote:
 I think this may be a sensible move, but only if it's used primarily to
 land the less complex/risky patches more quickly.

 2 +2 has been part of OpenStack culture for a long time, and there is a
 good reason for it, it really does keep bugs out.

 It should also be clear that the subject of this email really should
 have been merging code faster, because nothing in here doubles the
 review bandwidth, it just provides us with less review coverage.
 
 For these reasons, I'm also wary of changing this in general.
 
 Sometimes I yell in IRC if I +2 something important, this shortens loop
 time as hopefully I already understand the patch and can answer
 questions.
 
 Single-approvals for small + simple changes could be worth trying.
 Perhaps also for large + simple changes like whitespace fixes.

Realistically core teams are already doing that. Being considered an
exception people typically provide a good reason in the review as to why
it's a fast approve, which is fine.

The large cross cutting whitespace fixes are actually completely
problematic in their own way, because they typically force a non trivial
rebase on 10s - 100s of patches in flight, so they generate *a ton* of
work for other people.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [neutron] non-deterministic gate failures due to unclosed eventlet Timeouts

On Sep 7, 2014, at 9:39 AM, John Schwarz jschw...@redhat.com wrote:

Hi,

Long story short: for future reference, if you initialize an eventlet
Timeout, make sure you close it (either with a context manager or simply
timeout.close()), and be extra-careful when writing tests using
eventlet Timeouts, because these timeouts don't implicitly expire and
will cause unexpected behaviours (see [1]) like gate failures. In our
case this caused non-deterministic failures on the dsvm-functional test
suite.

It would be good to have a fixture class in oslotest to set up eventlet
timeouts properly.

Doug

Late last week, a bug was found ([2]) in which an eventlet Timeout
object was initialized but not closed. This instance was left inside
eventlet's inner-workings and triggered non-deterministic Timeout: 10
seconds errors and failures in dsvm-functional tests.

As mentioned earlier, initializing a new eventlet.timeout.Timeout
instance also registers it to inner mechanisms that exist within the
library, and the reference remains there until it is explicitly removed
(and not until the scope leaves the function block, as some would have
thought). Thus, the old code (simply creating an instance without
assigning it to a variable) left no way to close the timeout object.
This reference remains throughout the life of a worker, so this can
(and did) effect other tests and procedures using eventlet under the
same process. Obviously this could easily effect production-grade
systems with very high load.

For future reference:
1) If you run into a Timeout: %d seconds exception whose traceback
includes hub.switch() and self.greenlet.switch() calls, there might
be a latent Timeout somewhere in the code, and a search for all
eventlet.timeout.Timeout instances will probably produce the culprit.

2) The setup used to reproduce this error for debugging purposes is a
baremetal machine running a VM with devstack. In the baremetal machine I
used some 6 dd if=/dev/zero of=/dev/null to simulate high CPU load
(full command can be found at [3]), and in the VM I ran the
dsvm-functional suite. Using only a VM with similar high CPU simulation
fails to produce the result.

[1]
http://eventlet.net/doc/modules/timeout.html#eventlet.timeout.eventlet.timeout.Timeout.Timeout.cancel
[2] https://review.openstack.org/#/c/119001/
[3]
http://stackoverflow.com/questions/2925606/how-to-create-a-cpu-spike-with-a-bash-command

--
John Schwarz,
Software Engineer, Red Hat.

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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Anita Kuno

On 09/08/2014 11:12 AM, Mike Bayer wrote:
 
 On Sep 7, 2014, at 9:27 PM, Anita Kuno ante...@anteaya.info wrote:
 
 On 09/07/2014 09:12 PM, Angus Salkeld wrote:
 Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making
 users happy.
 I don't understand why you would encourage writers of blog posts you
 disagree with by sending them traffic.
 
 silencing users who have issues with your project is a really bad idea.If 
 you want to create something great you absolutely need to be obsessed with 
 your detractors and the weight of what they have to say.  Because unless they 
 are a competitor engaged in outright slander, there will be some truth in it. 
   Ignore criticism at your peril.Someone who takes the time to write out 
 an even somewhat well reasoned criticism is doing your project a service.
 
 I found the above blog post very interesting as I’d like to get more data on 
 what the large, perceived issues are.
 
Wow, we are really taking liberties with my question today.

What part of any of my actions current or previous have led you to
believe that I want to now or ever have silenced anyone? I am curious
what led you to believe that silencing users was the motivation for my
question of Angus.

I now see, through asking Angus for clarity which he did provide (not
silencing him, you will notice), that Angus' motivation was prevention
of poor user experience through better attention.

I am highly aware, particularly in the area in which I work - the third
party space- of the leading nature of behavioural training that takes
place particularly of new contributors and contributors who don't have
English as a first language of anything we ask or expect them to do.
Many times what seems to be a reasonable comment or expectation can be
taken completely out of context by folks who don't have English as a
first language and don't have the cultural context and filters that
English speakers have.

Actually my question was motivated from a user experience point of view,
the third party user, since I am only too aware of what kind of
questions and confusion many comments cause because the commenter
doesn't take the non-English speaker point of view into account.

By clarifying Angus' motivation with Angus, hopefully his meaning -
create better user experiences, and better relationships with users -
has come through.

And I agree with all of your points, which is why I take such pains to
create clarity on the mailing lists and other communication.

Thanks,
Anita.
 
 
 

 Anita.

 1) Consistent/easy upgrading.
 all projects should follow a consistent model to the way they approach
 upgrading.
 it should actually work.
 - REST versioning
 - RPC versioning
 - db (data) migrations
 - ordering of procedures and clear documentation of it.
[this has been begged for by operators, but not sure how we have
 delivered]

 2) HA
  - ability to continue operations after been restated
  - functional tests to prove the above?

 3) Make it easier for small business to give OpenStack a go
  - produce standard docker images as part of ci with super simple
 instructions on running them.

 -Angus



 On Thu, Sep 4, 2014 at 1:37 AM, Joe Gordon joe.gord...@gmail.com wrote:

 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of what
 they think the project wide Kilo cycle goals should be and post them on
 this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.


 best,
 Joe Gordon

 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
 [1]
 http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html

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





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



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

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Sep 7, 2014, at 8:14 PM, Monty Taylor mord...@inaugust.com wrote:

2. Less features, more win

In a perfect world, I'd argue that we should merge exactly zero new features
in all of kilo, and instead focus on making the ones we have work well. Some
of making the ones we have work well may wind up feeling just like writing
features, as I imagine some of our features are probably only half features
in the first place.

3. Deleting things

We should delete a bunch of code. Deleting code is fun, and it makes your
life better, because it means you have less code. So we should start doing
it. In particular, we should look for places where we wrote something as part
of OpenStack because the python community did not have a thing already, but
now there is one. In those cases, we should delete ours and use theirs. Or we
should contribute to theirs if it's not quite good enough yet. Or we should
figure out how to make more of the oslo libraries things that can truly
target non-OpenStack things.

I have to agree that “Deleting things” is the best, best thing. Anytime you
can refactor around things and delete more code, a weight is lifted, your code
becomes easier to understand, maintain, and expand upon.Simpler code then
gives way to refactorings that you couldn’t even see earlier, and sometimes you
can even get a big performance boost once a bunch of supporting code now
reveals itself to be superfluous. This is most critical for Openstack as
Openstack is written in Python, and for as long as we have to stay on the
cPython interpreter, number of function calls is directly proportional to how
slow something is. Function calls are enormously expensive in Python.

Something that helps greatly with the goal of “Deleting things” is to reduce
dependencies between systems. In SQLAlchemy, the kind of change I’m usually
striving for is one where we take a module that does one Main Thing, but then
has a bunch of code spread throughout it to do some Other Thing, that is really
much less important, but complicates the Main Thing. What we do is reorganize
the crap out of it and get the Other Thing out of the core Main Thing, move it
out to a totally optional “extension” module that bothers noone, and we
essentially forget about it because nobody ever uses it (examples include
http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_08.html#instrumentationmanager-and-alternate-class-instrumentation-is-now-an-extension,

http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_08.html#mutabletype).
When we make these kinds of changes, major performance enhancements come
right in - the Main Thing no longer has to worry about those switches and left
turns introduced by the Other Thing, and tons of superfluous logic can be
thrown away.SQLAlchemy’s architecture gains from these kinds of changes
with every major release and 1.0 is no exception.

This is not quite the same as “Deleting things” but it has more or less the
same effect; you isolate code that everyone uses from code that only some
people occasionally use. In SQLAlchemy specifically, we have the issue of
individual database dialects that are still packaged along; e.g. there is
sqlalchemy.dialects.mysql, sqlalchemy.dialects.postgresql, etc. However, a few
years back I went through a lot of effort to modernize the system by which
users can provide their own database backends; while you can not only provide
your own custom backend using setuptools entry points, I also made a major
reorganization of SQLAlchemy’s test suite to produce the “dialect test suite”;
so that when you write your custom dialect, you can actually run a large,
pre-fabricated test suite out of SQLAlchemy’s core against your dialect,
without the need for your dialect to be actually *in* SQLAlchemy. There
were many wins from this system, including that it forced me to write lots of
tests that were very well focused on testing specifically what a dialect needs
to do, in isolation of anything SQLAlchemy itself needs to do. It allowed a
whole batch of new third party dialects like that for Amazon Redshift,
FoundationDB, MonetDB, and also was a huge boon to IBM’s DB2 driver who I
helped to get onto the new system. And since then I’ve been able to go into
SQLAlchemy and dump out lots of old dialects that are much better off being
maintained separately, at a different level of velocity and hopefully by
individual contributors who are interested in them, like MS Access, Informix,
MaxDB, and Drizzle. Having all these dialects in one big codebase only served
as a weight on the project, and theoretically it wouldn’t be a bad idea for
SQLA to have *all* dialects as separate projects, but we’re not there yet.

The only reason I’m rambling on about a SQLAlchemy’s Core/Dialect dichotomy is
just that I was very much *reminded* of it by the thread regarding Nova and the
various “virt” drivers. I know

Re: [openstack-dev] [Fuel] SSL in Fuel

2014-09-08 Thread Adam Lawson

blueprints for non-self-signed certs/PKI for starters.


*Adam Lawson*
*CEO, Principal Architect*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072



On Mon, Sep 8, 2014 at 2:49 AM, Sebastian Kalinowski 
skalinow...@mirantis.com wrote:

 Hi all,

 As next step for improving Fuel security we are introducing SSL for both
 Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed
 certificates generated by Fuel.
 It also required to allow users to use their own certs to secure their
 deployments
 (two blueprints that touch that part are [3] and [4])

 We would like to start a discussion to see what opinions (and maybe ideas)
 you
 have for that feature.

 Best,
 Sebastian

 [1] https://review.openstack.org/#/c/119330
 [2] https://review.openstack.org/#/c/102273
 [3] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
 [4] https://blueprints.launchpad.net/fuel/+spec/manage-ssl-certificate

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


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

Re: [openstack-dev] [Heat] Should docker plugin remove containers on delete?

2014-09-08 Thread Zane Bitter


On 01/09/14 19:18, Steve Baker wrote:

On 02/09/14 05:58, Lars Kellogg-Stedman wrote:

Hello all,

I recently submitted this change:

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

This causes the Docker plugin to *remove* containers on delete,
rather than simply *stopping* them.  When creating named containers,
the stop but do not remove behavior would cause conflicts when try
to re-create the stack.

Do folks have an opinion on which behavior is correct?


Removing after stopping seems reasonable.


+1


If we wanted to support both
behaviors then that resource could always have deletion_policy: Retain
implemented.


I think you mean Snapshot (every resource supports Retain, because it's 
just a NOOP), which we may well be able to do something with. However I 
think the correct way of stopping ( starting) containers is to 
implement the Suspend/Resume lifecycle operations on the resource.


cheers,
Zane.

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

Re: [openstack-dev] Kilo Cycle Goals Exercise


On Sep 8, 2014, at 11:30 AM, Anita Kuno ante...@anteaya.info wrote:

 Wow, we are really taking liberties with my question today.
 
 What part of any of my actions current or previous have led you to
 believe that I want to now or ever have silenced anyone? I am curious
 what led you to believe that silencing users was the motivation for my
 question of Angus.

I was only replying to your single message in isolation of the full 
conversation; the notion that one would not want to send traffic to a blog 
because they disagree with it, at face value seems like a bad idea.  Apparently 
that isn’t the meaning you wished to convey, so I apologize for missing the 
larger context.




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

Re: [openstack-dev] doubling our core review bandwidth

2014-09-08 Thread Kevin L. Mitchell

 tl;dr I think we should drop our 'needs 2x+2 to land' rule and instead
 use 'needs 1x+2'. We can ease up a large chunk of pressure on our
 review bottleneck, with the only significant negative being that core
 reviewers may see less of the code going into the system - but they
 can always read more to stay in shape if thats an issue :)

I'm going to make a tangential but somewhat related suggestion.  Instead
of reducing the number of +2s required, what would happen if we gave our
more trusted but non-core reviewers the ability to +2, but leave +A in
the hands of the existing cores?  That way, their reviews can be counted
by the core reviewers.  With this change in policy, you still need two
+2s, but you have more people that can +2, and you only need one of our
limited number of cores to review.
-- 
Kevin L. Mitchell kevin.mitch...@rackspace.com
Rackspace


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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Anita Kuno

On 09/08/2014 12:00 PM, Mike Bayer wrote:
 
 On Sep 8, 2014, at 11:30 AM, Anita Kuno ante...@anteaya.info wrote:
 
 Wow, we are really taking liberties with my question today.

 What part of any of my actions current or previous have led you to
 believe that I want to now or ever have silenced anyone? I am curious
 what led you to believe that silencing users was the motivation for my
 question of Angus.
 
 I was only replying to your single message in isolation of the full 
 conversation; the notion that one would not want to send traffic to a blog 
 because they disagree with it, at face value seems like a bad idea.
Actually the word used was prevent, and if I personally want to prevent
something I don't encourage it by giving it attention.

Not understanding something due to disagreement with it is, I agree, a
perspective which is limiting and which ultimately does the party at the
heart of the discussion the most harm, it is self-defeating, yes.

  Apparently that isn’t the meaning you wished to convey, so I apologize for 
 missing the larger context.
I appreciate you taking the time to talk to me so that we might
understand each other better. Thank you, Mike, I'm grateful for your
time with this.

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


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

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

2014-09-08 Thread Sylvain Bauza



Le 08/09/2014 18:06, Steven Dake a écrit :

On 09/05/2014 06:10 AM, Sylvain Bauza wrote:


Le 05/09/2014 12:48, Sean Dague a écrit :

On 09/05/2014 03:02 AM, Sylvain Bauza wrote:

Le 05/09/2014 01:22, Michael Still a écrit :

On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange
berra...@redhat.com wrote:

[Heavy snipping because of length]


The radical (?) solution to the nova core team bottleneck is thus to
follow this lead and split the nova virt drivers out into separate
projects and delegate their maintainence to new dedicated teams.

   - Nova becomes the home for the public APIs, RPC system, database
 persistent and the glue that ties all this together with the
 virt driver API.

   - Each virt driver project gets its own core team and is 
responsible

 for dealing with review, merge  release of their codebase.
I think this is the crux of the matter. We're not doing a great 
job of

landing code at the moment, because we can't keep up with the review
workload.

So far we've had two proposals mooted:

   - slots / runways, where we try to rate limit the number of things
we're trying to review at once to maintain focus
   - splitting all the virt drivers out of the nova tree

Ahem, IIRC, there is a third proposal for Kilo :
  - create subteam's half-cores responsible for reviewing patch's
iterations and send to cores approvals requests once they consider the
patch enough stable for it.

As I explained, it would allow to free up reviewing time for cores
without loosing the control over what is being merged.
I don't really understand how the half core idea works outside of a 
math

equation, because the point is in core is to have trust over the
judgement of your fellow core members so that they can land code when
you aren't looking. I'm not sure how I manage to build up half trust in
someone any quicker.


Well, this thread is becoming huge so that's becoming hard to follow 
all the discussion but I explained the idea elsewhere. Let me just 
provide it here too :
The idea is *not* to land patches by the halfcores. Core team will 
still be fully responsible for approving patches. The main problem in 
Nova is that cores are spending lots of time because they review each 
iteration of a patch, and also have to look at if a patch is good or 
not.


That's really time consuming, and for most of the time, quite 
frustrating as it requires to follow the patch's life, so there are 
high risks that your core attention is becoming distracted over the 
life of the patch.


Here, the idea is to reduce dramatically this time by having teams 
dedicated to specific areas (as it's already done anyway for the 
various majority of reviewers) who could on their own take time for 
reviewing all the iterations. Of course, that doesn't mean cores 
would loose the possibility to specifically follow a patch and bypass 
the halfcores, that's just for helping them if they're overwhelmed.


About the question of trusting cores or halfcores, I can just say 
that Nova team is anyway needing to grow up or divide it so the 
trusting delegation has to be real anyway.


This whole process is IMHO very encouraging for newcomers because 
that creates dedicated teams that could help them to improve their 
changes, and not waiting 2 months for getting a -1 and a frank reply.



Interesting idea, but having been core on Heat for ~2 years, it is 
critical to be involved in the review from the beginning of the patch 
set.  Typically you won't see core reviewer's participate in a review 
that is already being handled by two core reviewers.


The reason it is important from the beginning of the change request is 
that the project core can store the iterations and purpose of the 
change in their heads.  Delegating all that up front work to a 
non-core just seems counter to the entire process of code reviews. 
Better would be reduce the # of reviews in the queue (what is proposed 
by this change) or trust new reviewers faster.  I'm not sure how you 
do that - but this second model is what your proposing.


I think one thing that would be helpful is to point out somehow in the 
workflow that two core reviewers are involved in the review so core 
reviewers don't have to sift through 10 pages of reviews to find new 
work.




Now that the specs repo is in place and has been proved with Juno, most 
of the design stage is approved before the implementation is going. If 
the cores are getting more time because they wouldn't be focused on each 
single patchset, they could really find some patches they would like to 
look at, or they could just wait for the half-approvals from the halfcores.


If a core thinks that a patch is enough tricky for looking at each 
iteration, I don't see any bad things. At least, it's up to the core 
reviewer to choose which patches he could look at, and he would be more 
free than if the slots proposal would be there.


I'm a core from a tiny project but I know how time consuming it is. I 
would really enjoy if

[openstack-dev] [Mistral] Team meeting minutes/log - 08/09/2014

2014-09-08 Thread Renat Akhmerov

Thanks for joining us today at our team meeting!

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-08-16.00.html
Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-08-16.00.log.html
Agenda/Meeting archive: https://wiki.openstack.org/wiki/Meetings/MistralAgenda

The next meeting will be at the same time/place on Sep 15.

Renat Akhmerov
@ Mirantis Inc.



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

[openstack-dev] [Fuel] Working on 6.0 and new releases in general

2014-09-08 Thread Dmitry Mescheryakov

Hello Fuelers,

Right now we have the following policy in place: the branches for a
release are opened only after its 'parent' release have reached hard
code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and
6.0.

And that is the problem: if parent release is delayed, we can't
properly start development of a child release because we don't have
branches to commit. That is current issue with 6.0: we already started
to work on pushing Juno in to 6.0, but if we are to make changes to
our deployment code we have nowhere to store them.

IMHO the issue could easily be resolved by creation of pre-release
branches, which are merged together with parent branches once the
parent reaches HCF. Say, we use branch 'pre-6.0' for initial
development of 6.0. Once 5.1 reaches HCF, we merge pre-6.0 into master
and continue development here. After that pre-6.0 is abandoned.

What do you think?

Thanks,

Dmitry

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

[openstack-dev] [qa] Reminder: Tempest Bug Day: Tuesday September 9 (tomorrow)

2014-09-08 Thread David Kranz



It's been a while since we had a bug day. We now have 121 (now 124) NEW 
bugs:


https://bugs.launchpad.net/tempest/+bugs?field.searchtext=field.status%3Alist=NEWorderby=-importance

The first order of business is to triage these bugs. This is a large 
enough number that I hesitate to
mention anything else, but there are also many In Progress bugs that 
should be looked at to see if they should

be closed or an assignee removed if no work is actually planned:

https://bugs.launchpad.net/tempest/+bugs?search=Searchfield.status=In+Progress

I hope we will see a lot of activity on this bug day. During the 
Thursday meeting right after we can see if
there are ideas for how to manage the bugs on a more steady-state basis. 
We could also discuss how the grenade and

devstack bugs should fit in to such activities.

-David



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

[openstack-dev] [Infra] Meeting Tuesday September 9th at 19:00 UTC

2014-09-08 Thread Elizabeth K. Joseph

Hi everyone,

The OpenStack Infrastructure (Infra) team is hosting our weekly
meeting on Tuesday September 9th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2
http://www.princessleia.com

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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Brad Topol

Monty,

+1!!   I fully agree!!  How can I help :-)?  Can we dedicate some design 
summit sessions to this topic?  Ideally,  having some stakeholder driven 
sessions where we can hear about the user experiences issues causing the 
most pain would be a good start to get this to become a focus area.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor mord...@inaugust.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, 
Date:   09/07/2014 08:15 PM
Subject:Re: [openstack-dev] Kilo Cycle Goals Exercise



On 09/03/2014 08:37 AM, Joe Gordon wrote:
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One 
idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of 
what
 they think the project wide Kilo cycle goals should be and post them on
 this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world 
views
 align with the greater community, and to get the ball rolling on a 
larger
 discussion of where as a project we should be focusing more time.

If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not 
running your own cloud, that we collectively have not valued the class 
of user who is a person who wants to use the cloud. Examples of this 
are that the other day I had to read a section of the admin guide to 
find information about how to boot a nova instance with a cinder volume 
attached all in one go. Spoiler alert, it doesn't work. Another spoiler 
alert - even though the python client has an option for requesting that 
a volume that is to be attached on boot be formatted in a particular 
way, this does not work for cinder volumes, which means it does not work 
for an end user - EVEN THOUGH this is a very basic thing to want.

Our client libraries are clearly not written with end users in mind, and 
this has been the case for quite some time. However, openstacksdk is not 
yet to the point of being usable for end users - although good work is 
going on there to get it to be a basis for an end user python library.

We give deployers so much flexibility, that in order to write even a 
SIMPLE program that uses OpenStack, an end user has to know generally 
four of five pieces of information to check for that are different ways 
that a deployer may have decided to do things.

Example:

  - As a user, I want a compute instance that has an IP address that can 
do things.

WELL, now you're screwed, because there is no standard way to do that. 
You may first want to try booting your instance and then checking to see 
if nova returns a network labeled public. You may get no networks. 
This indicates that your provider decided to deploy neutron, but as part 
of your account creation did not create default networks. You now need 
to go create a router, network and port in neutron. Now you can try 
again. Or, you may get networks back, but neither of them are labeled 
public - instead, you may get a public and a private address back in 
the network labeled private. Or, you may only get a private network 
back. This indicates that you may be expected to create a thing called a 
floating-ip. First, you need to verify that your provider has 
installed the floating-ip's extension. If they have, then you can create 
a floating-ip and attach it to your host. NOW - once you have those 
things done, you need to connect to your host and verify that its 
outbound networking has not been blocked by a thing called security 
groups, which you also may not have been expecting to exist, but I'll 
stop there, because the above is long enough.

Every. Single. One. Of. Those. Cases. is real and has occurred across 
only the two public openstack clouds that infra uses. That means that 
our provisioning code takes every single one of them in to account, and 
anyone who writes code that wants to get a machine to use must take them 
all in to account or else their code is buggy.

That's RIDICULOUS. So we should fix it. I'd say we should fix it by 
removing 1000% of the choices we've given deployers in this case, but I 
won't win there. So how about let's make at least one client library 
that encodes all of the above logic behind some simple task oriented API 
calls? How about we make that library not something which is just a 
repackaging of requests that does not contain intelligent, but instead 
something that is fundamentally usable. How about we have

Re: [openstack-dev] doubling our core review bandwidth

2014-09-08 Thread Zane Bitter


On 07/09/14 23:43, Morgan Fainberg wrote:

## avoiding collaboration between bad actors

The two core requirement means that it takes three people (proposer +
2 core) to collaborate on landing something inappropriate (whether its
half baked, a misfeature, whatever). Thats only 50% harder than 2
people (proposer + 1 core) and its still not really a high bar to
meet. Further, we can revert things.

Solid assessment. I tend to agree with this point. If you are going to have bad 
actors try and get code in you will have bad actors trying to get code in. The 
real question is: how many (if any) extra reverts will be needed in the case of 
bad actors? My guess is 1 per bad actor (which that actor is likely no longer 
going to be core), if there are even any bad actors out there.


I think this misses the point, which isn't so much to prevent bad actors 
(and I don't think we have any of those). It's to protect good (and 
sometimes maybe slightly misguided) actors from any perception that they 
might be behaving as bad actors.


I think Rob missed another possible benefit off the list: it allows us 
to add core team members more aggressively than we might if adding 
someone meant allowing them to approve patches by themselves.


I'm not convinced that dropping the 2 x +2 is the right trade-off, 
though I would definitely support more official documentation of the 
wiggle room available for reviewer discretion, such as what Flavio 
suggested. In Heat we agreed on a policy of allowing immediate approval 
in the case where you're effectively reviewing a rebase of or a minor 
fix to a patchset that already had the assent in principle of two core 
reviewers. I rarely see anyone actually do it though, I think in part 
because the OpenStack-wide documentation makes it sound very naughty. I 
was interested to learn from this thread that many programs appear to 
have informally instituted something similar.


cheers,
Zane.

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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Tim Bell


The End User working group is being described at 
https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is 
establishing the structure.

This page covers how to get involved...

Tim

From: Brad Topol [mailto:bto...@us.ibm.com]
Sent: 08 September 2014 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Kilo Cycle Goals Exercise

Monty,

+1!!   I fully agree!!  How can I help :-)?  Can we dedicate some design summit 
sessions to this topic?  Ideally,  having some stakeholder driven sessions 
where we can hear about the user experiences issues causing the most pain would 
be a good start to get this to become a focus area.

Thanks,

Brad


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.commailto:bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:Monty Taylor mord...@inaugust.commailto:mord...@inaugust.com
To:OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org,
Date:09/07/2014 08:15 PM
Subject:Re: [openstack-dev] Kilo Cycle Goals Exercise




On 09/03/2014 08:37 AM, Joe Gordon wrote:
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].

 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of what
 they think the project wide Kilo cycle goals should be and post them on
 this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.

If I were king ...

1. Caring about end user experience at all

It's pretty clear, if you want to do things with OpenStack that are not
running your own cloud, that we collectively have not valued the class
of user who is a person who wants to use the cloud. Examples of this
are that the other day I had to read a section of the admin guide to
find information about how to boot a nova instance with a cinder volume
attached all in one go. Spoiler alert, it doesn't work. Another spoiler
alert - even though the python client has an option for requesting that
a volume that is to be attached on boot be formatted in a particular
way, this does not work for cinder volumes, which means it does not work
for an end user - EVEN THOUGH this is a very basic thing to want.

Our client libraries are clearly not written with end users in mind, and
this has been the case for quite some time. However, openstacksdk is not
yet to the point of being usable for end users - although good work is
going on there to get it to be a basis for an end user python library.

We give deployers so much flexibility, that in order to write even a
SIMPLE program that uses OpenStack, an end user has to know generally
four of five pieces of information to check for that are different ways
that a deployer may have decided to do things.

Example:

 - As a user, I want a compute instance that has an IP address that can
do things.

WELL, now you're screwed, because there is no standard way to do that.
You may first want to try booting your instance and then checking to see
if nova returns a network labeled public. You may get no networks.
This indicates that your provider decided to deploy neutron, but as part
of your account creation did not create default networks. You now need
to go create a router, network and port in neutron. Now you can try
again. Or, you may get networks back, but neither of them are labeled
public - instead, you may get a public and a private address back in
the network labeled private. Or, you may only get a private network
back. This indicates that you may be expected to create a thing called a
floating-ip. First, you need to verify that your provider has
installed the floating-ip's extension. If they have, then you can create
a floating-ip and attach it to your host. NOW - once you have those
things done, you need to connect to your host and verify that its
outbound networking has not been blocked by a thing called security
groups, which you also may not have been expecting to exist, but I'll
stop there, because the above is long enough.

Every. Single. One. Of. Those. Cases. is real and has occurred across
only the two public openstack clouds that infra uses. That means that
our provisioning code takes every single one of them in to account, and
anyone who writes code that wants to get a machine to use must take them
all in to account or else their code is buggy.

Re: [openstack-dev] [Neutron] - reading router external IPs

2014-09-08 Thread Kevin Benton

IIUC, the required policy change is to allow a tenant to list ports that
don't belong to you. I don't think the policy.json is powerful enough to
allow tenants to list their external ports but no other ports they don't
own.
On Sep 8, 2014 10:30 AM, Carl Baldwin c...@ecbaldwin.net wrote:

 I think there could be some discussion about the validity of this as a
 bug report vs a feature enhancement.  Personally, I think I could be
 talked in to accepting a small change to address this bug but I
 won't try to speak for everyone.

 This bug report [1] -- linked by devvesa to the bug report to which
 Kevin linked -- suggests that the external IP address can be seen by
 an admin user.  Is there a policy.json setting that can be set at
 deployment time to allow this without making a change to the code
 base?

 Carl

 [1] https://bugs.launchpad.net/neutron/+bug/1189358

 On Sun, Sep 7, 2014 at 3:41 AM, Kevin Benton blak...@gmail.com wrote:
  https://review.openstack.org/#/c/83664/

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

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

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Joshua Harlow

Amen to this!

I've always felt bad that before yahoo tries to include a new feature in its 
openstack cloud/s we have to figure out how much the feature is a land-mine, 
how much of it works, how much of it doesn't and so-on. That type of 
investigation imho shouldn't really be needed and the fact that it is makes me 
want more and more a stability cycle or two (or three).

More and more recently I've be thinking that we have spent way to much on 
drivers and features and not enough on our own 'infrastructure'. 

While of course there is a balance, it just seems like the balance currently 
isn't right (IMHO).

Maybe we should start asking ourselves why it is so much easier to add a driver 
vs. do a cross-project functionality like gantt (or centralized quota 
management or other...) that removes some of those land-mines. When it becomes 
easier to land gantt vs a new driver then I think we might be in a better 
place. After all, our infrastructure is what makes the project a long-term 
success and not adding new drivers.

Just my 2 cents,

Josh

On Sep 7, 2014, at 5:14 PM, Monty Taylor mord...@inaugust.com wrote:

 On 09/03/2014 08:37 AM, Joe Gordon wrote:
 As you all know, there has recently been several very active discussions
 around how to improve assorted aspects of our development process. One idea
 that was brought up is to come up with a list of cycle goals/project
 priorities for Kilo [0].
 
 To that end, I would like to propose an exercise as discussed in the TC
 meeting yesterday [1]:
 Have anyone interested (especially TC members) come up with a list of what
 they think the project wide Kilo cycle goals should be and post them on
 this thread by end of day Wednesday, September 10th. After which time we
 can begin discussing the results.
 The goal of this exercise is to help us see if our individual world views
 align with the greater community, and to get the ball rolling on a larger
 discussion of where as a project we should be focusing more time.
 
 If I were king ...
 
 1. Caring about end user experience at all
 
 It's pretty clear, if you want to do things with OpenStack that are not 
 running your own cloud, that we collectively have not valued the class of 
 user who is a person who wants to use the cloud. Examples of this are that 
 the other day I had to read a section of the admin guide to find information 
 about how to boot a nova instance with a cinder volume attached all in one 
 go. Spoiler alert, it doesn't work. Another spoiler alert - even though the 
 python client has an option for requesting that a volume that is to be 
 attached on boot be formatted in a particular way, this does not work for 
 cinder volumes, which means it does not work for an end user - EVEN THOUGH 
 this is a very basic thing to want.
 
 Our client libraries are clearly not written with end users in mind, and this 
 has been the case for quite some time. However, openstacksdk is not yet to 
 the point of being usable for end users - although good work is going on 
 there to get it to be a basis for an end user python library.
 
 We give deployers so much flexibility, that in order to write even a SIMPLE 
 program that uses OpenStack, an end user has to know generally four of five 
 pieces of information to check for that are different ways that a deployer 
 may have decided to do things.
 
 Example:
 
 - As a user, I want a compute instance that has an IP address that can do 
 things.
 
 WELL, now you're screwed, because there is no standard way to do that. You 
 may first want to try booting your instance and then checking to see if nova 
 returns a network labeled public. You may get no networks. This indicates 
 that your provider decided to deploy neutron, but as part of your account 
 creation did not create default networks. You now need to go create a router, 
 network and port in neutron. Now you can try again. Or, you may get networks 
 back, but neither of them are labeled public - instead, you may get a 
 public and a private address back in the network labeled private. Or, you may 
 only get a private network back. This indicates that you may be expected to 
 create a thing called a floating-ip. First, you need to verify that your 
 provider has installed the floating-ip's extension. If they have, then you 
 can create a floating-ip and attach it to your host. NOW - once you have 
 those things done, you need to connect to your host and verify that its 
 outbound networkin
 g has not been blocked by a thing called security groups, which you also may 
not have been expecting to exist, but I'll stop there, because the above is 
long enough.
 
 Every. Single. One. Of. Those. Cases. is real and has occurred across only 
 the two public openstack clouds that infra uses. That means that our 
 provisioning code takes every single one of them in to account, and anyone 
 who writes code that wants to get a machine to use must take them all in to 
 account or else their code is buggy.
 
 That's

[openstack-dev] [oslo] Anticipated Final Release Versions for Juno

I spent some time today looking over our current set of libraries trying to 
anticipate which will be ready for 1.0 (or later) and which are still 
considered pre-release. I came up with this set of anticipated version numbers 
for our final juno releases. Please let me know if you see any surprises on the 
list.

1.0 or later

oslo.config - 1.4.0
oslo.i18n - 1.0.0
oslo.messaging - 1.4.0
oslo.rootwrap - 1.3.0
oslo.serialization - 1.0.0
oslosphinx - 2.2.0
oslotest - 1.1.0
oslo.utils - 1.0.0
cliff - 1.7.x
stevedore - 1.0.0

Alphas or Pre-releases (Trying for 1.0 for Kilo)

oslo.concurrency -  1.0
oslo.log - 0.1.0
oslo.middleware - 0.1.0
pbr -  1.0
taskflow -  1.0

Unknown

oslo.db - I think we said 1.0.0 but I need to confirm.
oslo.vmware - I’ll need to talk to the vmware team to see where things stand 
with their release plans.



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

Re: [openstack-dev] [oslo] Anticipated Final Release Versions for Juno

2014-09-08 Thread Davanum Srinivas

LGTM Doug. for oslo.vmware - we need a fresh rev for use by Nova to
fix the following bug:
https://bugs.launchpad.net/nova/+bug/1341954

thanks,
dims

On Mon, Sep 8, 2014 at 2:32 PM, Doug Hellmann d...@doughellmann.com wrote:
 I spent some time today looking over our current set of libraries trying to 
 anticipate which will be ready for 1.0 (or later) and which are still 
 considered pre-release. I came up with this set of anticipated version 
 numbers for our final juno releases. Please let me know if you see any 
 surprises on the list.

 1.0 or later

 oslo.config - 1.4.0
 oslo.i18n - 1.0.0
 oslo.messaging - 1.4.0
 oslo.rootwrap - 1.3.0
 oslo.serialization - 1.0.0
 oslosphinx - 2.2.0
 oslotest - 1.1.0
 oslo.utils - 1.0.0
 cliff - 1.7.x
 stevedore - 1.0.0

 Alphas or Pre-releases (Trying for 1.0 for Kilo)

 oslo.concurrency -  1.0
 oslo.log - 0.1.0
 oslo.middleware - 0.1.0
 pbr -  1.0
 taskflow -  1.0

 Unknown

 oslo.db - I think we said 1.0.0 but I need to confirm.
 oslo.vmware - I’ll need to talk to the vmware team to see where things stand 
 with their release plans.



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



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

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

[openstack-dev] Error creating instances in DevStack

2014-09-08 Thread Sharan Kumar M

Hi,

I am trying to setup my own OpenStack cloud for development. I installed
DevStack on a VM and the installation is fine. I am able to log in via
Horizon. I followed these steps to create an instance via Horizon.
http://isurues.wordpress.com/tag/devstack/. However, when I launch an
instance, I get the following error.

Failed to launch instance nova: Please try again later [Error: No valid
host was found. ]

I checked if the libvirt_type=qemu in nova.conf. Also the package
nova-compute-qemu is installed. I am using Ubuntu 14.04.

Can someone identify why this problem occurs and how to solve it? What are
the possible causes for this problem?

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

Re: [openstack-dev] Error creating instances in DevStack

2014-09-08 Thread Dean Troyer

On Mon, Sep 8, 2014 at 1:40 PM, Sharan Kumar M sharan.monikan...@gmail.com
wrote:

 I am trying to setup my own OpenStack cloud for development. I installed
 DevStack on a VM and the installation is fine. I am able to log in via

  ...

 I checked if the libvirt_type=qemu in nova.conf. Also the package
 nova-compute-qemu is installed. I am using Ubuntu 14.04.


First thing is you should not combine DevStack and any packaged OpenStack
installation.  DevStack installs from the source repos and has no knowledge
of any decisions made while packaging OpenStack by the distros.

After sorting that out you'll need to dig further into the Nova log files
to see why no working compute node is available.

dt

-- 

Dean Troyer
dtro...@gmail.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Error creating instances in DevStack

2014-09-08 Thread hemant burman

Check your scheduler logs you should be able to figure out whats happening.
If not clear then turn on your logs from info mode to debug in nova.conf.

-Hemant


On Tue, Sep 9, 2014 at 12:10 AM, Sharan Kumar M sharan.monikan...@gmail.com
 wrote:

 Hi,

 I am trying to setup my own OpenStack cloud for development. I installed
 DevStack on a VM and the installation is fine. I am able to log in via
 Horizon. I followed these steps to create an instance via Horizon.
 http://isurues.wordpress.com/tag/devstack/. However, when I launch an
 instance, I get the following error.

 Failed to launch instance nova: Please try again later [Error: No valid
 host was found. ]

 I checked if the libvirt_type=qemu in nova.conf. Also the package
 nova-compute-qemu is installed. I am using Ubuntu 14.04.

 Can someone identify why this problem occurs and how to solve it? What are
 the possible causes for this problem?

 Thanks,
 Sharan Kumar M

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


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

[openstack-dev] [cinder][FFE] request for exceptions in xiv_ds8k driver

2014-09-08 Thread Alon Marx

Hi,

Please consider the following code changes as Feature Freeze Exceptions. 
The first code change is needed to support the latest XIV release (version 
11.5.0) and is very important for us, and the second code change is simply 
support for backups. 

Add domain support for XIV with multitenancy
https://review.openstack.org/#/c/118290/

Add support for backups to xiv_ds8k driver
https://review.openstack.org/#/c/118298/

Both changes were uploaded, reviewed and all relevant changes made by 
Juno-3 date. 
Both changes are very small and simple.
Both changes affect only the xiv_ds8k driver.
Because the changes are small and simple and have no general affect the 
risk is negligible. 

Thank you,
Alon Marx


mobile +972549170122, office +97236897824
email alo...@il.ibm.com
IBM XIV, Cloud Storage Solutions (previously HSG)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Standard virtualenv for docs building

2014-09-08 Thread Joshua Harlow

Hi all,

I just wanted to get some feedback on a change that I think will make the docs 
building process more understood,

Currently there is a script @ 
https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/slave_scripts/run-docs.sh
 (this is the github mirror fyi) that builds your docs when requested using an 
implicit virtualenv 'venv' with a single command `tox -e$venv -- python 
setup.py build_sphinx`. Over the weekend I was working on having the taskflow 
'docs' venv build a changelog and include it in the docs when I learned that 
the 'docs' virtualenv isn't actually what is called when docs are being built 
(and thus can't do customized things to include the changelog).

I wanted to get some some feedback on standardizing around the 'docs' 
virtualenv for docs building (it seems common to use this in most projects 
anyway) and depreciate or remove the implicitly used 'venv' + above command to 
build the docs and just have the infra setup call into the 'docs' virtualenv 
and have it build the docs as appropriate for the project.

This would mean that all projects would at least need the following in there 
tox.ini (if they don't already have it).

[docs]
commands = python setup.py build_sphinx

Does this seem reasonable to all?

There is also a change in the governance repo for this as well @ 
https://review.openstack.org/#/c/119875/

Thoughts, comments, other?

- Josh




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

Re: [openstack-dev] Announcing Gertty 1.0.0: A console interface to Gerrit

2014-09-08 Thread James E. Blair

I just released 1.0.1 with some bug fixes for issues found by early
adopters.  Thanks!

-Jim

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

[openstack-dev] China blocking access to OpenStack git review push

2014-09-08 Thread Thomas Goirand

Am I dreaming, or is the Chinese government is trying to push for the
cloud, they said. However, today, bad surprise:

# nmap -p 29418 23.253.232.87

Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST
Nmap scan report for review.openstack.org (23.253.232.87)
Host is up (0.21s latency).
PORT  STATESERVICE
29418/tcp filtered unknown

Oh dear ... not fun!

FYI, this is from China Unicom (eg: CNC Group)

I'm guessing that this is the Great Firewall of China awesome automated
ban script which detected too many ssh connection to a weird port. It
has blocked a few of my servers recently too, as it became a way too
aggressive. I very much prefer to use my laptop to use git review than
having to bounce around servers. :(

Are their alternative IPs that I could use for review.openstack.org?

Cheers,

Thomas Goirand (zigo)

P.S: If a Chinese official read this, an easy way to unlist (legitimate)
servers access would be the first action any reasonable Chinese
government people must do.

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

Re: [openstack-dev] Kilo Cycle Goals Exercise


On 09/03/2014 12:16 PM, Doug Hellmann wrote:

On Sep 3, 2014, at 11:37 AM, Joe Gordon joe.gord...@gmail.com
mailto:joe.gord...@gmail.com wrote:


As you all know, there has recently been several very active discussions
around how to improve assorted aspects of our development process. One
idea
that was brought up is to come up with a list of cycle goals/project
priorities for Kilo [0].

To that end, I would like to propose an exercise as discussed in the
TC meeting yesterday [1]:
Have anyone interested (especially TC members) come up with a list of
what they think the project wide Kilo cycle goals should be and post
them on this thread by end of day Wednesday, September 10th. After
which time we can begin discussing the results.
The goal of this exercise is to help us see if our individual world
views align with the greater community, and to get the ball rolling on
a larger discussion of where as a project we should be focusing more time.


Thanks for starting this discussion, Joe. It’s important for us to start
working on “OpenStack” as a whole, in addition to our individual projects.


Agreed. Thank you, Joe.


1. Sean has done a lot of analysis and started a spec on standardizing
logging guidelines where he is gathering input from developers,
deployers, and operators [1]. Because it is far enough for us to see
real progress, it’s a good place for us to start experimenting with how
to drive cross-project initiatives involving code and policy changes
from outside of a single project. We have a couple of potentially
related specs in Oslo as part of the oslo.log graduation work [2] [3],
but I think most of the work will be within the applications.


No surprise, I'm a huge +1 on this.


2. A longer-term topic is standardizing our notification content and
format. See the thread Treating notifications as a contract” for
details. We could set a goal for Kilo of establishing the requirements
and proposing a spec, with implementation to begin in L.


+1.


3. Another long-term topic is standardizing our APIs so that we use
consistent terminology and formatting (I think we have at least 3 forms
of errors returned now?). I’m not sure we have anyone ready to drive
this, yet, so I don’t think it’s something to consider for Kilo.


+10

Frankly, I believe this should be our #1 priority from a cross-project 
perspective.


The inconsistencies in the current APIs (even within the same project's 
APIs!) is just poor form and since our REST APIs are the very first 
impression that we give to the outside developer community, it really is 
incumbent on us to make sure they are explicit, free of side-effects, 
well-documented, consistent, easy-to-use, and hide implementation 
details thoroughly.



4. I would also like to see the unified SDK and command line client
projects continued (or resumed, I haven’t been following the SDK work
closely). Both of those projects will eventually make using OpenStack
clouds easier. It would be nice to see some movement towards a “user
tools” program to encompass both of these projects, perhaps with an eye
on incubation at the end of Kilo.


+1


5. And we should also be considering the Python 3 porting work. We’ve
made some progress with the Oslo libraries, with oslo.messaging 
eventlet still our main blocker. We need to put together a more concrete
plan to finish that work and for tackling applications, as well as a
team willing to help projects through their transition. This is very
long term, but does need attention, and I think it’s reasonable to ask
for a plan by the end of Kilo.


+0 (only because I don't consider it a priority compared with the other 
things you've documented here)



 From a practical standpoint, we do need to work out details like where
we make decisions about the plans for these projects once the general
idea is approved. We’ve done some of this in the Oslo project in the
past (log translations, for example) but I don’t think that’s the right
place for projects at this scale. A new openstack-specs repository would
give us a place to work on them, but we need to answer the question of
how to decide what is approved.


An openstack-specs repo might indeed be a nice place to put this 
cross-project, OpenStack-wide type of stuff.


Best,
-jay


Doug




best,
Joe Gordon

[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/041929.html
[1]
http://eavesdrop.openstack.org/meetings/tc/2014/tc.2014-09-02-20.04.log.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org

Re: [openstack-dev] China blocking access to OpenStack git review push

2014-09-08 Thread Clark Boylan

On Mon, Sep 8, 2014, at 12:20 PM, Thomas Goirand wrote:
 Am I dreaming, or is the Chinese government is trying to push for the
 cloud, they said. However, today, bad surprise:
 
 # nmap -p 29418 23.253.232.87
 
 Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST
 Nmap scan report for review.openstack.org (23.253.232.87)
 Host is up (0.21s latency).
 PORT  STATESERVICE
 29418/tcp filtered unknown
 
 Oh dear ... not fun!
 
 FYI, this is from China Unicom (eg: CNC Group)
 
 I'm guessing that this is the Great Firewall of China awesome automated
 ban script which detected too many ssh connection to a weird port. It
 has blocked a few of my servers recently too, as it became a way too
 aggressive. I very much prefer to use my laptop to use git review than
 having to bounce around servers. :(
 
 Are their alternative IPs that I could use for review.openstack.org?
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 P.S: If a Chinese official read this, an easy way to unlist (legitimate)
 servers access would be the first action any reasonable Chinese
 government people must do.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

As an alternative to pushing via ssh you can push via https over port
443 which may bypass this port blockage. Both latest git review and the
version of gerrit that we are running support this.

The first step is to generate a gerrit http password, this will be used
to authenticate against Gerrit. Go to
https://review.openstack.org/#/settings/http-password and generate a
password there (note this is independent of your launchpad openid
password).

Next step is to get some code clone it from eg
https://git.openstack.org/openstack-dev/sandbox. Now I am sure there is
a better way to have git-review do this for you with config overrides
somewhere but we need to add a git remote in that repo called 'gerrit'.
By default all of our .gitreview files set this up for ssh so we will
manually add one. `git remote add gerrit
https://usern...@review.openstack.org/openstack-dev/sandbox`. Finally
run `git review -s` to get the needed commit hook and now you are ready
to push code with `git review` as you normally would. Note when git
review asks for a password it will want the password we generated in the
first step.

I am pretty sure this is can be made easier and the manual git remote
step is not required if you set up some overrides in git(review) config
files. Maybe the folks that added https support for git review can fill
us in.

Clark

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

Re: [openstack-dev] [cinder][FFE] request for exceptions in xiv_ds8k driver

2014-09-08 Thread Jay S. Bryant

Alon,

Thanks, I have added your request to the etherpad
https://etherpad.openstack.org/p/juno-cinder-approved-ffes and it will
undergo review.

Thanks,
Jay


On Mon, 2014-09-08 at 21:55 +0300, Alon Marx wrote:
 Hi, 
 
 Please consider the following code changes as Feature Freeze
 Exceptions. 
 The first code change is needed to support the latest XIV release
 (version 11.5.0) and is very important for us, and the second code
 change is simply support for backups. 
 
 Add domain support for XIV with multitenancy 
 https://review.openstack.org/#/c/118290/ 
 
 Add support for backups to xiv_ds8k driver 
 https://review.openstack.org/#/c/118298/ 
 
 Both changes were uploaded, reviewed and all relevant changes made by
 Juno-3 date. 
 Both changes are very small and simple. 
 Both changes affect only the xiv_ds8k driver. 
 Because the changes are small and simple and have no general affect
 the risk is negligible. 
 
 Thank you, 
 Alon Marx 
 
 
 mobile +972549170122, office +97236897824
 email alo...@il.ibm.com
 IBM XIV, Cloud Storage Solutions (previously HSG) 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Fuel] Doc team working with bugs

2014-09-08 Thread Anne Gentle

On Mon, Sep 8, 2014 at 9:04 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 09/08/2014 03:46 AM, Dmitry Mescheryakov wrote:

 Hello Fuelers,

 On the previous meeting a topic was raised on how Fuel doc team should
 work with bugs, see [1] for details. We agreed to move the discussion
 into the mailing list.

 The thing is there are two members in the team at the moment (Meg and
 Irina) and they need to distribute work among themselves. The natural
 way to distribute load is to assign bugs. But frequently they document
 bugs which are in the process of being fixed, so they are already
 assigned to an engineer. I.e. a bug needs to be assigned to an
 engineer and a tech writer at the same time.

 I've proposed to create a separate series 'docs' in launchpad (it is
 the thing like '5.0.x', '5.1.x'). If bug affects several series, a
 different engineer could be assigned on each of them. So doc team will
 be free to assign bugs to themselves within this new series.

 Mike Scherbakov and Dmitry Borodaenko objected creating another series
 in launchpad. Instead they proposed to mark bugs with tags like
 'docs-irina' and 'docs-meg' thus assigning them.

 What do you think is the best way to handle this? As for me, I don't
 have strong preference there.

 One last note: the question applies to two launchpad projects
 actually: Fuel and MOS. But naturally we want to do this the same way
 in both projects.


 Hi Dmitry!

 Good question and problem! :) This limitation of Launchpad has bugged me
 for some time (pun intended). It would be great to have the ability to
 assign a bug to more than one person.

 I actually think using tags is more appropriate here. Series are intended
 for releasable things. And since we'd never be releasing just a docs
 package, having a docs series doesn't really work. So, though it's a bit
 kludgy, I think using tags is the best solution here.


Thanks to you both for noting! Yes, I agree tags are the best solution with
Launchpad.

Love that you're thinking about how to pair-bug-squash!

Anne



 All the best,
 -jay


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

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

Re: [openstack-dev] Standard virtualenv for docs building

2014-09-08 Thread Monty Taylor


On 09/08/2014 11:59 AM, Joshua Harlow wrote:

Hi all,

I just wanted to get some feedback on a change that I think will make the docs 
building process more understood,

Currently there is a script @ 
https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/slave_scripts/run-docs.sh
 (this is the github mirror fyi) that builds your docs when requested using an 
implicit virtualenv 'venv' with a single command `tox -e$venv -- python 
setup.py build_sphinx`. Over the weekend I was working on having the taskflow 
'docs' venv build a changelog and include it in the docs when I learned that 
the 'docs' virtualenv isn't actually what is called when docs are being built 
(and thus can't do customized things to include the changelog).

I wanted to get some some feedback on standardizing around the 'docs' 
virtualenv for docs building (it seems common to use this in most projects 
anyway) and depreciate or remove the implicitly used 'venv' + above command to 
build the docs and just have the infra setup call into the 'docs' virtualenv 
and have it build the docs as appropriate for the project.

This would mean that all projects would at least need the following in there 
tox.ini (if they don't already have it).

[docs]
commands = python setup.py build_sphinx

Does this seem reasonable to all?

There is also a change in the governance repo for this as well @ 
https://review.openstack.org/#/c/119875/

Thoughts, comments, other?


For those who like numbers, across all of the repos in gerrit that have 
docs dirs, 11 need to have a doc env renamed to docs, and 9 need one 
added - all of the rest of the repos, including every integrated repo, 
has a docs env already.



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

Re: [openstack-dev] [neutron] [nova] non-deterministic gate failures due to unclosed eventlet Timeouts


On 09/07/2014 10:43 AM, Matt Riedemann wrote:

On 9/7/2014 8:39 AM, John Schwarz wrote:

Hi,

Long story short: for future reference, if you initialize an eventlet
Timeout, make sure you close it (either with a context manager or simply
timeout.close()), and be extra-careful when writing tests using
eventlet Timeouts, because these timeouts don't implicitly expire and
will cause unexpected behaviours (see [1]) like gate failures. In our
case this caused non-deterministic failures on the dsvm-functional test
suite.


Late last week, a bug was found ([2]) in which an eventlet Timeout
object was initialized but not closed. This instance was left inside
eventlet's inner-workings and triggered non-deterministic Timeout: 10
seconds errors and failures in dsvm-functional tests.

As mentioned earlier, initializing a new eventlet.timeout.Timeout
instance also registers it to inner mechanisms that exist within the
library, and the reference remains there until it is explicitly removed
(and not until the scope leaves the function block, as some would have
thought). Thus, the old code (simply creating an instance without
assigning it to a variable) left no way to close the timeout object.
This reference remains throughout the life of a worker, so this can
(and did) effect other tests and procedures using eventlet under the
same process. Obviously this could easily effect production-grade
systems with very high load.

For future reference:
  1) If you run into a Timeout: %d seconds exception whose traceback
includes hub.switch() and self.greenlet.switch() calls, there might
be a latent Timeout somewhere in the code, and a search for all
eventlet.timeout.Timeout instances will probably produce the culprit.

  2) The setup used to reproduce this error for debugging purposes is a
baremetal machine running a VM with devstack. In the baremetal machine I
used some 6 dd if=/dev/zero of=/dev/null to simulate high CPU load
(full command can be found at [3]), and in the VM I ran the
dsvm-functional suite. Using only a VM with similar high CPU simulation
fails to produce the result.

[1]
http://eventlet.net/doc/modules/timeout.html#eventlet.timeout.eventlet.timeout.Timeout.Timeout.cancel

[2] https://review.openstack.org/#/c/119001/
[3]
http://stackoverflow.com/questions/2925606/how-to-create-a-cpu-spike-with-a-bash-command



--
John Schwarz,
Software Engineer, Red Hat.


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



Thanks, that might be what's causing this timeout/gate failure in the
nova unit tests. [1]

[1] https://bugs.launchpad.net/nova/+bug/1357578


Indeed, there are a couple places where eventlet.timeout.Timeout() seems 
to be used in the test suite without a context manager or calling 
close() explicitly:


tests/virt/libvirt/test_driver.py
8925:raise eventlet.timeout.Timeout()

tests/virt/hyperv/test_vmops.py
196:mock_with_timeout.side_effect = etimeout.Timeout()

Best,
-jay

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

Re: [openstack-dev] China blocking access to OpenStack git review push

2014-09-08 Thread Matt Riedemann




On 9/8/2014 2:20 PM, Thomas Goirand wrote:

Am I dreaming, or is the Chinese government is trying to push for the
cloud, they said. However, today, bad surprise:

# nmap -p 29418 23.253.232.87

Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST
Nmap scan report for review.openstack.org (23.253.232.87)
Host is up (0.21s latency).
PORT  STATESERVICE
29418/tcp filtered unknown

Oh dear ... not fun!

FYI, this is from China Unicom (eg: CNC Group)

I'm guessing that this is the Great Firewall of China awesome automated
ban script which detected too many ssh connection to a weird port. It
has blocked a few of my servers recently too, as it became a way too
aggressive. I very much prefer to use my laptop to use git review than
having to bounce around servers. :(

Are their alternative IPs that I could use for review.openstack.org?

Cheers,

Thomas Goirand (zigo)

P.S: If a Chinese official read this, an easy way to unlist (legitimate)
servers access would be the first action any reasonable Chinese
government people must do.

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



Yeah the IBM DB2 third party CI is run from a team in China and they've 
been blocked for a few weeks now.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [rally] KeyError: 'admin'

2014-09-08 Thread Boris Pavlovic

Daisuke,


This patch https://review.openstack.org/#/c/116766/ introduced this bug:
https://bugs.launchpad.net/rally/+bug/1366824
That was fixed by this commit: https://review.openstack.org/#/c/119790/

So update your rally and try one more time. Everything should work now.


Best regards,
Boris Pavlovic

On Mon, Sep 8, 2014 at 4:05 PM, Daisuke Morita morita.dais...@lab.ntt.co.jp
 wrote:


 Thanks, Boris.

 I tried rally-manage db recreate before registering a deployment, but
 nothing changed at all in running Tempest...

 It is late in Japan, so I will try it tomorrow.


 Best regards,
 Daisuke

 On 2014/09/08 20:38, Boris Pavlovic wrote:

 Daisuke,

 We have as well changes in our DB models.

 So running:

$ rally-manage db recreate

 Will be as well required..


 Best regards,
 Boris Pavlovic



 On Mon, Sep 8, 2014 at 3:24 PM, Mikhail Dubov mdu...@mirantis.com
 mailto:mdu...@mirantis.com wrote:

 Hi Daisuke,

 seems like your issue is connected to the change in the deployment
 configuration file format for existing clouds we've merged
 https://review.openstack.org/#/c/116766/ recently.

 Please see the updated Wiki How to page
 https://wiki.openstack.org/wiki/Rally/HowTo#Step_1._
 Deployment_initialization_.28use_existing_cloud.29 that
 describes the new format. In your case, you can just update the
 deployment configuration file and run again /rally deployment
 create/. Everything should work then.



 Best regards,
 Mikhail Dubov

 Mirantis, Inc.
 E-Mail: mdu...@mirantis.com mailto:mdu...@mirantis.com
 Skype: msdubov

 On Mon, Sep 8, 2014 at 3:16 PM, Daisuke Morita
 morita.dais...@lab.ntt.co.jp mailto:morita.dais...@lab.ntt.co.jp

 wrote:


 Hi, rally developers!

 Now, I am trying to use Rally to devstack cluster on AWS VM
 (all-in-one). I'm following a blog post
 https://www.mirantis.com/blog/rally-openstack-tempest-
 testing-made-simpler/
 . I successfully installed Devstack, Rally and Tempest. Now, I
 just ran
 Tempest by 'rally verify start' command, but the command failed
 with the
 following stacktrace.


 2014-09-08 10:57:57.803 17176 CRITICAL rally [-] KeyError: 'admin'
 2014-09-08 10:57:57.803 17176 TRACE rally Traceback (most recent
 call last):
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/bin/rally,
 line 10, in module
 2014-09-08 10:57:57.803 17176 TRACE rally sys.exit(main())
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/cmd/main.py, line
 40, in main
 2014-09-08 10:57:57.803 17176 TRACE rally return
 cliutils.run(sys.argv, categories)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/cmd/cliutils.py,
 line
 184, in run
 2014-09-08 10:57:57.803 17176 TRACE rally ret = fn(*fn_args,
 **fn_kwargs)
 2014-09-08 10:57:57.803 17176 TRACE rally   File string,
 line 2, in
 start
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/cmd/envutils.py,
 line 64,
 in default_from_global
 2014-09-08 10:57:57.803 17176 TRACE rally return f(*args,
 **kwargs)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/cmd/
 commands/verify.py,
 line 59, in start
 2014-09-08 10:57:57.803 17176 TRACE rally
  api.verify(deploy_id,
 set_name, regex)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/
 orchestrator/api.py,
 line
 153, in verify
 2014-09-08 10:57:57.803 17176 TRACE rally
 verifier.verify(set_name=set_name, regex=regex)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/
 verification/verifiers/tempest/tempest.py,
 line 247, in verify
 2014-09-08 10:57:57.803 17176 TRACE rally
 self._prepare_and_run(set_name, regex)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/utils.py, line
 165, in
 wrapper
 2014-09-08 10:57:57.803 17176 TRACE rally result = f(self,
 *args,
 **kwargs)
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/
 verification/verifiers/tempest/tempest.py,
 line 146, in _prepare_and_run
 2014-09-08 10:57:57.803 17176 TRACE rally
   self.generate_config_file()
 2014-09-08 10:57:57.803 17176 TRACE rally   File
 /usr/local/lib/python2.7/dist-packages/rally/
 verification/verifiers/tempest/tempest.py,
 line 89,

Re: [openstack-dev] Kilo Cycle Goals Exercise

2014-09-08 Thread Mathieu Gagné


On 2014-09-07 8:14 PM, Monty Taylor wrote:


If I were king ...

1. Caring about end user experience at all

If I don't do anything at all next cycle, I will see the above fixed.
Because it's embarrassing. Seriously. Try to use OpenStack from python
some time. I dare you.


 [...]


Between 2 and 3, maybe we can make a kilo release that has a net
negative SLOC count. But, honestly, screw 2 and 3 - let's all just work
on 1.



On 2014-09-08 5:07 PM, James E. Blair wrote:

 3) A real SDK

 OpenStack is so nearly impossible to use, that we have a substantial
 amount of code in the infrastructure program to do things that,
 frankly, we are a bit surprised that the client libraries don't do.
 Just getting an instance with an IP address is an enormous challenge,
 and something that took us years to get right.  We still have problems
 deleting instances.  We need client libraries (an SDK if you will) and
 command line clients that are easy for users to understand and work
 with, and hide the gory details of how the sausage is made.


I 100% agree with both of you. The user experience is a MAJOR concern 
for us. I'm not a good writer able to articulate my thoughts as good as 
I would like but both Monty and James managed to communicate and 
summarize them.


As a technical person, I often don't see the level of complexity in 
tools I use, I like challenges. I will gladly learn new complex stuff if 
needed. But when I first tried to use OpenStack client libraries, it was 
one of those times where I told myself: wow, it sucks. Especially around 
lack of consistency. Or as Monty said, the number of hoops you have to 
go through just to get a pingable instance. And it was and still is the 
opinion shared by some of my coworkers.


If we could improve this aspect, I would be so happy.

--
Mathieu

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

[openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

2014-09-08 Thread Joe Gordon

Hi All,

We have recently started seeing assorted memory issues in the gate
including the oom-killer [0] and libvirt throwing memory errors [1].
Luckily we run ps and dstat on every devstack run so we have some insight
into why we are running out of memory. Based on the output from job taken
at random [2][3] a typical run consists of:

* 68 openstack api processes alone
* the following services are running 8 processes (number of CPUs on test
nodes)
  * nova-api (we actually run 24 of these, 8 compute, 8 EC2, 8 metadata)
  * nova-conductor
  * cinder-api
  * glance-api
  * trove-api
  * glance-registry
  * trove-conductor
* together nova-api, nova-conductor, cinder-api alone take over 45 %MEM
(note: some of that is memory usage is counted multiple times as RSS
includes shared libraries)
* based on dstat numbers, it looks like we don't use that much memory
before tempest runs, and after tempest runs we use a lot of memory.

Based on this information I have two categories of questions:

1) Should we explicitly set the number of workers that services use in
devstack? Why have so many workers in a small all-in-one environment? What
is the right balance here?

2) Should we be worried that some OpenStack services such as nova-api,
nova-conductor and cinder-api take up so much memory? Does there memory
usage keep growing over time, does anyone have any numbers to answer this?
Why do these processes take up so much memory?

best,
Joe


[0]
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwib29tLWtpbGxlclwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiIxNzI4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDEwMjExMjA5NzY3fQ==
[1] https://bugs.launchpad.net/nova/+bug/1366931
[2] http://paste.openstack.org/show/108458/
[3]
http://logs.openstack.org/83/119183/4/check/check-tempest-dsvm-full/ea576e7/logs/screen-dstat.txt.gz
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo] Puppet elements support

2014-09-08 Thread Emilien Macchi

Hi TripleO community,

I would be really interested by helping to bring Puppet elements support
in TripleO.
So far I've seen this work:
https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat
which is a very good bootstrap but really outdated.
After some discussion with Greg Haynes on IRC, we came up with the idea
to create a repo (that would be move in Stackforge or OpenStack git) and
push the bits from what has been done by HP folks with updates 
improvements.

I started a basic repo
https://github.com/enovance/tripleo-puppet-elements that could be moved
right now on Stackforge to let the community start the work.

My proposal is:
* move this repo (or create a new one directly on
github/{stackforge,openstack?})
* push some bits from agroup original work.
* continue the contributions, updates  improvements.

Any thoughts?

-- 
Emilien Macchi




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

Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)