Re: [openstack-dev] [Zaqar] How to get the pool list in graceful way.

[Flavio Percoco]

On 10/09/2014 03:37 AM, Lei Zhang wrote:
> The question comes from my patch[1]. Kgriffs point that there are two
> way to get all the pools. But I don’t know which one is better, event
> though I comment that limit=0 is wired. I think there are three ways.
> 
> use limit=0( current logical).
> pro: 1) may easy to implement
> con: 1) not clearly and wired. 2) may some storage driver doesn’t support?
> call .list multiple times
> pro: 1) directly and compatiblely
> con: 1) multiple request must make when the list size is too large.
> define a new method named list_all
> 
> [1] https://review.openstack.org/#/c/123462/5/zaqar/queues/storage/pooling.py
> 

Kurt was referring to whether `limit=0` is consistent throughout the
storage drivers. I think `limit=None` is what we want here since it
explicitly says we don't want any limit.

We'll need to document this and make this part of the contract for
drivers implementations.

Thanks for bringing it up,
Flavio

-- 
@flaper87
Flavio Percoco

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

Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns

[Roman Podoliaka]

Hi Mike,

Great stuff! Fixing the mess with transactions and their scope is
probably one of the most important tasks for us, IMO. I look forward
for this to be implemented in oslo.db and consuming projects!

Thanks,
Roman

On Thu, Oct 9, 2014 at 12:07 AM, Mike Bayer  wrote:
> Hi all -
>
> I’ve drafted up my next brilliant idea for how to get Openstack projects to 
> use SQLAlchemy more effectively.   The proposal here establishes significant 
> detail on what’s wrong with the current state of things, e.g. the way I see 
> EngineFacade, get_session() and get_engine() being used, and proposes a new 
> system that provides a true facade around a managed context.   But of course, 
> it requires that you all change your code!  (a little bit).  Based on just a 
> few tiny conversations on IRC so far, seems like this might be a hard sell.  
> But please note, most projects are pretty much broken in how they use the 
> database - this proposal is just a first step to making it all non-broken, if 
> not as amazing and cool as some people wish it could be.  Unbreaking the code 
> and removing boilerplate is the first step - with sane and declarative 
> patterns in place, we can then build in more bells and whistles.
>
> Hoping you’re all super curious now, here it is!  Jump in:  
> https://review.openstack.org/#/c/125181/
>
> - mike
>
>
>
>
>
>
>
> ___
> 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] [Fuel] Contribution to fuel-library: new requirements for reviews

[Mike Scherbakov]

This discussion should go in the public, as not every developer is here,
and other opinions are important.

I believe that we are again diverting the conversation into a few
directions. Let's address things one by one, and feel free to spin off new
discussions out of this thread. After original email from Sergii, what I'm
trying to achieve here - is to formalize new requirements for code review
process. I suggest to start with something very small and limited -
approving the code into master. I think rules should change, and reviews
should have:

   - at least one Subject Matter Expert (SME)'s +1
   - Core developer should not merge if there are no other +1th or +2th
   - Recommended to have two core reviews of complicated / suspicious
   patches
   - Must have at least two core reviews for patches which change reference
   architecture

Thanks,

From: Vladimir Kuklin 
Date: Mon, Oct 6, 2014 at 6:12 PM
Subject: Re: Contribution to fuel-library
To: Anastasia Urlapova 
Cc: Aleksandr Didenko , Andrey Danin <
ada...@mirantis.com>, Partner Integrations Team , Mike
Scherbakov , Sergii Golovatiuk <
sgolovat...@mirantis.com>, fuel-core-team 


Nastya,

I do not think modular testing blueprint is the right place to write this
checklist down. I think, we need, first of all, create corresponding
jenkins jobs and make them dry-run until there is implementation ready for
them. E.g. we almost do already have --noop implementation support. Let's
finally add it as a job to CI. And let's do not run actual deployments
until CI passes syntax and noop verification, for example.

On Mon, Oct 6, 2014 at 6:07 PM, Anastasia Urlapova 
wrote:

> Alex,
> could you update
> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
> according your ideas and suggestions.
>
> Thanks,
>  Nastya.
>
> On Mon, Oct 6, 2014 at 3:53 PM, Aleksandr Didenko 
> wrote:
>
>> I would also add rspec testing to the CI as well:
>>
>> a) code linting
>> b) syntax checking
>> c) [in future] rake spec testing
>> d) noop dry run test
>> e) [in future] deployment modules tests
>> f) system tests
>> g) [in future] integration tests
>>
>> On Mon, Oct 6, 2014 at 2:34 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Ok, guys, I would suggest to start with formalization of requirements
>>> for code review in Fuel Library, as there is no such page on Fuel wiki. I
>>> think that workflow should be as following:
>>>
>>> 1) Code itself should be reviewed manually
>>> 2) Unit tests should be written by the developer himself. Other tests
>>> should be written by QA and/or developers
>>> 3) All the other criteria should be checked by CI automatically - there
>>> MUST be no manual process:
>>> a) code linting
>>> b) syntax checking
>>> c) noop dry run test
>>> d) [in future] deployment modules tests
>>> e) system tests
>>> f) [in future] integration tests
>>> 4) [In Future] each request can be accepted only after related upstream
>>> manifests bug is created and a review request for particular change is
>>> opened
>>>
>>> Some of these points are marked for future. But we can enable them as
>>> soon as corresponding testing code is written and CI infrastructure is
>>> ready.
>>>
>>> On Mon, Oct 6, 2014 at 1:28 PM, Andrey Danin 
>>> wrote:
>>>

 +PI team
 Please, keep us in this discussion. We are interested in it a lot.

 On Mon, Oct 6, 2014 at 12:31 AM, Aleksandr Didenko <
 adide...@mirantis.com> wrote:

> Hi,
>
> > On #1, I'd love to hear more information and suggested workflow. I
> know only something short like "propose contribution to upstream module
> first, then to fuel-library"; I think we need more details, and make sure
> everyone knows and follows.
>
> First of all, I think everybody who wants to contribute into
> fuel-library should know some Puppet DSL basics and also read
> puppet-openstack dev docs [1] and our dev docs [2]
>
> Since we start merging upstream manifests, the most common and general
> rule is: upstream modules should be modified only with bugfixes and
> improvements everyone in the community could benefit from. And appropriate
> patch should be proposed to the upstream project. In other cases (like
> applying our own logic or settings) we should do it in our own modules or
> in "openstack::*" classes (fuel-library/deployment/puppet/openstack), 
> like:
> openstack::compute, openstack::cinder. I think, our main goal should be:
> use all the community modules "as is". This is why we need to contribute 
> to
> the upstream projects.
>
> So the workflow for contributing into fuel-library should be something
> like this:
>
> 1. Check what module you're contributing to and where is its upstream
> (if any). You can check this via Modulefile located in the most of puppet
> modules we use:
>fuel-library/deployment/puppet/*MODULE*/Modulefile
> For example:
>fuel-library/deployment/puppe

Re: [openstack-dev] [nova] gerrit based statistics

[Daniel P. Berrange]

On Wed, Oct 08, 2014 at 04:30:16PM -0700, Joe Gordon wrote:
> Recently there has been a lot of discussion around the development growing
> pains in nova. Instead of guessing about how bad some of the issues are, I
> tried to answer a few questions that may help us better understand the
> issues.

What time period did you calculate these stats over ? One whole dev
cycle ?

> Q: How many revisions does it take to merge a patch?
> 
> Average: 6.76 revisions
> median: 4.0 revisions
> 
> 
> Q: How many rechecks/verifies does it take to merge a patch (ignoring
> rechecks where the same job failed before and after)?
> 
> Average: 0.749 rechecks per patch revision
> median: 0.4285  rechecks per patch revision

These feel really low to me, but I guess that is a consequence of
aggregating over a long time period.

> For comparison here are the same results for tempest, which has a lot more
> gating tests:
> 
> Average: 1.01591525738
> median: 0.6
> 
> 
> Q: How long does it take for a patch to get approved?
> 
> Average: 28 days
> median: 11 days
> 
> 
> Q: How long does it take for a patch to get approved that touches
> 'nova/virt/'?
> 
> Average: 34 days
> median: 18 days
> 
> 
> When looking at these numbers two things stick out out:
> 
> * We successfully use recheck an awful lot. More then I expected
> * Patches that touch 'nova/virt' take about 20% more time to land or about
> 6 days. While that is definitely a difference, its smaller then I expected
> 
> 
> Dataset: last 800 patches in nova
> Code: https://github.com/jogo/gerrit-fun

Ah ok, so I think what would be more informative is to caculate the
stats on weekly blocks and graph it over 2 cycles. There are certainly
times when the problems are much worse than others and a long term
average will mask that to a large extent. It is the periods when it is
particularly bad that are leading to the high frustration amongst
contributors IMHO, so we must look at the worst cases.

For example look at the stats I produced for patch review comments per
core team reviewer:

  https://www.berrange.com/~dan/novacodeandspecsreviewrate.png

The gap betweeen good weeks and bad weeks is enourmous.


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

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

[openstack-dev] [Nova] Questions on glance alternative link

[Chen CH Ji]

Hi
in nova/api/openstack/compute/views/images.py, there is a
function returns alternate links which contains project_id
However, I didn't see any info in glance API V2 spec
Can any one help me on :

1) what's the purpose of alternate link? can I remove the project_id? maybe
backward compatible issue?
2) if #1 's answer is negative, should we add a image api under nova/image/
to also generate a link with project_id?

 Thanks

def _get_alternate_link(self, request, identifier):
"""Create an alternate link for a specific image id."""
glance_url = glance.generate_glance_url()
glance_url = self._update_glance_link_prefix(glance_url)
return '/'.join([glance_url,
 request.environ["nova.context"].project_id, <---
this is the line which add project_id
 self._collection_name,
 str(identifier)])

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Let me propose another approach. I agree with most of Dmitry's statements
and it seems in MVP we need plugin management UI where we can enable
installed plugins. It should be a separate page. If you want to create
environment with a plugin, enable the plugin on this page and create a new
environment. You can also disable and uninstall plugins using that page (if
there is no environments with the plugin enabled).

The main reason why I'm against Evgeniy's 2nd approach (explicitly enabling
plugins in the wizard) is that we need to add a step where we choose the
plugins. This step should be added right after choice of environment name
and release, because options on the next steps and even steps could be
added from plugins. And this is complete disaster for UX. Imagine a new
user which uses Fuel for the first time and has to decide which plugins he
will use right after giving a name to an environment.

So I think if we implement plugin management page and make user explicitly
and globally enable installed plugins there we can implement Evgeniy's 2nd
approach, but in a slightly different way. I think we need to use all
enabled plugins for new environments by default and let user to uncheck
some of them, so they won't be used for that particular environment. I
think the checkboxes should be right on the first pane under release
selectbox (it makes sense because different releases could have different
plugins available). These checkboxes should be hidden by default and only
appear after user clicks a button named like "customize used plugins". I
think we should use the word "use" here instead of "enable" as we "enable"
plugins on the plugin management page.

The plugin management page and explicit enabling of plugins are also
required for plugins with an UI part as we need to preload it when UI loads
and not when the wizard opens as the plugin can contain mixins for the
wizard.

What do you think?

2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko :

> I don't like how this discussion is framed. The initial premise that we
> have
> only two controversial options to choose from is lazy. If there is no
> consensus, we should look for more options, not for a popular vote.
>
> Secondly, current level of UX is not negotiable. You can't take something
> that
> we already have and that works (and current Fuel UI is the best out there
> by a
> wide margin), and make it worse just to add a new feature. Even something
> as
> important as plugins must be an incremental improvement.
>
> With that premise, lets decompose the problem.
>
> 1. There are two levels of settings related to any plugin: a) first you
> have to
> enable enable the plugin itself; b) when the plugin is enabled, it may
> expose
> additional settings.
>
> - How can it be acceptable to have all plugins always enabled in all
>   environments? Do you really trust all plugin writers to carefully check
> for
>   plugin-specific options and ensure there is zero impact on an
> environment if
>   none of its options are enabled?
>
> - If all your plugins are enabled everywhere, you can't uninstall any of
> them
>   because all environments you deployed would become unmanageable.
>
> - If you ignore uninstallation, soon you will be stuck with plugins that
> cannot
>   be made removable even when Fuel itself begins to support it.
>
> - To break away from unremovable plugins, you're likely going to have to
> break
>   backwards compatibility (unless you already have a forward-compatible
> design
>   that allows for removable plugins in the future, but then you wouldn't
> have
>   to exclude removing plugins from MVP).
>
> - And if a Fuel upgrade ever requires uninstalling a plugin due to
>   irreconcilable incompatibility, and they're enabled in all of your
>   environments, you're stuck unable to upgrade.
>
> So, lets not enable any plugins by default. And if we can come up with a
> way to
> make them removable (when they're not enabled in any deployed
> environments), we
> should at least leave room for that in the design.
>
> 2. Either level of plugin settings (enable or configure) may be exposed in
> setup wizard, settings page, or both.
>
> - Yes, additional plugin settings also may show up in the wizard (e.g.
> vCenter
>   credentials).
>
> - Yes, we should maintain the settings page as the SSoT, and that means
>   reflecting as many of setup wizard options in it as possible.
>
> - Yes, for some options (like choice of operating system or network
> topology),
>   our settings page is not dynamic enough to allow user to go back and
> revert
>   them without recreating the environment.
>
> - No, plugin writer shouldn't have to explicitly describe a checkbox to
> enable
>   their plugin. They only should provide name and description of the
> plugin.
>   Plugin engine should be able to produce a catalogue of installed
> plugins, and
>   UI should generate enable checkboxes from that catalogue.
>
> - If a plugin doesn't affect any available environment configuration
> o

Re: [openstack-dev] [all][oslo][db][docs] RFC: drop support for libpq < 9.1

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/10/14 18:05, Mike Bayer wrote:
> 
> On Oct 7, 2014, at 8:29 AM, Ihar Hrachyshka 
> wrote:
> 
>> 
>> That said, I wonder how we're going to manage cases when those 
>> *global* settings for the whole server should be really limited
>> to specific databases. Isn't it better to enforce utf8 on service
>> side, since we already know that we always run against utf8
>> database?
> 
> I think whenever we do a ?CREATE DATABASE?, we should make sure the
> desired encodings are set up at that level.  I?ve seen lots of
> migration scripts that are listing through tables and setting each
> table individually to utf-8, and that?s less than ideal, though I
> suppose that?s more of a retroactive fix.
> 
>> 
>> Please let me clarify... Do you say that setting client encoding
>> on oslo.db side is actually ok? I haven't suggested to enforce
>> utf8 per column/table, though I guess we're already there.
> 
> The way we are setting client encoding now should be fine, if you
> could clarify what about that isn?t working for PG 8.4 that would
> be helpful.IMHO especially on Postgresql we should be able to
> get away with not having it.   MySQLdb is not as nicely implemented
> as far as encoding (including the use_unicode speed issues) so it
> may be more necessary there.

PostgreSQL part is more for consistency with MySQL, but also to avoid
enforcing users to set utf8 globally for their SQL server. I think the
less we demand on configuration level the better (assuming we decided
on using utf8 globally for all our databases).

> 
> But yes what I really *dont* want is the encoding set up on every
> column definition, e.g. ?VARCHAR(20) CHARACTER SET ?utf-8??, that?s
> been suggested before and that would be terrible.   I don?t think
> Postgresql has quite the same thing available (only collation per
> column).
> 
>> 
>> Forgoing, again, means some users running with utf8 client
>> encoding, others without it. I strive towards consistency here,
>> that's why I try to find a way to set the setting for all clients
>> we support (and the question is *which* of those clients we
>> really support).
>> 
>> The thing that is not supported in psql < 9.1 is a connection
>> option added to libpq as of: 
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=02e14562a806a96f38120c96421d39dfa7394192
>
>> 
> OK but that is just the connection parameter, when you pass
> client_encoding to SQLAlchemy?s psycopg2 dialect, the encoding is
> set using psycopg2?s set_client_encoding() method:
> http://initd.org/psycopg/docs/connection.html#connection.set_client_encoding.
> This ultimately emits ?SET client_encoding TO ?utf8?? on the
> connection:
> 
> conn_set_client_encoding ->
> https://github.com/psycopg/psycopg2/blob/master/psycopg/connection_int.c#L1188
>
>  pq_set_guc_locked ->
> https://github.com/psycopg/psycopg2/blob/master/psycopg/pqpath.c#L709
>
>  ?SET client_encoding TO ? is supported in all Postgresql
> versions, here?s 8.0:
> http://www.postgresql.org/docs/8.0/static/multibyte.html
> 
> So there?s no issue with Postgresql 8.2 here as far as client
> encoding, the libpq feature isn?t used for that.   Also, it
> defaults to the encoding that is set for the database (e.g. server
> side), so if we make sure CREATE DATABASE is emitted with the
> encoding, then we wouldn?t even need to set it (and perhaps we
> shouldn?t if the database is set to a different encoding).

As was revealed during IRC discussion with Mike, libpq
'client_encoding' and SQLAlchemy 'client_encoding' are different
beasts, and we have the latter into our possession when using libpq <
9.1, so it's better to use that one to avoid raising a minimum version
bar.

> 
> 
> 
> 
> 
> ___ OpenStack-dev
> mailing list OpenStack-dev@lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNn5OAAoJEC5aWaUY1u57Y98H/2PGpZg4IeUKPqT2IGRtCOp3
Ln52cJ3ew/unL0n1JdBW/CAYuN2/c8jsFeWsFGG4P7zMrLh+AFUtmq/4xQShyLkM
YimaCzziN3beojVjPOKCYhMNNnS83pS7FIDXdEn/cdadFliiDX7m5rjMG40l9WOD
JFR5WfWPFrvura4VUDMjStmgFANxuxLboDy95xmdVomSL9m4Ms+/OZOPkcrV39Iu
H3scbIgZVEd8SZ1lpEQYMO4QXgSSfgEV+3efQbZADLYO8ig82a4h+nVN1079RAos
DfgxRdu1kK5NaPUFxbtbxhhTYbIuKRHf183tv6qJv6uPHgo06sLe5ie+is2q4LA=
=kSU1
-END PGP SIGNATURE-

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

Re: [openstack-dev] ./run_tests.sh fails to create the .venv environment for neutron

[Ihar Hrachyshka]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/10/14 01:55, Vasudevan, Swaminathan (PNB Roseville) wrote:
> Hi Folks,
> 
> 
> 
> ./run_tests.sh fails to create the .venv with the latest neutron
> repo.
> 
> It fails at MySQL-python.
> 
> Does anyone know what is broken.

You probably miss libmysqlclient-devel package installed from your
distribution repos.

/Ihar
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUNoDIAAoJEC5aWaUY1u57jo4IALh9FaEsICHxKoaNjtlmTey9
F9+DQicJOwc/Iw22U+zY9d1AnuBz7P+xLvGLqavsVdEvYdbZSlT4OKUCBiTovseV
pit3WiUFjVhXcLlUS3aKfjkX4mHwHTBIWQEZvf0jEVQRTSnIAv3x0TbCuXDJ9vcB
Luf4PcFoqMFW/PVFYkSXhEQ4WMrPcTcNNdy5AqdpVrkntviR+oyHONvYSizjhIda
raiMtgWYZvAigXz62Bul13B42AJVIhzFMeFnN5d1enV41ZlgJje/Dgqf1e8YC87z
v7aXbUiEolTZvCpjO1jL/uBmuOBkGeltrMW4XWv0WJD7SqsW9ridNuHdXV2yMfc=
=TA77
-END PGP SIGNATURE-

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

[openstack-dev] [compute][nova] Provide an option to ignore suspended VMs in the resource count

[Arthur Lutz]

Hi list,

Here is proposal previously posted on
https://bugs.launchpad.net/nova/+bug/1378233

It would be very useful for our case scenario to be able to have an
option that enables not counting suspended machines as consuming
resources. The use case is having little memory available and still
being able to launch new VMs when old VMs are in suspended mode. We
understand that once the compute node's memory is full we won't be able
to resume these machines, but that is OK with the way we're using our cloud.

For example a compute node with 8G of RAM, launch 1 VM with 4G and
another with 2G, then suspend them both, one could then launch a new VM
with 4G of RAM (the actual memory on the compute node is free).

On essex we had the following patch for this scenario to work :

Index: nova/nova/scheduler/host_manager.py
===
--- nova.orig/nova/scheduler/host_manager.py
+++ nova/nova/scheduler/host_manager.py
@@ -337,6 +337,8 @@ class HostManager(object):
 if not host:
 continue
 host_state = host_state_map.get(host, None)
+ if instance.get('power_state', 1) != 1: # power_state.RUNNING
+ continue
 if not host_state:
 continue
 host_state.consume_from_instance(instance)

We're looking into patching icehouse for the same behaviour but would
like to add it as an option this time.

If you have any comments on this before I write up a blueprint and nova
spec, they would be welcome.

Arthur

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

[openstack-dev] [Heat] Juno RC2 available

[Thierry Carrez]

Hello everyone,

One week to final release! Due to a number of issues discovered in the
published Heat 2014.2 RC1, we generated a new Juno release candidate.
You can find the list of bugfixes in this RC and a link to a source
tarball at:

https://launchpad.net/heat/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Heat 2014.2 on
October 16. You are therefore strongly encouraged to test and validate
this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/heat/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/heat/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
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] [nova] gerrit based statistics

[Russell Bryant]

On 10/08/2014 07:30 PM, Joe Gordon wrote:
> Recently there has been a lot of discussion around the development
> growing pains in nova. Instead of guessing about how bad some of the
> issues are, I tried to answer a few questions that may help us better
> understand the issues.
> 
> 
> Q: How many revisions does it take to merge a patch?
> 
> Average: 6.76 revisions
> median: 4.0 revisions
> 
> 
> Q: How many rechecks/verifies does it take to merge a patch (ignoring
> rechecks where the same job failed before and after)?
> 
> Average: 0.749 rechecks per patch revision
> median: 0.4285  rechecks per patch revision
> 
> For comparison here are the same results for tempest, which has a lot
> more gating tests:
> 
> Average: 1.01591525738
> median: 0.6
> 
> 
> Q: How long does it take for a patch to get approved?
> 
> Average: 28 days
> median: 11 days
> 
> 
> Q: How long does it take for a patch to get approved that touches
> 'nova/virt/'?
> 
> Average: 34 days
> median: 18 days
> 
> 
> When looking at these numbers two things stick out out:
> 
> * We successfully use recheck an awful lot. More then I expected
> * Patches that touch 'nova/virt' take about 20% more time to land or
> about 6 days. While that is definitely a difference, its smaller then I
> expected
> 
> 
> Dataset: last 800 patches in nova
> Code: https://github.com/jogo/gerrit-fun

Some related stats on open code reviews:

http://russellbryant.net/openstack-stats/nova-openreviews.html

I don't have historical data, which would be really useful.  However,
based on my memory and an old ML post [1], these numbers have tripled
for Nova since mid 2013.

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-June/011043.html

-- 
Russell Bryant

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

[openstack-dev] TC Candidacy

[John Garbutt]

Hi,

I would like to run for a seat on the Technical Committee, to help
serve the whole OpenStack community during this time of change.

I am employed by Rackspace, working on their public cloud. I am
currently focus mostly on Nova. I am nova-core, and currently nova's
blueprint czar. I am johnthetubaguy on IRC.

I started contributing to OpenStack, working as a researcher at Citrix
in December 2010. I helped create Citrix's Project Olympus packaging
of OpenStack (nova, swift and glance). After "a change in strategy" I
started working more on making OpenStack work with XenServer, setting
up one of the first Nova sub groups. After my move to Rackspace in
February 2013, I was able to work on all parts of Nova, and quickly
got more involved with a wider range of upstream activities.

I find the work of building a consensus really rewarding. I don't
claim to have all the answers, but I know we need change, so we can
scale out the community, while at the same time we preserving the true
nature of this awesome community.


** Topic: OpenStack Mission
** How do you feel the technical community is doing in meeting the
OpenStack Mission?

Its a bold mission, and I think it is still the right one.

"serve developers, users, and the entire ecosystem"
I think we need to be better at the serving the entire ecosystem.

Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community,
we should learn to embrace the diversity, where goals don't quite
align. But we still want it to be easy for anyone to join in with any
exiting effort people are working on. People invest in competing
startups.

On the other side of the coin, its hard for our users to know what
combinations of drivers give you are working system, and a system that
solves the problems the user wants to solve. Distros and consultants
are helping fix that. But I am not sure the Vendors always know what
they need to participate in the most useful ways.

We need to better understand what "interoperability" means with this
broader scope. But making it easy for people to use multiple different
OpenStack implementations is important. Nova API should always behave
like Nova API, Cinder API should always behave like Cinder API, etc.


** Topic: Technical Committee Mission
** How do you feel the technical committee is doing in meeting the
technical committee mission?

TC is clearly aways striving to do better, and trying out new ideas,
which is great.

Evolving the concept of the integrated release is clearly key to
making the system scale. There seems to have been much friction over
the incubation process.

Helping share what has worked well between all the projects, seems key
to providing technical leadership at large scale. Thats starting to
happen, which is cool.

Should the TC reduce its scope to some small number of projects? I am
not sure. Maybe there needs to be a different group setup to deal with
the specifics related to that group of projects? Maybe ttx's cross
project meeting is already the beginnings of that group?


** Topic: Contributor Motivation
** How would you characterise the various facets of contributor motivation?

I feel we are a community of problem solvers, and wanting to
collaborate and make an impact.

Many of us do this work as (some or all) for our full time jobs. That
leads to people being put into a position where the problems they are
able to work on can be constrained by their employer.

We need to get better at educating those who employ people working on
OpenStack, on how they can get the best out of their investment. For
example, not testing things upstream, is really going to hurt.


** Topic: Rate of Growth
** There is no argument the OpenStack technical community has a
substantial rate of growth. What are some of the consequences of this
rate?

Yes, its hurting, and it touches everything. But thats fun, and brings
new ideas, and challenges, which keeps us evolving and adapting. We
need to take care to unlearn things that get in the way too.


** Topic: New Contributor Experience
** How would you characterize the experience new contributors have currently?

I enjoyed how I was welcomed into the OpenStack community. But it was
scary then, and it has to be worse now. We all need to do our part to
be open and welcoming to people.

But we should probably look at who is leaving our community. I
certainly see people step back due to frustrated with the contribution
process. Sometimes burning out after feeling like their ideas are
"torn to shreds" or feel like the are battling pointless bureaucracy.
The solutions are hard, but it feels like getting better at
documenting the "intent" of a process, would help, better setting of
expectations around how debates will work, would help. I find rather
than trying to "merge my patch", its better to collaborate in "solving
my problem".


** Topic: Communication
** How would you describe our current state of communication in the
OpenStack community?

Its not terrible. I think we could do bette

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

Hi,

Vitaly, I like the idea of having separate page, but I'm not sure if it
should be on releases page.
Usually a plugin is not release specific, usually it's environment specific
and you can have
different set of plugins for different environments.

Also I don't think that we should enable plugins by default, user should
enable plugin if he wants
it to be installed.

Thanks,

On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh 
wrote:

> Let me propose another approach. I agree with most of Dmitry's statements
> and it seems in MVP we need plugin management UI where we can enable
> installed plugins. It should be a separate page. If you want to create
> environment with a plugin, enable the plugin on this page and create a new
> environment. You can also disable and uninstall plugins using that page (if
> there is no environments with the plugin enabled).
>
> The main reason why I'm against Evgeniy's 2nd approach (explicitly
> enabling plugins in the wizard) is that we need to add a step where we
> choose the plugins. This step should be added right after choice of
> environment name and release, because options on the next steps and even
> steps could be added from plugins. And this is complete disaster for UX.
> Imagine a new user which uses Fuel for the first time and has to decide
> which plugins he will use right after giving a name to an environment.
>
> So I think if we implement plugin management page and make user explicitly
> and globally enable installed plugins there we can implement Evgeniy's 2nd
> approach, but in a slightly different way. I think we need to use all
> enabled plugins for new environments by default and let user to uncheck
> some of them, so they won't be used for that particular environment. I
> think the checkboxes should be right on the first pane under release
> selectbox (it makes sense because different releases could have different
> plugins available). These checkboxes should be hidden by default and only
> appear after user clicks a button named like "customize used plugins". I
> think we should use the word "use" here instead of "enable" as we "enable"
> plugins on the plugin management page.
>
> The plugin management page and explicit enabling of plugins are also
> required for plugins with an UI part as we need to preload it when UI loads
> and not when the wizard opens as the plugin can contain mixins for the
> wizard.
>
> What do you think?
>
> 2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko :
>
>> I don't like how this discussion is framed. The initial premise that we
>> have
>> only two controversial options to choose from is lazy. If there is no
>> consensus, we should look for more options, not for a popular vote.
>>
>> Secondly, current level of UX is not negotiable. You can't take something
>> that
>> we already have and that works (and current Fuel UI is the best out there
>> by a
>> wide margin), and make it worse just to add a new feature. Even something
>> as
>> important as plugins must be an incremental improvement.
>>
>> With that premise, lets decompose the problem.
>>
>> 1. There are two levels of settings related to any plugin: a) first you
>> have to
>> enable enable the plugin itself; b) when the plugin is enabled, it may
>> expose
>> additional settings.
>>
>> - How can it be acceptable to have all plugins always enabled in all
>>   environments? Do you really trust all plugin writers to carefully check
>> for
>>   plugin-specific options and ensure there is zero impact on an
>> environment if
>>   none of its options are enabled?
>>
>> - If all your plugins are enabled everywhere, you can't uninstall any of
>> them
>>   because all environments you deployed would become unmanageable.
>>
>> - If you ignore uninstallation, soon you will be stuck with plugins that
>> cannot
>>   be made removable even when Fuel itself begins to support it.
>>
>> - To break away from unremovable plugins, you're likely going to have to
>> break
>>   backwards compatibility (unless you already have a forward-compatible
>> design
>>   that allows for removable plugins in the future, but then you wouldn't
>> have
>>   to exclude removing plugins from MVP).
>>
>> - And if a Fuel upgrade ever requires uninstalling a plugin due to
>>   irreconcilable incompatibility, and they're enabled in all of your
>>   environments, you're stuck unable to upgrade.
>>
>> So, lets not enable any plugins by default. And if we can come up with a
>> way to
>> make them removable (when they're not enabled in any deployed
>> environments), we
>> should at least leave room for that in the design.
>>
>> 2. Either level of plugin settings (enable or configure) may be exposed in
>> setup wizard, settings page, or both.
>>
>> - Yes, additional plugin settings also may show up in the wizard (e.g.
>> vCenter
>>   credentials).
>>
>> - Yes, we should maintain the settings page as the SSoT, and that means
>>   reflecting as many of setup wizard options in it as possible.
>>
>> - Yes, for some options (l

Re: [openstack-dev] [Heat] Juno RC2 available

[Martinx - ジェームズ]

Congrats  :-D

On 9 October 2014 09:52, Thierry Carrez  wrote:

> Hello everyone,
>
> One week to final release! Due to a number of issues discovered in the
> published Heat 2014.2 RC1, we generated a new Juno release candidate.
> You can find the list of bugfixes in this RC and a link to a source
> tarball at:
>
> https://launchpad.net/heat/juno/juno-rc2
>
> Unless new release-critical issues are found that warrant a release
> candidate respin, this RC2 will be formally released as Heat 2014.2 on
> October 16. You are therefore strongly encouraged to test and validate
> this tarball !
>
> Alternatively, you can directly test the proposed/juno branch at:
> https://github.com/openstack/heat/tree/proposed/juno
>
> If you find an issue that could be considered release-critical, please
> file it at:
>
> https://bugs.launchpad.net/heat/+filebug
>
> and tag it *juno-rc-potential* to bring it to the release crew's
> attention.
>
> Regards,
>
> --
> Thierry Carrez (ttx)
>
> ___
> 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] TC Candidacy

[Tristan Cacqueray]

confirmed

On 09/10/14 09:07 AM, John Garbutt wrote:
> Hi,
> 
> I would like to run for a seat on the Technical Committee, to help
> serve the whole OpenStack community during this time of change.
> 
> I am employed by Rackspace, working on their public cloud. I am
> currently focus mostly on Nova. I am nova-core, and currently nova's
> blueprint czar. I am johnthetubaguy on IRC.
> 
> I started contributing to OpenStack, working as a researcher at Citrix
> in December 2010. I helped create Citrix's Project Olympus packaging
> of OpenStack (nova, swift and glance). After "a change in strategy" I
> started working more on making OpenStack work with XenServer, setting
> up one of the first Nova sub groups. After my move to Rackspace in
> February 2013, I was able to work on all parts of Nova, and quickly
> got more involved with a wider range of upstream activities.
> 
> I find the work of building a consensus really rewarding. I don't
> claim to have all the answers, but I know we need change, so we can
> scale out the community, while at the same time we preserving the true
> nature of this awesome community.
> 
> 
> ** Topic: OpenStack Mission
> ** How do you feel the technical community is doing in meeting the
> OpenStack Mission?
> 
> Its a bold mission, and I think it is still the right one.
> 
> "serve developers, users, and the entire ecosystem"
> I think we need to be better at the serving the entire ecosystem.
> 
> Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community,
> we should learn to embrace the diversity, where goals don't quite
> align. But we still want it to be easy for anyone to join in with any
> exiting effort people are working on. People invest in competing
> startups.
> 
> On the other side of the coin, its hard for our users to know what
> combinations of drivers give you are working system, and a system that
> solves the problems the user wants to solve. Distros and consultants
> are helping fix that. But I am not sure the Vendors always know what
> they need to participate in the most useful ways.
> 
> We need to better understand what "interoperability" means with this
> broader scope. But making it easy for people to use multiple different
> OpenStack implementations is important. Nova API should always behave
> like Nova API, Cinder API should always behave like Cinder API, etc.
> 
> 
> ** Topic: Technical Committee Mission
> ** How do you feel the technical committee is doing in meeting the
> technical committee mission?
> 
> TC is clearly aways striving to do better, and trying out new ideas,
> which is great.
> 
> Evolving the concept of the integrated release is clearly key to
> making the system scale. There seems to have been much friction over
> the incubation process.
> 
> Helping share what has worked well between all the projects, seems key
> to providing technical leadership at large scale. Thats starting to
> happen, which is cool.
> 
> Should the TC reduce its scope to some small number of projects? I am
> not sure. Maybe there needs to be a different group setup to deal with
> the specifics related to that group of projects? Maybe ttx's cross
> project meeting is already the beginnings of that group?
> 
> 
> ** Topic: Contributor Motivation
> ** How would you characterise the various facets of contributor motivation?
> 
> I feel we are a community of problem solvers, and wanting to
> collaborate and make an impact.
> 
> Many of us do this work as (some or all) for our full time jobs. That
> leads to people being put into a position where the problems they are
> able to work on can be constrained by their employer.
> 
> We need to get better at educating those who employ people working on
> OpenStack, on how they can get the best out of their investment. For
> example, not testing things upstream, is really going to hurt.
> 
> 
> ** Topic: Rate of Growth
> ** There is no argument the OpenStack technical community has a
> substantial rate of growth. What are some of the consequences of this
> rate?
> 
> Yes, its hurting, and it touches everything. But thats fun, and brings
> new ideas, and challenges, which keeps us evolving and adapting. We
> need to take care to unlearn things that get in the way too.
> 
> 
> ** Topic: New Contributor Experience
> ** How would you characterize the experience new contributors have currently?
> 
> I enjoyed how I was welcomed into the OpenStack community. But it was
> scary then, and it has to be worse now. We all need to do our part to
> be open and welcoming to people.
> 
> But we should probably look at who is leaving our community. I
> certainly see people step back due to frustrated with the contribution
> process. Sometimes burning out after feeling like their ideas are
> "torn to shreds" or feel like the are battling pointless bureaucracy.
> The solutions are hard, but it feels like getting better at
> documenting the "intent" of a process, would help, better setting of
> expectations around how debates will wo

Re: [openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

[Robert Li (baoli)]

Hi Thiago,

A couple of things to consider:
  ― As it is now, it doesn’t seem to be fully functional if you change your 
subnet to use SLAAC. The addresses that were assigned to your existing ports in 
neutron wouldn’t be updated/changed. So basically, you can not simply make an 
API call to change the subnet and expect that everything will be setup 
correctly. Not mention that currently subnet api to update the modes can’t even 
be invoked.

  ― if you want to use SLAAC, there might be a couple of ways to do that
. Once multiple prefix is supported, you can create a new slaac subnet 
in the same network. Obviously you need to use a different prefix. Later, you 
can remove the previous subnet.
. For now, you can create a new network with a slaac subnet. And attach 
your VMs to this new network. Once it’s done, you can remove the previous 
network.

Hope that it helps
Robert

On 10/8/14, 10:25 PM, "Martinx - ジェ�`ムズ" 
mailto:thiagocmarti...@gmail.com>> wrote:

Hi!

Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN Provider 
Network + static IPv6.

I created the subnet(s) like this (one for each tenant):

--
neutron net-create --tenant-id $ID --provider:physical_network=physnet1 
--provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200

neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID 
physnet1-vlan200 2001:db8:1::/64 --allocation-pool 
start=2001:db8:1::8000,end=2001:db8:1:0::::fffe
--

This new BUGs means that, after upgrading to Juno, I'll not be able to "update 
/ convert" this static network to SLAAC ?!?!

If yes, how can I force the update without breaking the production environment? 
Is there a procedure to follow?

I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN, neither a 
radvd controlled by Neutron. My upstream router already have radvd ready.

Thanks!
Thiago

On 7 October 2014 13:21, Henry Gessau 
mailto:ges...@cisco.com>> wrote:
A number of bugs[1][2][3] have been filed which are related to updating the
IPv6 attributes after a subnet has been created.

In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
questions have been raised, which were discussed in today's IPv6 IRC meeting[6].

Summary:
In Juno we are not ready for allowing the IPv6 attributes on a subnet to be
updated after the subnet is created, because:
- The implementation for supporting updates is incomplete.
- Perceived lack of usefulness, no good use cases known yet.
- Allowing updates causes more complexity in the code.
- Have not tested that radvd, dhcp, etc. behave OK after update.

Therefore we are proposing to change 'allow_put' to False for the two IPv6
attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes
from being updated via the PUT:subnets API.

We would be interested to hear of any disagreements or questions.


[1] https://launchpad.net/bugs/1362966
[2] https://launchpad.net/bugs/1363064
[3] https://launchpad.net/bugs/1373417
[4] https://review.openstack.org/125328
[5] https://review.openstack.org/117799
[6]
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.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

Re: [openstack-dev] [Keystone][Oslo] User mapping and X509 for signing

[John Dennis]

On 10/08/2014 04:58 PM, Adam Young wrote:
> When gyee posted his X509 server-side auth plugin patch,  the feedback 
> we gave was that it should be using the mapping code from Federation to 
> transform the environment variables set by the web server to the 
> Keystone userid, username, domain name, and so forth.
> 
> The PKI token format currently allows for a single signing cert.  I have 
> a proposal to allow for multiple signers.  One issue, though, is how to 
> map from the certificates signer-info to the Keystone server that signed 
> the data.   signer-data is part of the CMS message format, and can be 
> used to uniquely identify the certificate that signed the document.  
>  From the signer-data, we can fetch the certificate.
> 
> SO, we could build a system that allowed us to fetch multiple certs for 
> checking signatures.  But then the question is, which cert maps to "the 
> entity authorized to sign for this data."
> 
> OpenStack lacks a way to enumerate the systems, endpoints or otherwise.  
> I'm going to propose that we create a service domain and that any system 
> responsible for signing a document have a user created inside that 
> domain.  I think we want to make the endpoint id match the user ID for 
> endpoints, and probably something comparable for Nova Compute services.
> 
> This means we can use the associated keystone user to determine what 
> Compute node signed a message.  It gives us PKI based, asymetric Oslo 
> message signing.
> 
> This same abstraction should be extended to Kite for symmetric keys.
> 
> In order to convert the certificate data to the Keystone User ID, we can 
> use the Mapping mechanism from Federation, just like we are planning on 
> for the X509 Auth Plugin.
> 
> One thing I want to make explicit, and get some validation on from the 
> community:  is it acceptable to say that there needs to be a mappable 
> link between AL  X509 certificates distributed by a certain CA, for a 
> certain Domain and the users in there?  It seems to me to be comparable 
> to the LDAP constraints.  Is this a reasonable assumption?  If not, it 
> seems like the X509 mechanism is really not much more than a naked 
> Public Key.

I don't fully understand your proposal, perhaps because a few details
were omitted. But here are my thoughts and let me know where I might
have misunderstood.

The mapping seems pretty straight forward to me thus I'm not sure I see
the need for an extra service and the associated complexity. You should
be able extract the signer subject from the signing data as well as the
signer's issuer information. Given that it's a simple lookup whose
mapping can be trivially managed using any of the key/value tables
available to Keystone, one only needs to populate that table in some
authoritative way, but that's mostly a deployment issue.

I also don't follow what you mean by "not much more than a naked Public
Key", can you elaborate?


-- 
John

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

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Vitaly Kramskikh]

Evgeniy,

Yes, the plugin management page should be a separate page. As for
dependency on releases, I meant that some plugin can work only on Ubuntu
for example, so for different releases different plugins could be available.

And please confirm that you also agree with the flow: the user install a
plugin, then he enables it on the plugin management page, and then he
creates an environment and on the first step he can uncheck some plugins
which he doesn't want to use in that particular environment.

2014-10-09 20:11 GMT+07:00 Evgeniy L :

> Hi,
>
> Vitaly, I like the idea of having separate page, but I'm not sure if it
> should be on releases page.
> Usually a plugin is not release specific, usually it's environment
> specific and you can have
> different set of plugins for different environments.
>
> Also I don't think that we should enable plugins by default, user should
> enable plugin if he wants
> it to be installed.
>
> Thanks,
>
> On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh 
> wrote:
>
>> Let me propose another approach. I agree with most of Dmitry's statements
>> and it seems in MVP we need plugin management UI where we can enable
>> installed plugins. It should be a separate page. If you want to create
>> environment with a plugin, enable the plugin on this page and create a new
>> environment. You can also disable and uninstall plugins using that page (if
>> there is no environments with the plugin enabled).
>>
>> The main reason why I'm against Evgeniy's 2nd approach (explicitly
>> enabling plugins in the wizard) is that we need to add a step where we
>> choose the plugins. This step should be added right after choice of
>> environment name and release, because options on the next steps and even
>> steps could be added from plugins. And this is complete disaster for UX.
>> Imagine a new user which uses Fuel for the first time and has to decide
>> which plugins he will use right after giving a name to an environment.
>>
>> So I think if we implement plugin management page and make user
>> explicitly and globally enable installed plugins there we can implement
>> Evgeniy's 2nd approach, but in a slightly different way. I think we need to
>> use all enabled plugins for new environments by default and let user to
>> uncheck some of them, so they won't be used for that particular
>> environment. I think the checkboxes should be right on the first pane under
>> release selectbox (it makes sense because different releases could have
>> different plugins available). These checkboxes should be hidden by default
>> and only appear after user clicks a button named like "customize used
>> plugins". I think we should use the word "use" here instead of "enable" as
>> we "enable" plugins on the plugin management page.
>>
>> The plugin management page and explicit enabling of plugins are also
>> required for plugins with an UI part as we need to preload it when UI loads
>> and not when the wizard opens as the plugin can contain mixins for the
>> wizard.
>>
>> What do you think?
>>
>> 2014-10-09 11:04 GMT+07:00 Dmitry Borodaenko :
>>
>>> I don't like how this discussion is framed. The initial premise that we
>>> have
>>> only two controversial options to choose from is lazy. If there is no
>>> consensus, we should look for more options, not for a popular vote.
>>>
>>> Secondly, current level of UX is not negotiable. You can't take
>>> something that
>>> we already have and that works (and current Fuel UI is the best out
>>> there by a
>>> wide margin), and make it worse just to add a new feature. Even
>>> something as
>>> important as plugins must be an incremental improvement.
>>>
>>> With that premise, lets decompose the problem.
>>>
>>> 1. There are two levels of settings related to any plugin: a) first you
>>> have to
>>> enable enable the plugin itself; b) when the plugin is enabled, it may
>>> expose
>>> additional settings.
>>>
>>> - How can it be acceptable to have all plugins always enabled in all
>>>   environments? Do you really trust all plugin writers to carefully
>>> check for
>>>   plugin-specific options and ensure there is zero impact on an
>>> environment if
>>>   none of its options are enabled?
>>>
>>> - If all your plugins are enabled everywhere, you can't uninstall any of
>>> them
>>>   because all environments you deployed would become unmanageable.
>>>
>>> - If you ignore uninstallation, soon you will be stuck with plugins that
>>> cannot
>>>   be made removable even when Fuel itself begins to support it.
>>>
>>> - To break away from unremovable plugins, you're likely going to have to
>>> break
>>>   backwards compatibility (unless you already have a forward-compatible
>>> design
>>>   that allows for removable plugins in the future, but then you wouldn't
>>> have
>>>   to exclude removing plugins from MVP).
>>>
>>> - And if a Fuel upgrade ever requires uninstalling a plugin due to
>>>   irreconcilable incompatibility, and they're enabled in all of your
>>>   environments, you're stu

[openstack-dev] [Nova] object field naming question

[Murray, Paul (HP Cloud)]

Hi All,

The following question relates to this change:

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

This change adds a field to the ComputeNode object called 
"supported_instances". It also adds an object called "SupportedInstance" that 
has fields called "arch", "hvtype" and "vm_mode".

All these names already exist in the nova code, but when put together in these 
objects they seem a little odd (i.e. supported_instances may be a little 
misleading, hvtype has no hyphen but vm_mode does). This is where they come 
from:


-  supported_instances is the name of the corresponding field of the 
compute_nodes database table. The supported_instances field actually contains a 
the list of architecture, hypervisor type and vm_mode combinations supported by 
the compute node. It is also the existing field name used in a dict provided by 
the virt drivers to report this list to nova.


-  arch, hvtype and vm_mode are the names used by variables throughout 
nova that refer to the relevant data obtained contained in supported_instances.

The question is: are these the names we actually want to use?

The reason I ask is that once the names are used for Nova object fields, the 
nova object versions would need to be bumped to change them. So if they are 
going to change, now would be a good time to put the right thing in the objects 
(the rest of nova could be changed subsequently).

So, do you think supported_instances should be something else, e.g. 
supported_hv_properties? (The SupportedInstance object name can follow this 
one.) Please make a suggestion if you think it should change.

Do you think we should have hyphens or not in hvtype and vm_mode (note, vm_mode 
occurs 160+ times in nova and vmmode occurs 12 times, whereas occurrence of 
hv_type vs hvtype has the opposite bias).

In fact, is there a convention that should be followed that I have forgotten 
about (or never knew)?

Let me know opinions and I will fix the patch accordingly.

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

Re: [openstack-dev] [nova] gerrit based statistics

[Matt Riedemann]

On 10/8/2014 9:21 PM, Joe Gordon wrote:



On Wed, Oct 8, 2014 at 6:12 PM, Michael Still mailto:mi...@stillhq.com>> wrote:

On Thu, Oct 9, 2014 at 11:58 AM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote:
 > On Wed, Oct 8, 2014 at 4:30 PM, Joe Gordon mailto:joe.gord...@gmail.com>> wrote:
 >>
 >> Recently there has been a lot of discussion around the
development growing
 >> pains in nova. Instead of guessing about how bad some of the
issues are, I
 >> tried to answer a few questions that may help us better
understand the
 >> issues.
 >>
 >>
 >> Q: How many revisions does it take to merge a patch?
 >>
 >> Average: 6.76 revisions
 >> median: 4.0 revisions
 >>
 >>
 >> Q: How many rechecks/verifies does it take to merge a patch
(ignoring
 >> rechecks where the same job failed before and after)?
 >>
 >> Average: 0.749 rechecks per patch revision
 >> median: 0.4285  rechecks per patch revision
 >>
 >> For comparison here are the same results for tempest, which has
a lot more
 >> gating tests:
 >>
 >> Average: 1.01591525738
 >> median: 0.6
 >>
 >>
 >> Q: How long does it take for a patch to get approved?
 >>
 >> Average: 28 days
 >> median: 11 days
 >>
 >>
 >> Q: How long does it take for a patch to get approved that touches
 >> 'nova/virt/'?
 >>
 >> Average: 34 days
 >> median: 18 days
 >>
 >
 > To expand on these numbers, same results for last 6 months of
commits:
 >
 > all of nova (1723 patches):
 > Average: 28.8
 > median: 11.0
 >
 > nova/virt (476 patches):
 >  Average: 34.5

I think it would be interesting to break this up by driver
directory... Are there drivers which take longer to land code for than
others?


Like this?

subtree: None (1724 patches):
Average: 28.7
median: 11.0
subtree: nova/virt/ (476 patches):
Average: 34.5
median: 18.0
subtree: nova/virt/hyperv/ (38 patches):
Average: 46.8
median: 33.0
subtree: nova/virt/libvirt/ (224 patches):
Average: 35.9
median: 18.0
subtree: nova/virt/xenapi/ (72 patches):
Average: 39.5
median: 20.0
subtree: nova/virt/vmwareapi/ (134 patches):
Average: 38.7
median: 26.0

>> When looking at these numbers two things stick out out:
>>
>> * We successfully use recheck an awful lot. More then I expected
>> * Patches that touch 'nova/virt' take about 20% more time to land or 
about
>> 6 days. While that is definitely a difference, its smaller then I 
expected
>>
>>
>> Dataset: last 800 patches in nova
>> Code:https://github.com/jogo/gerrit-fun
>
>
>
 > ___
 > OpenStack-dev mailing list
 > OpenStack-dev@lists.openstack.org

 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >

Michael

--
Rackspace Australia

___
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



That's the distribution, percentage-wise, I'd expect to see for the 4 
in-tree virt drivers.


--

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] OpenStack Havana End of Upstream Support Lifetime

[Jeremy Stanley]

On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
[...]
> the tips of these branches have been tagged "havana-eol" in
> preparation for branch deletion. The list of affected Git
> repositories is as follows:
> 
> openstack-dev/devstack
> openstack-dev/grenade
> openstack/ceilometer
> openstack/cinder
> openstack/designate
> openstack/glance
> openstack/heat
> openstack/horizon
> openstack/keystone
> openstack/neutron
> openstack/nova
> openstack/openstack-manuals
> openstack/oslo-incubator
> openstack/oslo.config
> openstack/requirements
> openstack/swift
> openstack/tempest
> openstack/trove

Just following up to note that I finally removed the stable/havana
branches of the above mentioned projects, in accordance with the EOL
announcement from a couple weeks ago.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Nova] object field naming question

[Daniel P. Berrange]

On Thu, Oct 09, 2014 at 01:45:43PM +, Murray, Paul (HP Cloud) wrote:
> Hi All,
> 
> The following question relates to this change:
> 
> https://review.openstack.org/#/c/125091/
> 
> This change adds a field to the ComputeNode object called 
> "supported_instances". It also adds an object called "SupportedInstance" that 
> has fields called
> "arch", "hvtype" and "vm_mode".
> 
> All these names already exist in the nova code, but when put together in
> these objects they seem a little odd (i.e. supported_instances may be a
> little misleading, hvtype has no hyphen but vm_mode does). This is where
> they come from:
> 
> -  supported_instances is the name of the corresponding field of
>  the compute_nodes database table. The supported_instances field actually
>  contains a the list of architecture, hypervisor type and vm_mode
>  combinations supported by the compute node. It is also the existing
>  field name used in a dict provided by the virt drivers to report this
>  list to nova.
> 
> 
> -  arch, hvtype and vm_mode are the names used by variables
>   throughout nova that refer to the relevant data obtained contained
>   in supported_instances.
> 
> The question is: are these the names we actually want to use?

I'd like to just kill the underscore in 'vm_mode' as I don't think it
adds any real value.

> Let me know opinions and I will fix the patch accordingly.

I don't think we want to block your patch on this item. We can just do a
cleanup afterwards, rather than mixing it in with your patch.

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

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

Re: [openstack-dev] [Nova] object field naming question

[Jay Pipes]

On 10/09/2014 10:16 AM, Daniel P. Berrange wrote:

On Thu, Oct 09, 2014 at 01:45:43PM +, Murray, Paul (HP Cloud) wrote:

Hi All,

The following question relates to this change:

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

This change adds a field to the ComputeNode object called "supported_instances". It also 
adds an object called "SupportedInstance" that has fields called
"arch", "hvtype" and "vm_mode".

All these names already exist in the nova code, but when put together in
these objects they seem a little odd (i.e. supported_instances may be a
little misleading, hvtype has no hyphen but vm_mode does). This is where
they come from:

-  supported_instances is the name of the corresponding field of
  the compute_nodes database table. The supported_instances field actually
  contains a the list of architecture, hypervisor type and vm_mode
  combinations supported by the compute node. It is also the existing
  field name used in a dict provided by the virt drivers to report this
  list to nova.


-  arch, hvtype and vm_mode are the names used by variables
   throughout nova that refer to the relevant data obtained contained
   in supported_instances.

The question is: are these the names we actually want to use?


I'd like to just kill the underscore in 'vm_mode' as I don't think it
adds any real value.


The value it adds (and that an underscore would add in hvtype -> 
hv_type) is that the name would match the naming style for the vast 
majority of everything else in OpenStack. See, for examples:


 We use vm_state not vmstate. power_state, not powerstate, port_status 
not portstatus, disk_container not diskcontainer, etc.



Let me know opinions and I will fix the patch accordingly.


I don't think we want to block your patch on this item. We can just do a
cleanup afterwards, rather than mixing it in with your patch.


As mentioned in the review, I disagree on this point, since "doing a 
cleanup afterwards" would mean having to increment the 
nova.objects.SupportedInstance model VERSION as soon as it went into 
master. I say let's make the quick change now and avoid having to write 
code like this in the next patchset:


 if client_version <= (1,0):
# We renamed hvtype to hv_type in 1.1
self.hv_type = fields.get('hvtype')

Best,
-jay

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

Re: [openstack-dev] [Nova] object field naming question

[Jay Pipes]

On 10/09/2014 09:45 AM, Murray, Paul (HP Cloud) wrote:

Hi All,

The following question relates to this change:

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

This change adds a field to the ComputeNode object called
“supported_instances”. It also adds an object called “SupportedInstance”
that has fields called “arch”, “hvtype” and “vm_mode”.

All these names already exist in the nova code, but when put together in
these objects they seem a little odd (i.e. supported_instances may be a
little misleading, hvtype has no hyphen but vm_mode does). This is where
they come from:

-supported_instances is the name of the corresponding field of the
compute_nodes database table. The supported_instances field actually
contains a the list of architecture, hypervisor type and vm_mode
combinations supported by the compute node. It is also the existing
field name used in a dict provided by the virt drivers to report this
list to nova.

-arch, hvtype and vm_mode are the names used by variables throughout
nova that refer to the relevant data obtained contained in
supported_instances.

The question is: are these the names we actually want to use?

The reason I ask is that once the names are used for Nova object fields,
the nova object versions would need to be bumped to change them. So if
they are going to change, now would be a good time to put the right
thing in the objects (the rest of nova could be changed subsequently).


Right, exactly.


So, do you think supported_instances should be something else, e.g.
supported_hv_properties? (The SupportedInstance object name can follow
this one.) Please make a suggestion if you think it should change.


Yeah, supported_hv_properties works for me. ++


Do you think we should have hyphens or not in hvtype and vm_mode (note,
vm_mode occurs 160+ times in nova and vmmode occurs 12 times, whereas
occurrence of hv_type vs hvtype has the opposite bias).

In fact, is there a convention that should be followed that I have
forgotten about (or never knew)?


The convention throughout OpenStack code is to use underscore 
separation. Not having underscore separation is the exception, not the rule.


Best,
-jay


Let me know opinions and I will fix the patch accordingly.

Thanks,

Paul



___
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] [keystone] Using 'admin_token' option as token to create keystone client.

[Nader Lahouti]

Thanks Lei for the reply and clarification.
So, instead of that we can use the following:


from keystone client.v2_0 import Client

keystone = Client(username=user, password=password, tenant_name=tenant,
auth_url=url)


with user, password, tenant and url can be obtained from cfg.CONF.


Thanks,

Nader.

On Wed, Oct 8, 2014 at 11:54 PM, Lei Zhang  wrote:

> it should works but it is not safe to use admin_token. Because
> * It is a admin token which has the full privilege for the keystone service
> * The token will be always valid till the admin_token in the conf file
> is changed.
>   It is dangerous when the token leak.
>
> Suggest that the admin_token is only used for the initial of admin account.
>
> On Thu, Oct 9, 2014 at 2:29 PM, Nader Lahouti 
> wrote:
> > Hi,
> >
> > Is it acceptable to use 'admin_token' option from keystone.conf,  when
> > creating a keystone client? something like this:
> >
> > kc = client.Client(token=cfg.CONF.admin_token,
> >
> >endpoint='http://localhost:35357/v2.0/')
> >
> >
> >
> >
> > Thanks,
> >
> > Nader.
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Lei Zhang
> Blog: http://xcodest.me
> twitter/weibo: @jeffrey4l
>
> ___
> 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] Cinder/Neutron plugins on UI

[Dmitry Borodaenko]

Notes from the architecture review meeting on plugins UX:

   - separate page for plugins management
   - user installs the plugin on the master
   - global master node configuration across all environments:
  - user can see a list of plugins on Plugins tab (plugins description)
  - Enable/Disable plugin
 - should we enable/disable plugins globally, or only per
 environment?
- yes, we need a global plugins management page, it will later
be extended to upload or remove plugins
 - if a plugin is used in a deployed environment, options to
 globally disable or remove that plugin are blocked
  - show which environments (or a number of environments) have a
  specific plugin enabled
  - global plugins page is a Should in 6.0 (but easy to add)
  - future: a plugin like ostf should have a deployable flag set to
  false, so that it doesn't show up as an option per env
   - user creates new environment
  - in setup wizard on the releases page (1st step), a list of
  checkboxes for all plugins is offered (same page as releases?)
 - all globally enabled plugins are checked (enabled) by default
 - changes in selection of plugins will trigger regeneration of
 subsequent setup wizard steps
  - plugin may include a yaml mixin for settings page options in
  openstack.yaml format
 - in future releases, it will support describing setup wizard
 (disk configuration, network settings etc.) options in the same way
 - what is the simplest case? does plugin writer have to define the
 plugin enable/disable checkbox, or is it autogenerated?
- if plugin does not define any configuration options: a
checkbox is automatically added into Additional Services
section of the
settings page (disabled by default)
- *problem:* if a plugin is enabled by default, but the option
to deploy it is disabled by default, such environment
would count against
the plugin (and won't allow to remove this plugin
globally) even though it
actually wasn't deployed
 - manifest of plugins enabled/used for an environment?


We ended the discussion on the problem highlighted in bold above: what's
the best way to detect which plugins are actually used in an environment?


On Thu, Oct 9, 2014 at 6:42 AM, Vitaly Kramskikh 
wrote:

> Evgeniy,
>
> Yes, the plugin management page should be a separate page. As for
> dependency on releases, I meant that some plugin can work only on Ubuntu
> for example, so for different releases different plugins could be available.
>
> And please confirm that you also agree with the flow: the user install a
> plugin, then he enables it on the plugin management page, and then he
> creates an environment and on the first step he can uncheck some plugins
> which he doesn't want to use in that particular environment.
>
> 2014-10-09 20:11 GMT+07:00 Evgeniy L :
>
>> Hi,
>>
>> Vitaly, I like the idea of having separate page, but I'm not sure if it
>> should be on releases page.
>> Usually a plugin is not release specific, usually it's environment
>> specific and you can have
>> different set of plugins for different environments.
>>
>> Also I don't think that we should enable plugins by default, user should
>> enable plugin if he wants
>> it to be installed.
>>
>> Thanks,
>>
>> On Thu, Oct 9, 2014 at 3:34 PM, Vitaly Kramskikh > > wrote:
>>
>>> Let me propose another approach. I agree with most of Dmitry's
>>> statements and it seems in MVP we need plugin management UI where we can
>>> enable installed plugins. It should be a separate page. If you want to
>>> create environment with a plugin, enable the plugin on this page and create
>>> a new environment. You can also disable and uninstall plugins using that
>>> page (if there is no environments with the plugin enabled).
>>>
>>> The main reason why I'm against Evgeniy's 2nd approach (explicitly
>>> enabling plugins in the wizard) is that we need to add a step where we
>>> choose the plugins. This step should be added right after choice of
>>> environment name and release, because options on the next steps and even
>>> steps could be added from plugins. And this is complete disaster for UX.
>>> Imagine a new user which uses Fuel for the first time and has to decide
>>> which plugins he will use right after giving a name to an environment.
>>>
>>> So I think if we implement plugin management page and make user
>>> explicitly and globally enable installed plugins there we can implement
>>> Evgeniy's 2nd approach, but in a slightly different way. I think we need to
>>> use all enabled plugins for new environments by default and let user to
>>> uncheck some of them, so they won't be used for that particular
>>> environment. I think the checkboxes should be right on the first pane under
>>> release selectbox (it makes sense because different releases could hav

Re: [openstack-dev] [Neutron] Proposing to disallow updates of IPv6 attributes on subnets

[Martinx - ジェームズ]

Ah okay... That's seems to be perfect fine... Thank you!   :-)

On 9 October 2014 10:22, Robert Li (baoli)  wrote:

>  Hi Thiago,
>
>  A couple of things to consider:
>   — As it is now, it doesn’t seem to be fully functional if you change
> your subnet to use SLAAC. The addresses that were assigned to your existing
> ports in neutron wouldn’t be updated/changed. So basically, you can not
> simply make an API call to change the subnet and expect that everything
> will be setup correctly. Not mention that currently subnet api to update
> the modes can’t even be invoked.
>
>— if you want to use SLAAC, there might be a couple of ways to do that
> . Once multiple prefix is supported, you can create a new slaac
> subnet in the same network. Obviously you need to use a different prefix.
> Later, you can remove the previous subnet.
> . For now, you can create a new network with a slaac subnet. And
> attach your VMs to this new network. Once it’s done, you can remove the
> previous network.
>
>  Hope that it helps
> Robert
>
>   On 10/8/14, 10:25 PM, "Martinx - ジェームズ" 
> wrote:
>
>   Hi!
>
>  Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN
> Provider Network + static IPv6.
>
>  I created the subnet(s) like this (one for each tenant):
>
>  --
> neutron net-create --tenant-id $ID --provider:physical_network=physnet1
> --provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200
>
>  neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID
> physnet1-vlan200 2001:db8:1::/64 --allocation-pool
> start=2001:db8:1::8000,end=2001:db8:1:0::::fffe
>  --
>
>  This new BUGs means that, after upgrading to Juno, I'll not be able to
> "update / convert" this static network to SLAAC ?!?!
>
>  If yes, how can I force the update without breaking the production
> environment? Is there a procedure to follow?
>
>  I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN,
> neither a radvd controlled by Neutron. My upstream router already have
> radvd ready.
>
>  Thanks!
> Thiago
>
> On 7 October 2014 13:21, Henry Gessau  wrote:
>
>> A number of bugs[1][2][3] have been filed which are related to updating
>> the
>> IPv6 attributes after a subnet has been created.
>>
>> In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
>> questions have been raised, which were discussed in today's IPv6 IRC
>> meeting[6].
>>
>> Summary:
>> In Juno we are not ready for allowing the IPv6 attributes on a subnet to
>> be
>> updated after the subnet is created, because:
>> - The implementation for supporting updates is incomplete.
>> - Perceived lack of usefulness, no good use cases known yet.
>> - Allowing updates causes more complexity in the code.
>> - Have not tested that radvd, dhcp, etc. behave OK after update.
>>
>> Therefore we are proposing to change 'allow_put' to False for the two IPv6
>> attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the
>> modes
>> from being updated via the PUT:subnets API.
>>
>> We would be interested to hear of any disagreements or questions.
>>
>>
>> [1] https://launchpad.net/bugs/1362966
>> [2] https://launchpad.net/bugs/1363064
>> [3] https://launchpad.net/bugs/1373417
>> [4] https://review.openstack.org/125328
>> [5] https://review.openstack.org/117799
>> [6]
>>
>> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.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

Re: [openstack-dev] [Nova] object field naming question

[Dan Smith]

> The value it adds (and that an underscore would add in hvtype ->
> hv_type) is that the name would match the naming style for the vast
> majority of everything else in OpenStack. See, for examples:

Agreed.

> As mentioned in the review, I disagree on this point, since "doing a
> cleanup afterwards" would mean having to increment the
> nova.objects.SupportedInstance model VERSION as soon as it went into
> master. I say let's make the quick change now and avoid having to write
> code like this in the next patchset:
> 
>  if client_version <= (1,0):
> # We renamed hvtype to hv_type in 1.1
> self.hv_type = fields.get('hvtype')

Right, this becomes RPC debt if we think we might change it later. We
definitely want to get it right the first time whenever possible.

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

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

[Chris Friesen]

On 10/09/2014 08:12 AM, Jeremy Stanley wrote:

On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
[...]

the tips of these branches have been tagged "havana-eol" in
preparation for branch deletion. The list of affected Git
repositories is as follows:

 openstack-dev/devstack
 openstack-dev/grenade
 openstack/ceilometer
 openstack/cinder
 openstack/designate
 openstack/glance
 openstack/heat
 openstack/horizon
 openstack/keystone
 openstack/neutron
 openstack/nova
 openstack/openstack-manuals
 openstack/oslo-incubator
 openstack/oslo.config
 openstack/requirements
 openstack/swift
 openstack/tempest
 openstack/trove


Just following up to note that I finally removed the stable/havana
branches of the above mentioned projects, in accordance with the EOL
announcement from a couple weeks ago.


Just curious...why do we remove the stable branches for old releases? 
Is the idea to force people onto new branches?


It seems like this just makes more work for people that are maintaining 
older releases since it means they need to make sure to mirror things 
before they go EOL.


Chris


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

Re: [openstack-dev] [Fuel] Contribution to fuel-library: new requirements for reviews

[Sergii Golovatiuk]

Hi,

I think it must be a mandatory request for fuel-library core reviewers.

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

On Thu, Oct 9, 2014 at 10:19 AM, Mike Scherbakov 
wrote:

> This discussion should go in the public, as not every developer is here,
> and other opinions are important.
>
> I believe that we are again diverting the conversation into a few
> directions. Let's address things one by one, and feel free to spin off new
> discussions out of this thread. After original email from Sergii, what I'm
> trying to achieve here - is to formalize new requirements for code review
> process. I suggest to start with something very small and limited -
> approving the code into master. I think rules should change, and reviews
> should have:
>
>- at least one Subject Matter Expert (SME)'s +1
>- Core developer should not merge if there are no other +1th or +2th
>- Recommended to have two core reviews of complicated / suspicious
>patches
>- Must have at least two core reviews for patches which change
>reference architecture
>
> Thanks,
>
> From: Vladimir Kuklin 
> Date: Mon, Oct 6, 2014 at 6:12 PM
> Subject: Re: Contribution to fuel-library
> To: Anastasia Urlapova 
> Cc: Aleksandr Didenko , Andrey Danin <
> ada...@mirantis.com>, Partner Integrations Team , Mike
> Scherbakov , Sergii Golovatiuk <
> sgolovat...@mirantis.com>, fuel-core-team 
>
>
> Nastya,
>
> I do not think modular testing blueprint is the right place to write this
> checklist down. I think, we need, first of all, create corresponding
> jenkins jobs and make them dry-run until there is implementation ready for
> them. E.g. we almost do already have --noop implementation support. Let's
> finally add it as a job to CI. And let's do not run actual deployments
> until CI passes syntax and noop verification, for example.
>
> On Mon, Oct 6, 2014 at 6:07 PM, Anastasia Urlapova  > wrote:
>
>> Alex,
>> could you update
>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
>> according your ideas and suggestions.
>>
>> Thanks,
>>  Nastya.
>>
>> On Mon, Oct 6, 2014 at 3:53 PM, Aleksandr Didenko 
>> wrote:
>>
>>> I would also add rspec testing to the CI as well:
>>>
>>> a) code linting
>>> b) syntax checking
>>> c) [in future] rake spec testing
>>> d) noop dry run test
>>> e) [in future] deployment modules tests
>>> f) system tests
>>> g) [in future] integration tests
>>>
>>> On Mon, Oct 6, 2014 at 2:34 PM, Vladimir Kuklin 
>>> wrote:
>>>
 Ok, guys, I would suggest to start with formalization of requirements
 for code review in Fuel Library, as there is no such page on Fuel wiki. I
 think that workflow should be as following:

 1) Code itself should be reviewed manually
 2) Unit tests should be written by the developer himself. Other tests
 should be written by QA and/or developers
 3) All the other criteria should be checked by CI automatically - there
 MUST be no manual process:
 a) code linting
 b) syntax checking
 c) noop dry run test
 d) [in future] deployment modules tests
 e) system tests
 f) [in future] integration tests
 4) [In Future] each request can be accepted only after related upstream
 manifests bug is created and a review request for particular change is
 opened

 Some of these points are marked for future. But we can enable them as
 soon as corresponding testing code is written and CI infrastructure is
 ready.

 On Mon, Oct 6, 2014 at 1:28 PM, Andrey Danin 
 wrote:

>
> +PI team
> Please, keep us in this discussion. We are interested in it a lot.
>
> On Mon, Oct 6, 2014 at 12:31 AM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hi,
>>
>> > On #1, I'd love to hear more information and suggested workflow. I
>> know only something short like "propose contribution to upstream module
>> first, then to fuel-library"; I think we need more details, and make sure
>> everyone knows and follows.
>>
>> First of all, I think everybody who wants to contribute into
>> fuel-library should know some Puppet DSL basics and also read
>> puppet-openstack dev docs [1] and our dev docs [2]
>>
>> Since we start merging upstream manifests, the most common and
>> general rule is: upstream modules should be modified only with bugfixes 
>> and
>> improvements everyone in the community could benefit from. And 
>> appropriate
>> patch should be proposed to the upstream project. In other cases (like
>> applying our own logic or settings) we should do it in our own modules or
>> in "openstack::*" classes (fuel-library/deployment/puppet/openstack), 
>> like:
>> openstack::compute, openstack::cinder. I think, our main goal should be:
>> use all the community modules "as is". This is why we need to contribute 
>> to
>> the upstream projects.
>>
>> So the workflow 

Re: [openstack-dev] OpenStack Technical Committee Nomination

[Tristan Cacqueray]

confirmed.

Note that we are making an exception here for a brand new parent.
I'd like to remind further candidate to use the proper "TC candidacy"
mail subject.

On 08/10/14 09:33 PM, Sean Dague wrote:
> I'd like to announce throwing my hat into the ring for the OpenStack
> Technical Committee.
> 
> = My Background on the Project =
> 
> I've been a contributor to OpenStack since late in the Essex release. I
> was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer
> on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project
> Config repo in infra, and a host of other projects in OpenStack. I was
> elected to the TC last fall as part of the first fully directed TC.
> 
> You might also know me from the fact that I spend a lot of time on the
> OpenStack gate, which really means I spend a lot of time trying to
> understand why when all the OpenStack components run together, they
> often break horribly, and actually try to debug and address those. I was
> part of the team that built Elastic Recheck
> (http://status.openstack.org/elastic-recheck/) for that effort.
> 
> In any particular release of OpenStack I'm typically one of the largest
> reviewers of code. A lot of these are help shepherding in easy fixes
> that get lost in our review queues. I built things like Gerrit Dashboard
> Creator (https://github.com/stackforge/gerrit-dash-creator) to make it
> easier for reviewers to sift patches to make sure that good patches
> don't get lost, and make reviewer's lives easier.
> 
> And I am a strong believer that the way we grow our community is through
> growing our contributors. This is one of the reasons I kicked off the
> OpenStack Bootstrapping Hour
> (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and
> Dan Smith, to provide one avenue for this growth to happen. I think many
> other are required as well, but this is one way to get us started.
> 
> = My Views on the Future of OpenStack and the TC =
> 
> I feel like OpenStack is at a crossroads. The original definition of the
> integrated release, and horizontal teams was built around the concept of
> 2 projects. It worked at 5. It was strained at 8. And I think we're now
> on the very of it being completely broken.
> 
> I think that in order for OpenStack to move forward we need to
> pragmatically redefine the integrated release as the set of horizontal
> components that have to be linked together to be useful. Exactly the
> right unit I think is up for debate. It could be as small as Nova,
> Glance, Keystone, Neutron. It might include Cinder, Designate, and / or
> Oslo (I can see the case for and against any of these). Those should be
> the projects that QA, Docs, and Stable Maint, Release Management,
> Security Team, and the TC needs to take responsibility for.
> 
> I think that we need to have an expansive ecosystem where projects like
> Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally,
> Ironic, and all the other really interesting projects can flourish. I
> think their inclusion in the OpenStack umbrella should be a lightweight
> process that is largely a self assessment and an acceptance of certain
> principles that are core to OpenStack. I think these projects should be
> self responsible for their own QA, Docs, Stable Maint, Security, and
> Release Management. And I think mentoring should be made available to
> help them with any of these. I believe a structure similar to the User
> Committee is probably most appropriate here. However we get this body,
> it should have an electorate (directly or indirectly) that represents
> ATCs from the broadest expanse of our ecosystem.
> 
> I think the TC needs to evolve from a policy body, to a body that's
> primarily directly responsible for the integrated release (as I defined
> above). Direct responsibility means more than approving and managing gap
> analysis plans. It means diving directly into project code across all
> the integrated release projects at substantial regularity. It could mean
> the TC inheriting +2 on the integrated projects and horizontal efforts
> supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we
> could only do this with a strong set of expectations and checks and
> balances to prevent abuse, but it's an idea that's interesting to think
> about).
> 
> I would like to think about this as a tight integrated release plus a
> large and solid ecosystem.
> 
> These are things I'm going to push for going forward, whether or not I'm
> on the TC, however I think the idea of having the TC take more ownership
> of the integrated release, directly. We need an OpenStack base box set
> with more full and cohesive user experience (one that doesn't require
> understanding and maintaining multiple db systems), that is deployable
> at everything from small colleges and institutions, to giant places like
> wall street, telcos, and research institutions. And then we need to have
> space to promote great expansions to OpenS

Re: [openstack-dev] OpenStack Technical Committee Nomination

[Tristan Cacqueray]

confirmed.

Note that we are making an exception here for a brand new parent.
I'd like to remind further candidate to use the proper "TC candidacy"
mail subject.

On 08/10/14 09:33 PM, Sean Dague wrote:
> I'd like to announce throwing my hat into the ring for the OpenStack
> Technical Committee.
> 
> = My Background on the Project =
> 
> I've been a contributor to OpenStack since late in the Essex release. I
> was the QA PTL for the Havana and Icehouse cycles. I'm a core reviewer
> on QA (Devstack, Grenade, Tempest), on Nova, and on the new Project
> Config repo in infra, and a host of other projects in OpenStack. I was
> elected to the TC last fall as part of the first fully directed TC.
> 
> You might also know me from the fact that I spend a lot of time on the
> OpenStack gate, which really means I spend a lot of time trying to
> understand why when all the OpenStack components run together, they
> often break horribly, and actually try to debug and address those. I was
> part of the team that built Elastic Recheck
> (http://status.openstack.org/elastic-recheck/) for that effort.
> 
> In any particular release of OpenStack I'm typically one of the largest
> reviewers of code. A lot of these are help shepherding in easy fixes
> that get lost in our review queues. I built things like Gerrit Dashboard
> Creator (https://github.com/stackforge/gerrit-dash-creator) to make it
> easier for reviewers to sift patches to make sure that good patches
> don't get lost, and make reviewer's lives easier.
> 
> And I am a strong believer that the way we grow our community is through
> growing our contributors. This is one of the reasons I kicked off the
> OpenStack Bootstrapping Hour
> (https://wiki.openstack.org/wiki/BootstrappingHour) with Jay Pipes and
> Dan Smith, to provide one avenue for this growth to happen. I think many
> other are required as well, but this is one way to get us started.
> 
> = My Views on the Future of OpenStack and the TC =
> 
> I feel like OpenStack is at a crossroads. The original definition of the
> integrated release, and horizontal teams was built around the concept of
> 2 projects. It worked at 5. It was strained at 8. And I think we're now
> on the very of it being completely broken.
> 
> I think that in order for OpenStack to move forward we need to
> pragmatically redefine the integrated release as the set of horizontal
> components that have to be linked together to be useful. Exactly the
> right unit I think is up for debate. It could be as small as Nova,
> Glance, Keystone, Neutron. It might include Cinder, Designate, and / or
> Oslo (I can see the case for and against any of these). Those should be
> the projects that QA, Docs, and Stable Maint, Release Management,
> Security Team, and the TC needs to take responsibility for.
> 
> I think that we need to have an expansive ecosystem where projects like
> Swift, Heat, Horizon, Ceilometer, Trove, Congress, Sahara, Zaqar, Rally,
> Ironic, and all the other really interesting projects can flourish. I
> think their inclusion in the OpenStack umbrella should be a lightweight
> process that is largely a self assessment and an acceptance of certain
> principles that are core to OpenStack. I think these projects should be
> self responsible for their own QA, Docs, Stable Maint, Security, and
> Release Management. And I think mentoring should be made available to
> help them with any of these. I believe a structure similar to the User
> Committee is probably most appropriate here. However we get this body,
> it should have an electorate (directly or indirectly) that represents
> ATCs from the broadest expanse of our ecosystem.
> 
> I think the TC needs to evolve from a policy body, to a body that's
> primarily directly responsible for the integrated release (as I defined
> above). Direct responsibility means more than approving and managing gap
> analysis plans. It means diving directly into project code across all
> the integrated release projects at substantial regularity. It could mean
> the TC inheriting +2 on the integrated projects and horizontal efforts
> supporting it (like QA, Docs, and Stable Maintenance) (Note: clearly we
> could only do this with a strong set of expectations and checks and
> balances to prevent abuse, but it's an idea that's interesting to think
> about).
> 
> I would like to think about this as a tight integrated release plus a
> large and solid ecosystem.
> 
> These are things I'm going to push for going forward, whether or not I'm
> on the TC, however I think the idea of having the TC take more ownership
> of the integrated release, directly. We need an OpenStack base box set
> with more full and cohesive user experience (one that doesn't require
> understanding and maintaining multiple db systems), that is deployable
> at everything from small colleges and institutions, to giant places like
> wall street, telcos, and research institutions. And then we need to have
> space to promote great expansions to OpenS

[openstack-dev] [Ironic] Juno RC2 available

[Devananda van der Veen]

Hi all!

We've had one release critical bug discovered in the past week, and so
today an RC2 candidate was published. A tarball of that is available
at:

https://launchpad.net/ironic/+milestone/juno-rc2

This fixed the following bug:

  Hash ring is stale after new conductor added
  https://bugs.launchpad.net/bugs/1378570

Please continue testing and validating the proposed Juno release. In
addition to the tarball available from the link above, you can
directly test the proposed/juno branch at:

https://github.com/openstack/ironic/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/ironic/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's attention.

Regards,
Devananda

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

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

[Boden Russell]

On 10/9/14 1:31 PM, Chris Friesen wrote:
> On 10/09/2014 08:12 AM, Jeremy Stanley wrote:
> > On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
> > [...]
> >> the tips of these branches have been tagged "havana-eol" in
> >> preparation for branch deletion. The list of affected Git
> >> repositories is as follows:
> >>
> >>  openstack-dev/devstack
> >>  openstack-dev/grenade
> >>  openstack/ceilometer
> >>  openstack/cinder
> >>  openstack/designate
> >>  openstack/glance
> >>  openstack/heat
> >>  openstack/horizon
> >>  openstack/keystone
> >>  openstack/neutron
> >>  openstack/nova
> >>  openstack/openstack-manuals
> >>  openstack/oslo-incubator
> >>  openstack/oslo.config
> >>  openstack/requirements
> >>  openstack/swift
> >>  openstack/tempest
> >>  openstack/trove
> >
> > Just following up to note that I finally removed the stable/havana
> > branches of the above mentioned projects, in accordance with the EOL
> > announcement from a couple weeks ago.
>
> Just curious...why do we remove the stable branches for old releases? Is the 
> idea to force people onto new branches?

If I'm not mistaken; it appears the tag rename from "havana" -> "havana-eol" 
may be effecting the upgrade CI tests in recent commits (ex: [1]).

For example in real-db-upgrade_nova_mysql_user001:th-mysql:
[snip]

2014-10-09 17:12:11,771 [output] Database is from Grizzly! Upgrade via Havana
2014-10-09 17:12:11,774 [output] error: branch 'stable/havana' not found.
2014-10-09 17:12:11,784 [output] Fetching origin
2014-10-09 17:12:16,634 [output] Switched to a new branch 'stable/havana'
2014-10-09 17:12:16,639 [output] fatal: ambiguous argument 
'remotes/origin/stable/havana': unknown revision or path not in the working 
tree.

[/snip]

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


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

[openstack-dev] [Cinder] Juno RC2 available

[Thierry Carrez]

Hello everyone,

Due to a number of issues discovered in the published Cinder 2014.2 RC1
(including two security issues), we generated a new Juno release
candidate. You can find the list of bugfixes in this RC and a link to a
source tarball at:

https://launchpad.net/cinder/juno/juno-rc2

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Cinder 2014.2 on
October 16. You are therefore strongly encouraged to test and validate
this tarball !

Alternatively, you can directly test the proposed/juno branch at:
https://github.com/openstack/cinder/tree/proposed/juno

If you find an issue that could be considered release-critical, please
file it at:

https://bugs.launchpad.net/cinder/+filebug

and tag it *juno-rc-potential* to bring it to the release crew's
attention.

Regards,

-- 
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] [Fuel] Documentation Process changed

[Dmitry Pyzhov]

We definitely need to assign these bugs to the fuel-docs team. And there is
a good point from Alexandra Fedorova that commit message needs to have
enough information for tech writer. And reviewers should not merge fixes
that do not apply this rule. Otherwise we will end up with new bottlenecks.

One bottleneck is bug triage with bunch of badly formatted bug reports
every day. And another bottleneck is bugs on fuel-docs team. They will have
to drive each bug, find a developer, get the information, find a place for
it and so on. Let's try to make their life easier.

And another point. I don't like bug tags. You can not see them from the
milestone page. You can not filter out documentation bugs even from
advanced search page. We could try to add [doc] prefix for bug subjects
automatically. It will help a little bit.

On Thu, Oct 9, 2014 at 12:27 AM, Sergii Golovatiuk  wrote:

> Hi,
>
> Dima, that's really good approach.
>
> Mike, technical writer may ask developer and assign bug to him/her if bug
> impacts developer documentation only.
>
> Best Regards,
> Sergii Golovatiuk
>
> On 08 Oct 2014, at 21:08, Mike Scherbakov 
> wrote:
>
> Thanks Dmitry,
> let's try to go this way and correct process if needed when we get first
> results.
>
> > Where is your 80% dev vs user docs figure coming from?
> it's no more than my guess. We will see real number over time.
>
> On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> At the moment OpenStack infrastructure doesn't allow to customize the
>> bugs it creates, we should propose a patch at some point to implement
>> that. When we do, I think we should assign such bugs automatically to
>> fuel-docs team.
>>
>> I don't think we should separate user and dev docs bugs, we're working
>> in the opposite direction towards merging dev docs into fuel-docs:
>> https://review.openstack.org/124551
>>
>> Where is your 80% dev vs user docs figure coming from?
>>
>> I think that whether it's dev or user documentation, a technical
>> writer should drive the process, collect information from the commit
>> author, and add it to the right documentation areas. It's commit
>> author's responsibility to provide an informative commit message in
>> the first place, to answer technical writer's questions, and to review
>> docs commits that address the DocImpact bug.
>>
>> On Oct 8, 2014 10:59 AM, "Mike Scherbakov" 
>> wrote:
>> >
>> > Very good improvement in our documentation process.
>> >
>> > Is there a way to configure it, so bugs would be created with tag
>> "docs" automatically? It would simplify triaging process I believe.
>> > From the other hand, as far as I understand, up to 80% of commits with
>> "DocImpact" will impact development documentation (or it's intended to be
>> affecting only user documentation?). It would be hard for tech writers, who
>> are mostly specialized in Fuel user docs, to work on low-level details of
>> how, let's say, l23network [1] works.
>> > Do we want to separate docs bugs somehow, user/dev?
>> >
>> > In other words, what would be the flow, who becomes responsible for
>> fixing bugs created automatically by Infra?
>> >
>> > [1]
>> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network
>> >
>> > On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fuel Summit '2014 we discussed our Documentation process. According
>> to follow up we aligned it to OpenStack 'DocImpact' process. The new
>> process has been tested on background by me and Bogdan Dobrelya. Today, I
>> have updated Fuel Documentation Process so we are making it official.
>> >>
>> >> Why?
>> >> Developer perspective:
>> >> It gives more flexibility for the developers to participate in
>> Documentation Process. Every time when the Reviewer sees that patch
>> requires Documentation update, it may ask the Commiter to update 'Commit
>> Message' with DocImpact message. Once patch passes the review Openstack
>> Infra will trigger a new bug in Launchpad that should be assigned to Fuel
>> Documentation team.
>> >>
>> >> From Fuel Documentation Team perspective:
>> >> When Fuel Documentation Team sees this bug they know who was the
>> commiter and reviewers and whom they should add for documentation review.
>> >>
>> >> Community:
>> >> Community member may ask the developer to put 'DocImpact' message when
>> it's required.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>  ___
> 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.or

Re: [openstack-dev] [Keystone][Oslo] User mapping and X509 for signing

[Adam Young]

On 10/09/2014 09:31 AM, John Dennis wrote:

On 10/08/2014 04:58 PM, Adam Young wrote:

When gyee posted his X509 server-side auth plugin patch,  the feedback
we gave was that it should be using the mapping code from Federation to
transform the environment variables set by the web server to the
Keystone userid, username, domain name, and so forth.

The PKI token format currently allows for a single signing cert.  I have
a proposal to allow for multiple signers.  One issue, though, is how to
map from the certificates signer-info to the Keystone server that signed
the data.   signer-data is part of the CMS message format, and can be
used to uniquely identify the certificate that signed the document.
  From the signer-data, we can fetch the certificate.

SO, we could build a system that allowed us to fetch multiple certs for
checking signatures.  But then the question is, which cert maps to "the
entity authorized to sign for this data."

OpenStack lacks a way to enumerate the systems, endpoints or otherwise.
I'm going to propose that we create a service domain and that any system
responsible for signing a document have a user created inside that
domain.  I think we want to make the endpoint id match the user ID for
endpoints, and probably something comparable for Nova Compute services.

This means we can use the associated keystone user to determine what
Compute node signed a message.  It gives us PKI based, asymetric Oslo
message signing.

This same abstraction should be extended to Kite for symmetric keys.

In order to convert the certificate data to the Keystone User ID, we can
use the Mapping mechanism from Federation, just like we are planning on
for the X509 Auth Plugin.

One thing I want to make explicit, and get some validation on from the
community:  is it acceptable to say that there needs to be a mappable
link between AL  X509 certificates distributed by a certain CA, for a
certain Domain and the users in there?  It seems to me to be comparable
to the LDAP constraints.  Is this a reasonable assumption?  If not, it
seems like the X509 mechanism is really not much more than a naked
Public Key.

I don't fully understand your proposal, perhaps because a few details
were omitted. But here are my thoughts and let me know where I might
have misunderstood.

The mapping seems pretty straight forward to me thus I'm not sure I see
the need for an extra service and the associated complexity.
No added service.  The token validation is code to run in auth_token 
middleware, so a remote service like Nova.



  You should
be able extract the signer subject from the signing data as well as the
signer's issuer information. Given that it's a simple lookup whose
mapping can be trivially managed using any of the key/value tables
available to Keystone, one only needs to populate that table in some
authoritative way, but that's mostly a deployment issue.
Yeah,  so first step is an extension to the current cert api to fetch 
based on signer info.   Now we can validate the token or other document


Second is to lookup user from cert, which will use the same mapping as 
the Federation based X509 plugin gyee is working on.


Third is to let the service user query the roles for that user in the 
domain as signed by the document.


the last two steps can be combined by reusing the existing token 
api...or maybe the validate-token call.  Bascially, we need to be able 
to get the set of roles for the user-in-domain that signed the document.


We have the ability to fetch policy per endpoint, so the service user 
can fetch the policy to determine if the signer has the authority to 
acutally sign for the data in the token.





I also don't follow what you mean by "not much more than a naked Public
Key", can you elaborate?
Sure.  If I can upload an X5098 cert to the record for Keystone user  
"jdennis"  but that cert was assigned to me, then I can authenticate to 
Keystone as "jdennis".  It puts all of the weight of authentication onto 
Keystone, without making use of the signing mechanism in the cert itself.










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

Re: [openstack-dev] [all] [oslo] Proposed database connectivity patterns

[Mike Bayer]

So so far, everyone seems really positive and psyched about the proposal.

It looks like providing some options for how to use would be best, that is 
provide decorators and context managers.

Now the thing with the context manager, it can be as I stated:

with sql.reader() as session:

or we can even have that accept the “context”:

with sql.reader(context) as session:

The latter again avoids having to use thread locals.

But can I get a feel for how comfortable we are with using thread local storage 
to implement this feature?   I had anticipated people wouldn’t like it because 
it’s kind of a “global” object, even though it will be hidden behind this 
facade (of course CONF is global as is sys.modules, and I think it is fine).
 If I just use a tlocal, this whole thing is pretty simple.

I’m going to do another pass that attempts to unify these three syntaxes - I’m 
proposing calling the context manager “using_” so that it can be differentiated 
from the decorator (e.g. so each function doesn’t need to inspect arguments):

@sql.reader
def my_api_method(context, …):
context.session

def my_api_method(context, …):
   with sql.using_reader(context) as session:
 session , context.session

def my_api_method(…):
   with sql.using_reader() as session:
   session

all three will be fully interchangeable - meaning they will ultimately use 
thread local storage in any case.For now I think if 
sql.using_reader(context) or @sql.reader is called with different context 
identities in a single call stack, it should raise an exception - not that we 
can’t support that, but whether it means we should push new state onto the 
“stack” or not is ambiguous at the moment so we should refuse to guess.




On Oct 8, 2014, at 5:07 PM, Mike Bayer  wrote:

> Hi all -
> 
> I’ve drafted up my next brilliant idea for how to get Openstack projects to 
> use SQLAlchemy more effectively.   The proposal here establishes significant 
> detail on what’s wrong with the current state of things, e.g. the way I see 
> EngineFacade, get_session() and get_engine() being used, and proposes a new 
> system that provides a true facade around a managed context.   But of course, 
> it requires that you all change your code!  (a little bit).  Based on just a 
> few tiny conversations on IRC so far, seems like this might be a hard sell.  
> But please note, most projects are pretty much broken in how they use the 
> database - this proposal is just a first step to making it all non-broken, if 
> not as amazing and cool as some people wish it could be.  Unbreaking the code 
> and removing boilerplate is the first step - with sane and declarative 
> patterns in place, we can then build in more bells and whistles.
> 
> Hoping you’re all super curious now, here it is!  Jump in:  
> https://review.openstack.org/#/c/125181/
> 
> - mike
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] [all] [tc] Multi-clouds integration by OpenStack cascading

[Duncan Thomas]

On 8 October 2014 10:32, joehuang  wrote:
> "maybe we should just slap a REST api on it". The challenge of Node-pool REST 
> API is "What it will look like for these API, totally new API? current OS-API 
> ?". From cloud operators' feed back, OS-API is preferred. If we developed 
> totally new API for Node-pool, it takes long time to grow API-ecosystem or 
> 3rd party APP for it.

Oh, I don't think nodepool solves many of the problems being looked at
here - it is almost a side discussion - I just think that nodepool
would be way more useful with an API rather than requiring people to
install it themselves.

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

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

[Duncan Thomas]

On 9 October 2014 07:49, henry hly  wrote:
> Hi Joshua,
>
> ...in fact hierarchical scale
> depends on square of single child scale. If a single child can deal
> with 00's to 000's, cascading on it would then deal with 00,000's.

That is faulty logic - maybe the cascading solution needs to deal with
global quota and other aggregations that will rapidly break down your
scaling factor, or maybe there are few such problems can the cascade
part can scale way better than the underlying part. They are two
totally different scaling cases, so and suggestion that they are
anything other than an unknown multiplier is bogus.

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

Re: [openstack-dev] [Fuel] Documentation Process changed

[Dmitry Borodaenko]

Filtering bugs by tags works fine in advanced search, the only problem is
that you can't combine it with filtering by releases (since that's broken
in advanced search and you have to use milestone page for that).

On Thu, Oct 9, 2014 at 12:18 PM, Dmitry Pyzhov  wrote:

> We definitely need to assign these bugs to the fuel-docs team. And there
> is a good point from Alexandra Fedorova that commit message needs to have
> enough information for tech writer. And reviewers should not merge fixes
> that do not apply this rule. Otherwise we will end up with new bottlenecks.
>
> One bottleneck is bug triage with bunch of badly formatted bug reports
> every day. And another bottleneck is bugs on fuel-docs team. They will have
> to drive each bug, find a developer, get the information, find a place for
> it and so on. Let's try to make their life easier.
>
> And another point. I don't like bug tags. You can not see them from the
> milestone page. You can not filter out documentation bugs even from
> advanced search page. We could try to add [doc] prefix for bug subjects
> automatically. It will help a little bit.
>
> On Thu, Oct 9, 2014 at 12:27 AM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>> Dima, that's really good approach.
>>
>> Mike, technical writer may ask developer and assign bug to him/her if bug
>> impacts developer documentation only.
>>
>> Best Regards,
>> Sergii Golovatiuk
>>
>> On 08 Oct 2014, at 21:08, Mike Scherbakov 
>> wrote:
>>
>> Thanks Dmitry,
>> let's try to go this way and correct process if needed when we get first
>> results.
>>
>> > Where is your 80% dev vs user docs figure coming from?
>> it's no more than my guess. We will see real number over time.
>>
>> On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> At the moment OpenStack infrastructure doesn't allow to customize the
>>> bugs it creates, we should propose a patch at some point to implement
>>> that. When we do, I think we should assign such bugs automatically to
>>> fuel-docs team.
>>>
>>> I don't think we should separate user and dev docs bugs, we're working
>>> in the opposite direction towards merging dev docs into fuel-docs:
>>> https://review.openstack.org/124551
>>>
>>> Where is your 80% dev vs user docs figure coming from?
>>>
>>> I think that whether it's dev or user documentation, a technical
>>> writer should drive the process, collect information from the commit
>>> author, and add it to the right documentation areas. It's commit
>>> author's responsibility to provide an informative commit message in
>>> the first place, to answer technical writer's questions, and to review
>>> docs commits that address the DocImpact bug.
>>>
>>> On Oct 8, 2014 10:59 AM, "Mike Scherbakov" 
>>> wrote:
>>> >
>>> > Very good improvement in our documentation process.
>>> >
>>> > Is there a way to configure it, so bugs would be created with tag
>>> "docs" automatically? It would simplify triaging process I believe.
>>> > From the other hand, as far as I understand, up to 80% of commits with
>>> "DocImpact" will impact development documentation (or it's intended to be
>>> affecting only user documentation?). It would be hard for tech writers, who
>>> are mostly specialized in Fuel user docs, to work on low-level details of
>>> how, let's say, l23network [1] works.
>>> > Do we want to separate docs bugs somehow, user/dev?
>>> >
>>> > In other words, what would be the flow, who becomes responsible for
>>> fixing bugs created automatically by Infra?
>>> >
>>> > [1]
>>> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network
>>> >
>>> > On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On Fuel Summit '2014 we discussed our Documentation process.
>>> According to follow up we aligned it to OpenStack 'DocImpact' process. The
>>> new process has been tested on background by me and Bogdan Dobrelya. Today,
>>> I have updated Fuel Documentation Process so we are making it official.
>>> >>
>>> >> Why?
>>> >> Developer perspective:
>>> >> It gives more flexibility for the developers to participate in
>>> Documentation Process. Every time when the Reviewer sees that patch
>>> requires Documentation update, it may ask the Commiter to update 'Commit
>>> Message' with DocImpact message. Once patch passes the review Openstack
>>> Infra will trigger a new bug in Launchpad that should be assigned to Fuel
>>> Documentation team.
>>> >>
>>> >> From Fuel Documentation Team perspective:
>>> >> When Fuel Documentation Team sees this bug they know who was the
>>> commiter and reviewers and whom they should add for documentation review.
>>> >>
>>> >> Community:
>>> >> Community member may ask the developer to put 'DocImpact' message
>>> when it's required.
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openst

Re: [openstack-dev] [all] [oslo] Acceptable methods for establishing per-test-suite behaviors

[Doug Hellmann]

On Oct 8, 2014, at 10:14 AM, Doug Hellmann  wrote:

> 
> On Oct 8, 2014, at 1:22 AM, Robert Collins  wrote:
> 
>> On 8 October 2014 11:10, Mike Bayer  wrote:
>>> Hi folks -
>>> 
>>> So just to update on the status here, for the transactional testing and all 
>>> that, I’ve had a blueprint in the queue for quite awhile:
>> 
>> ...
>> 
>> I'll probably time it out upstream if I can't get a review and just
>> drop it straight into testtools. That said, I'm still AWL from
>> everything dealing with this personal matter. Once thats resolved I'll
>> be full steam on unblocking things for this patch set of yours.
>> 
>> If you want to move forward without me - backporting the fixes to
>> testtools would be a good start, jml or thomi or jelmer (amongst
>> others) can review and land and do a release - I'm not critical path.
> 
> I know you put together a PoC (maybe more) showing how to make this work for 
> namespace packages. I wonder if this is just another example of a reason to 
> stop using them, though?
> 
> Does it make sense to move ahead with separate test suite instances and come 
> back to unify that when we resolve the package issue?

As an experiment, I put together a patch for oslo.i18n that moves it out of the 
namespace package while still retaining the ability to import from the 
namespace package (say that 10 times fast).

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

Doug


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

Re: [openstack-dev] [Fuel] Contribution to fuel-library: new requirements for reviews

[Dmitry Borodaenko]

Documented in the Wiki:
https://wiki.openstack.org/wiki/Fuel/Code_Review_Rules#Merging_commits

On Thu, Oct 9, 2014 at 1:19 AM, Mike Scherbakov 
wrote:

> This discussion should go in the public, as not every developer is here,
> and other opinions are important.
>
> I believe that we are again diverting the conversation into a few
> directions. Let's address things one by one, and feel free to spin off new
> discussions out of this thread. After original email from Sergii, what I'm
> trying to achieve here - is to formalize new requirements for code review
> process. I suggest to start with something very small and limited -
> approving the code into master. I think rules should change, and reviews
> should have:
>
>- at least one Subject Matter Expert (SME)'s +1
>- Core developer should not merge if there are no other +1th or +2th
>- Recommended to have two core reviews of complicated / suspicious
>patches
>- Must have at least two core reviews for patches which change
>reference architecture
>
> Thanks,
>
> From: Vladimir Kuklin 
> Date: Mon, Oct 6, 2014 at 6:12 PM
> Subject: Re: Contribution to fuel-library
> To: Anastasia Urlapova 
> Cc: Aleksandr Didenko , Andrey Danin <
> ada...@mirantis.com>, Partner Integrations Team , Mike
> Scherbakov , Sergii Golovatiuk <
> sgolovat...@mirantis.com>, fuel-core-team 
>
>
> Nastya,
>
> I do not think modular testing blueprint is the right place to write this
> checklist down. I think, we need, first of all, create corresponding
> jenkins jobs and make them dry-run until there is implementation ready for
> them. E.g. we almost do already have --noop implementation support. Let's
> finally add it as a job to CI. And let's do not run actual deployments
> until CI passes syntax and noop verification, for example.
>
> On Mon, Oct 6, 2014 at 6:07 PM, Anastasia Urlapova  > wrote:
>
>> Alex,
>> could you update
>> https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing
>> according your ideas and suggestions.
>>
>> Thanks,
>>  Nastya.
>>
>> On Mon, Oct 6, 2014 at 3:53 PM, Aleksandr Didenko 
>> wrote:
>>
>>> I would also add rspec testing to the CI as well:
>>>
>>> a) code linting
>>> b) syntax checking
>>> c) [in future] rake spec testing
>>> d) noop dry run test
>>> e) [in future] deployment modules tests
>>> f) system tests
>>> g) [in future] integration tests
>>>
>>> On Mon, Oct 6, 2014 at 2:34 PM, Vladimir Kuklin 
>>> wrote:
>>>
 Ok, guys, I would suggest to start with formalization of requirements
 for code review in Fuel Library, as there is no such page on Fuel wiki. I
 think that workflow should be as following:

 1) Code itself should be reviewed manually
 2) Unit tests should be written by the developer himself. Other tests
 should be written by QA and/or developers
 3) All the other criteria should be checked by CI automatically - there
 MUST be no manual process:
 a) code linting
 b) syntax checking
 c) noop dry run test
 d) [in future] deployment modules tests
 e) system tests
 f) [in future] integration tests
 4) [In Future] each request can be accepted only after related upstream
 manifests bug is created and a review request for particular change is
 opened

 Some of these points are marked for future. But we can enable them as
 soon as corresponding testing code is written and CI infrastructure is
 ready.

 On Mon, Oct 6, 2014 at 1:28 PM, Andrey Danin 
 wrote:

>
> +PI team
> Please, keep us in this discussion. We are interested in it a lot.
>
> On Mon, Oct 6, 2014 at 12:31 AM, Aleksandr Didenko <
> adide...@mirantis.com> wrote:
>
>> Hi,
>>
>> > On #1, I'd love to hear more information and suggested workflow. I
>> know only something short like "propose contribution to upstream module
>> first, then to fuel-library"; I think we need more details, and make sure
>> everyone knows and follows.
>>
>> First of all, I think everybody who wants to contribute into
>> fuel-library should know some Puppet DSL basics and also read
>> puppet-openstack dev docs [1] and our dev docs [2]
>>
>> Since we start merging upstream manifests, the most common and
>> general rule is: upstream modules should be modified only with bugfixes 
>> and
>> improvements everyone in the community could benefit from. And 
>> appropriate
>> patch should be proposed to the upstream project. In other cases (like
>> applying our own logic or settings) we should do it in our own modules or
>> in "openstack::*" classes (fuel-library/deployment/puppet/openstack), 
>> like:
>> openstack::compute, openstack::cinder. I think, our main goal should be:
>> use all the community modules "as is". This is why we need to contribute 
>> to
>> the upstream projects.
>>
>> So the workflow for contributing into fuel-library should be
>>>

[openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?

[Matt Riedemann]

The sqlalchemy-migrate project is basically maintenance mode and the 
core team [1] is kind of a weird mix of people - all great people I'm 
sure, but I think it's more a team of people that stepped up when 
OpenStack took over the project and said they'd babysit it but it's 
pretty idle.


Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can 
we just have the oslo.db core team [2] own sqlalchemy-migrate now too?


Here are the sqlalchemy-migrate open reviews:

https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z

[1] https://review.openstack.org/#/admin/groups/186,members
[2] https://review.openstack.org/#/admin/groups/331,members

--

Thanks,

Matt Riedemann


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

[openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning

[Gregory Haynes]

Hello TripleO-ers,

Last time around there was a lot of feedback that we should plan our
mid-cycle metup a lot sooner, so lets do that! I've created a (mostly
bare) etherpad here:

https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup

Note that there are currently no possible venues listed. If you are able
to provide a possible venue (Thank you!) please reply and/or add it to
the etherpad.

I have also listed a few possible Mon-Fri meetup dates. Do not take this
as any indication that Mon-Fri is an ideal meetup length or time of
week, and feel free to add feedback / combinations of your own.
Personally, I felt pretty burned out by Friday last time so maybe
Mon-Wed is a better size?

Cheers,
Greg

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

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

[Jeremy Stanley]

On 2014-10-09 11:31:37 -0600 (-0600), Chris Friesen wrote:
> Just curious...why do we remove the stable branches for old
> releases? Is the idea to force people onto new branches?

It's twofold. First, it's to indicate that the branch will be
getting no new patches ever. Second, it's because that's the only
good way to get Gerrit to refuse backports developers may try to
propose to the branch in error.

> It seems like this just makes more work for people that are
> maintaining older releases since it means they need to make sure
> to mirror things before they go EOL.

No need to mirror them. The final commit to the stable/havana branch
is tagged havana-eol prior to deletion, as my announcement a couple
weeks ago mentioned. This preserves the commit history indefinitely,
so you can always create a local branch from that if you so desire.
-- 
Jeremy Stanley

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

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

[Jeremy Stanley]

On 2014-10-09 14:13:29 -0400 (-0400), Boden Russell wrote:
> If I'm not mistaken; it appears the tag rename from "havana" ->
> "havana-eol" may be effecting the upgrade CI tests in recent
> commits (ex: [1]).
> 
> For example in real-db-upgrade_nova_mysql_user001:th-mysql:
[...]

That's a third-party testing system reporting on those changes, not
run by the OpenStack project. I will however bring it to the
immediate attention of the operators at Rackspace maintaining the
"DB Datasets CI" (formerly "turbo-hipster") system. Thanks for the
heads up!
-- 
Jeremy Stanley

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

Re: [openstack-dev] Can sqlalchemy-migrate-core just be oslo.db core?

[Matt Riedemann]

On 10/9/2014 3:30 PM, Matt Riedemann wrote:

The sqlalchemy-migrate project is basically maintenance mode and the
core team [1] is kind of a weird mix of people - all great people I'm
sure, but I think it's more a team of people that stepped up when
OpenStack took over the project and said they'd babysit it but it's
pretty idle.

Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can
we just have the oslo.db core team [2] own sqlalchemy-migrate now too?

Here are the sqlalchemy-migrate open reviews:

https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z


[1] https://review.openstack.org/#/admin/groups/186,members
[2] https://review.openstack.org/#/admin/groups/331,members



If no one wants this, I'll nominate myself for the sqlalchemy-migrate 
core team to try and keep the lights on.


Here's my code:

https://review.openstack.org/#/q/owner:mrie...@us.ibm.com+project:stackforge/sqlalchemy-migrate,n,z

And reviews:

https://review.openstack.org/#/q/reviewer:mrie...@us.ibm.com+project:stackforge/sqlalchemy-migrate,n,z

--

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] Can sqlalchemy-migrate-core just be oslo.db core?

[Doug Hellmann]

On Oct 9, 2014, at 4:30 PM, Matt Riedemann  wrote:

> The sqlalchemy-migrate project is basically maintenance mode and the core 
> team [1] is kind of a weird mix of people - all great people I'm sure, but I 
> think it's more a team of people that stepped up when OpenStack took over the 
> project and said they'd babysit it but it's pretty idle.
> 
> Given we have oslo.db now, and sqlalchemy-migrate is all DB goodies, can we 
> just have the oslo.db core team [2] own sqlalchemy-migrate now too?
> 
> Here are the sqlalchemy-migrate open reviews:
> 
> https://review.openstack.org/#/q/status:open+project:stackforge/sqlalchemy-migrate,n,z
> 
> [1] https://review.openstack.org/#/admin/groups/186,members
> [2] https://review.openstack.org/#/admin/groups/331,members

If the oslo.db team wants to participate, that’s obviously fine, but I don’t 
think we want to just add everyone in bulk. AIUI, the team’s goal is to get the 
migration stuff in oslo.db working with alembic so we can stop using 
sqlalchemy-migrate.

Doug


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

Re: [openstack-dev] [sahara] team meeting Oct 9 1800 UTC

[Sergey Lukjanov]

Meeting minutes:
http://eavesdrop.openstack.org/meetings/sahara/2014/sahara.2014-10-09-18.02.html

On Wed, Oct 8, 2014 at 10:59 AM, Sergey Lukjanov 
wrote:

> Hi folks,
>
> We'll be having the Sahara team meeting as usual in
> #openstack-meeting-alt channel.
>
> Agenda:
> https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Next_meetings
>
>
> http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meeting&iso=20141009T18
>
> P.S. I'd like to continue discussing design summit sessions.
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
>



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

[Chris Friesen]

On 10/09/2014 02:39 PM, Jeremy Stanley wrote:

On 2014-10-09 11:31:37 -0600 (-0600), Chris Friesen wrote:

Just curious...why do we remove the stable branches for old
releases? Is the idea to force people onto new branches?


It's twofold. First, it's to indicate that the branch will be
getting no new patches ever. Second, it's because that's the only
good way to get Gerrit to refuse backports developers may try to
propose to the branch in error.


Okay, makes sense.


It seems like this just makes more work for people that are
maintaining older releases since it means they need to make sure
to mirror things before they go EOL.


No need to mirror them. The final commit to the stable/havana branch
is tagged havana-eol prior to deletion, as my announcement a couple
weeks ago mentioned. This preserves the commit history indefinitely,
so you can always create a local branch from that if you so desire.


Ah, okay.  Apparently I skimmed too quickly and missed the part about it 
being tagged still.


Thanks for the explanation.

Chris

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

Re: [openstack-dev] [openstack-qa] Post job failures

[Joe Gordon]

What about using graphite + logstash to power a post-job
/nightly-job/post-merge-periodic (the new thing we talked about in Germany)
dashboard?

There are a few different use cases for a dashboard for jobs that don't
report on gerrit changes.

* Track the success an failure rates over time
  * If I am maintaining a a job that doesn't vote anywhere, I will check
this daily
  * If I am part of the core team of a project where one feature is tested
post-merge, I want to periodically check this to see if that feature is
being maintained.
* Provide links to logs for failed jobs so the cause of the failure can be
investigated


We can do all this with graphite on logstash. Graphite for the tracking the
trends (something like http://jogo.github.io/gate/) and logstash to find
the logs for failed jobs (we can get around the 10 day logstash window by
saving the results instead of overwriting them every time we regenerate the
list of log links)

And if we really want some sort of alerts, there are a lot of graphite
tools (http://graphite.readthedocs.org/en/latest/tools.html) that can give
us alerts on metrics (alert me if the last X runs of job-foo-bar failed).


On Wed, Oct 1, 2014 at 9:46 AM, Jeremy Stanley  wrote:

> On 2014-10-01 10:39:40 -0400 (-0400), Matthew Treinish wrote:
> [...]
> > So I actually think as a first pass this would be the best way to
> > handle it. You can leave comments on a closed gerrit changes,
> [...]
>
> Not so easy as it sounds. Jobs in post are running on an arbitrary
> Git commit (more often than not, a merge commit), and mapping that
> back to a change in Gerrit is nontrivial.
> --
> Jeremy Stanley
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning

[James Polley]

> On 10 Oct 2014, at 07:32, Gregory Haynes  wrote:
> 
> Hello TripleO-ers,
> 
> Last time around there was a lot of feedback that we should plan our
> mid-cycle metup a lot sooner, so lets do that! I've created a (mostly
> bare) etherpad here:
> 
> https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
> 
> Note that there are currently no possible venues listed. If you are able
> to provide a possible venue (Thank you!) please reply and/or add it to
> the etherpad.
> 
> I have also listed a few possible Mon-Fri meetup dates. Do not take this
> as any indication that Mon-Fri is an ideal meetup length or time of
> week, and feel free to add feedback / combinations of your own.
> Personally, I felt pretty burned out by Friday last time so maybe
> Mon-Wed is a better size?

Assuming it's in the US or Europe, Mon-Fri gives me about 3 useful days, once 
you take out the time I lose to jet lag. That's barely worth the 48 hours or so 
I spent in transit last time.

I would strongly prefer not to reduce the length of the mid-cycle. I agree that 
it can be quite draining but reducing the length would make it much more 
draining for me. 

I'd feel different if it was hosted somewhere localish to me, and I think it's 
reasonable that we plan the mid-cycle around what works for the majority of 
attendees rather than the minority. But even so, my personal preference is for 
a full week.
> 
> Cheers,
> Greg
> 
> ___
> 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] [keystone] Using 'admin_token' option as token to create keystone client.

[Lei Zhang]

Yes. That will be more safer.

On Fri, Oct 10, 2014 at 12:00 AM, Nader Lahouti  wrote:
> Thanks Lei for the reply and clarification.
> So, instead of that we can use the following:
>
>
> from keystone client.v2_0 import Client
>
> keystone = Client(username=user, password=password, tenant_name=tenant,
> auth_url=url)
>
>
> with user, password, tenant and url can be obtained from cfg.CONF.
>
>
> Thanks,
>
> Nader.
>
>
> On Wed, Oct 8, 2014 at 11:54 PM, Lei Zhang  wrote:
>>
>> it should works but it is not safe to use admin_token. Because
>> * It is a admin token which has the full privilege for the keystone
>> service
>> * The token will be always valid till the admin_token in the conf file
>> is changed.
>>   It is dangerous when the token leak.
>>
>> Suggest that the admin_token is only used for the initial of admin
>> account.
>>
>> On Thu, Oct 9, 2014 at 2:29 PM, Nader Lahouti 
>> wrote:
>> > Hi,
>> >
>> > Is it acceptable to use 'admin_token' option from keystone.conf,  when
>> > creating a keystone client? something like this:
>> >
>> > kc = client.Client(token=cfg.CONF.admin_token,
>> >
>> >endpoint='http://localhost:35357/v2.0/')
>> >
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Nader.
>> >
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Lei Zhang
>> Blog: http://xcodest.me
>> twitter/weibo: @jeffrey4l
>>
>> ___
>> 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
>



-- 
Lei Zhang
Blog: http://xcodest.me
twitter/weibo: @jeffrey4l

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

Re: [openstack-dev] [neutron] Creation of neutron-drivers team

[Damon Wang]

Hope this can accelerate Neutron's development :-)

Regards,
Damon

2014-10-09 5:46 GMT+08:00 Kyle Mestery :

> Sure, I'll add that section there.
>
> On Tue, Oct 7, 2014 at 2:58 PM, Kevin Benton  wrote:
> > Can you add a section to the wiki to document how a core can become a
> member
> > of the drivers team?
> >
> > On Tue, Oct 7, 2014 at 7:55 AM, Kyle Mestery 
> wrote:
> >>
> >> As discussed in today's meeting [1], I've created a neutron-drivers
> >> team [2], which was modeled on the same way as the existing
> >> nova-drivers team. This team will be responsible for approving specs
> >> for Kilo. Please see the wiki page for the long story, but the short
> >> story is that as focused team driving spec approval and a consistent
> >> architectural approach for Neutron in Kilo will be good for the
> >> long-term health of the project.
> >>
> >> As with all things process related, we'll try this out in Kilo and
> >> adjust accordingly at the end. I wanted to keep the broader community
> >> aware of this new team.
> >>
> >> Thanks!
> >> Kyle
> >>
> >> [1]
> >>
> http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-10-07-14.01.html
> >> [2] https://wiki.openstack.org/wiki/Neutron-drivers
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
> >
> > ___
> > 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] [all] [tc] Multi-clouds integration by OpenStack cascading

[joehuang]

Hello, Duncan,

You are right. It's not simple multiplier game. 

The performance or scalability bottleneck is mainly impacted from two aspect: 
request concurrency to the cloud, and the volume of the objects (including 
VM,Volume,Port,etc).

We can discuss that in a scenario: there are 1 million VMs in the cloud, and 
one cascading OpenStack manages 100 cascaded OpenStacks, the concurrency of 
request and data volume will be distributed evenly among cascaded OpenStacks. 
Let's suppose the concurrency of request is 1000 TPS.

For the cascaded layer: TPS is 10, and the VM instance object table contains 
10K VMs (or more, for some record deleted but stay there). It's much easier to 
install and tune performance in such scale.

For the cascading layer: TPS is 1000, and the VM instance object table contains 
1 million VMs (or more, for some record deleted but stay there). In the 
cascading layer, only 100 proxy nodes to be managed by the cascading OpenStack. 
If we scale one OpenStack to manage a 1 million VMs cloud, and suppose one 
compute nodes can run 20 VMs, then there are 50k compute nodes.

The challenge to scale the cascading OpenStack is smaller than one normal 
OpenStack instance to manage a cloud with 1 million VMs. The following 
performance advantage is obviously:

1. Reduce scheduling burden. Nova,Cinder scheduling only according to 
availability zone.
2. Nova,Cinder Host status and resources track task is much light weight
3. Reduce temporary status update to the DB. There are lots of internal state 
update messages during VM/volume creation. The number of exchanged message / DB 
access for one VM/Volume creation will be reduced greatly by batch periodic 
polling the VM/Volume stabl status from the cascaded OpenStack.
4. Less L2 population and L3 DVR router update nodes involved. Because the 
L2/L3 proxy delegates one cascaded OpenStack, and often VMs of one 
tenant/network will be limitedly located in one or two or three cascaded 
OpenStacks, the L2 population and L3 DVR population traffic will be greatly 
reduced in the cascading level
5. Ceilometer data will be collected in distributed ceilometers. I mentioned 
for 1 million level cloud, it's roughly estimated 20GB/minute data will be 
generated(based on current sampling way).   

But, The performance enhancement by cascading is not simple multiplier to a 
cascaded OpenStack scalability, although it provide a way to scale a cloud 
easier. 

That's because, the concurrency and latency for DB query is not easy to achieve 
linear growth with more resources to put into, even if we split DB and tables. 
For big table, RDBMS cannot realize very good CRUD performance. And also, the 
concurrency will heavily be affected by the ceiling of message bus.

Therefore, and as what we have discussed, the scalability of one OpenStack 
instance is always necessary and it's the fundamental for OpenStack cascading.

Best Regards
Chaoyi Huang ( Joe Huang )


-Original Message-
From: Duncan Thomas [mailto:duncan.tho...@gmail.com] 
Sent: Friday, October 10, 2014 3:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack 
cascading

On 9 October 2014 07:49, henry hly  wrote:
> Hi Joshua,
>
> ...in fact hierarchical scale
> depends on square of single child scale. If a single child can deal 
> with 00's to 000's, cascading on it would then deal with 00,000's.

That is faulty logic - maybe the cascading solution needs to deal with global 
quota and other aggregations that will rapidly break down your scaling factor, 
or maybe there are few such problems can the cascade part can scale way better 
than the underlying part. They are two totally different scaling cases, so and 
suggestion that they are anything other than an unknown multiplier is bogus.

___
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] [swift] Allow hostname for nodes in Ring

[Osanai, Hisashi]

Hi Swift folks,

Today the following patch was abandoned and I contacted with the author, 
so I would like to take it over if nobody else is chafing to take it.
Is it OK?

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

If it is OK, I will proceed it with following procedure.
(1) Open new bug report (there is no bug report for this)
I'm not sure that I should write a BP instead of a bug report.
(2) Make a patch based on the current patch on gerrit

Cheers,
Hisashi Osanai


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

[openstack-dev] TC Candidacy

[John Griffith]

I'd like to announce my candidacy for the OpenStack Technical Committee
Fall 2014 elections.

I've been contributing to OpenStack for almost three years now (this months
my anniversary) and up until this election cycle have served as PTL for the
Cinder Project.  Over the years I've had the opportunity to be on the TC
both as a result of PTL (back when PTL's were reserved seats) as well as by
election.  Last spring however I chose not to run for a seat, for a number
of reasons.  For one I didn't feel as though I had the bandwidth to really
dedicate as much as I should but more importantly I didn't necessarily feel
that what I was doing was really that worthwhile.

Since then there's been a number of ideas proposed about changing some of
our models including the role of the TC.  I really believe that this is
something that we need to do and am excited about the potential
opportunity.  I think there's a lot that needs to be done here, I also
think it's going to be a learning experience and something that's needed is
an open mind.

After the Juno cycle I decided not to seek another term as PTL partly
because I didn't feel that I would be able to effectively fulfill the role
of PTL and serve as a member of the TC.  So I decided that for me, I'd like
the opportunity (if elected) to focus on contributing more broadly to
OpenStack with a focus on service on the Technical Committee.

Answers to the candidacy questions are below.

Thanks,
John



Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack
Mission?

Just as a refresh: "To produce the ubiquitous OpenSource Cloud Computing
platform that will meet the needs of public and private clouds regardless
of size, by being simple to implement and massively scalable."

So I always find this one a bit challenging to digest to be honest.  I
think the "ubiquitous" part is coming along and is becoming a reality and I
also think that there's a decent balance between public and private clouds
and that the relative term "size" could be interpreted as something that's
being addressed fairly well thus far.

Those are the good now for the not so good; "simple to implement"; I
don't think deployment is  quite as bad as it's made out to be at times,
but it certainly leaves a bit to be desired.  One thing that's always
bothered me here is that it's always been "left to the distros" to provide
their custom deployment tools and we've never been able to even provide a
common deployment foundation as a community.  I really think that's too
bad, you can build the greatest software project there is, but if people
can't comprehend all the pieces let alone install and configure it fairly
easily it's really not living up to it's potential.

>From the perspective of the TC, I'm really not sure what role the TC is
playing in the overall mission to be honest.  In my opinion the TC has
really become mostly a committee relegated to voting on project incubation
and proposals for things like project mission statements.  It's really not
very technical in my opinion and it's also not overly effective either.

In my opinion the TC needs to undergo some changes, it would be great as
others mentioned to move away from just voting on incubation motions and
mission statements or gap analysis efforts and actually focus more on
technical decisions that impact OpenStack as a whole.  For example I think
it would be great for the TC to take a more active role in really having a
deep understanding of how all of the various OpenStack projects are
actually coming together, what they're doing that works, what they're doing
that's not and perhaps provide some guidance and input as well as technical
leadership and direction.  I'm certainly not saying they should be an all
powerful oversight group, but I do think the focus as it stands currently
is wrong.


Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical
committee mission?
(Reading from the Mission Statement here: [2])

I'm not sure that given the current state of OpenStack and the number of
projects and proposed projects the TC can be faulted for anything here.
The fact is that it's become a full time job to just try and keep up to
date on all the constantly changing projects in the ecosystem, not to
mention all the newly proposed projects.  I do think that it would be
helpful if the TC was able to be adjusted and tweaked a bit such that it
had a more active engagement in technical direction of the project; say for
example driving things like making installation more of a community effort,
providing HA options that really work and most of all pushing every project
in OpenStack to be responsible for making the upgrade process better.  I
also think that the TC needs to make some really hard decisions about
things; like projects that have been started, approved for incubation but
maybe aren't really turning out as was hoped.  In my opinion there are a
number o

[openstack-dev] TC Candidacy

[David Lyle]

I would like to announce my candidacy for the Technical Committee.

I have been working on OpenStack since the beginning of the Grizzly cycle.
I started working on OpenStack as part of HP's Public Cloud effort. I spent
two years working to make Horizon work in that scale of environment and
making Horizon the user facing interface of HP's Public Cloud. I have
served as a Horizon core reviewer since the Havana cycle and I am starting
my third release as Horizon PTL. Currently, I am employed by Intel in their
Open Source Technology Center.

I have been a regular observer of the Technical Committee during my time as
PTL. The role of the TC is large and difficult. I appreciate the efforts of
all those that have served during that time and I would like to thank them
for their dedication. One takeaway from those observations in the very
heavy representation on the TC by infrastructure and core services. I think
the TC would be benefit from more representation higher up the stack. I
think Heat, Horizon, Solum, TripleO have a unique perspective into
cross-project issues and the TC would benefit from such representation.

In my opinion, the fundamental problems the TC needs to address in the Kilo
cycle are handling growth and cross-project alignment. I'll be honest, I
don't have a master plan to address these, but I think I'm well equipped
and motivated to help develop that plan with other members of the TC.

Thanks for your consideration,
David Lyle


Topic: OpenStack Mission: How do you feel the technical community is doing
in meeting the OpenStack Mission?


"To produce the ubiquitous OpenSource Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable."

I think this is a very broad mission. Breadth is not a problem, but there
are a few implications in here. One OpenStack needs to be inclusive, to
accomplish ubiquity we need to strive to allow deployers to meet their
widely varied needs. So we need to support a large ecosystem. The ecosystem
around OpenStack is certainly large, but there is a fairly sharp dichotomy
between OpenStack and not OpenStack, recognizing larger parts of the
ecosystem is important for ecosystem health. As to public vs private and
massively scalable aspects, I think we have room for growth. Running a
public cloud on OpenStack requires not insignificant changes, and OpenStack
has room for improvement on the scalability front. We need greater feedback
from the very large deployers to make sure we meet those scalability needs.

Topic: Technical Committee Mission: How do you feel the technical committee
is doing in meeting the technical committee mission?


"The Technical Committee ("TC") is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project."

The technical committee has spent much of the last cycle acting as gate
keeper. I would like to see it take a larger role in overall architectural
direction in OpenStack. I believe one of the greatest challenges we face is
coherency of vision and direction. I think this should be the province of
the technical committee to act as an arbitrar and architectural board. I
don't hold that overall technical direction is to be dictated by the TC,
rather the TC merely helps unify that direction and insures consistency.
Obviously this is a herculean task, but I believe OpenStack needs more
clearness in direction.

Topic: Contributor Motivation: How would you characterize the various
facets of contributor motivation?


Contributors are motivated to contribute for various reasons. People
contribute for personal interest, corporate interest, academic interest,
and any mix of all three. Corporate interest covers a lot, from users to
operators, vendors to consumers. Many ideas from our great community of
diverse contributors helps drive us forward and keeps us honest and
progressing.

At the end of the day, OpenStack is cloud software that should be usable.
We do need to temper the wouldn't it be neat if, with how will this work in
real world application ranging from small test clouds to large public
clouds. Services should strive to work across this spectrum. The difficulty
is focusing these disparate motivations into a cohesive effort.

Topic: Rate of Growth: 

Re: [openstack-dev] TC Candidacy

[Anita Kuno]

confirmed

On 10/10/2014 01:22 AM, John Griffith wrote:
> I'd like to announce my candidacy for the OpenStack Technical Committee
> Fall 2014 elections.
> 
> I've been contributing to OpenStack for almost three years now (this months
> my anniversary) and up until this election cycle have served as PTL for the
> Cinder Project.  Over the years I've had the opportunity to be on the TC
> both as a result of PTL (back when PTL's were reserved seats) as well as by
> election.  Last spring however I chose not to run for a seat, for a number
> of reasons.  For one I didn't feel as though I had the bandwidth to really
> dedicate as much as I should but more importantly I didn't necessarily feel
> that what I was doing was really that worthwhile.
> 
> Since then there's been a number of ideas proposed about changing some of
> our models including the role of the TC.  I really believe that this is
> something that we need to do and am excited about the potential
> opportunity.  I think there's a lot that needs to be done here, I also
> think it's going to be a learning experience and something that's needed is
> an open mind.
> 
> After the Juno cycle I decided not to seek another term as PTL partly
> because I didn't feel that I would be able to effectively fulfill the role
> of PTL and serve as a member of the TC.  So I decided that for me, I'd like
> the opportunity (if elected) to focus on contributing more broadly to
> OpenStack with a focus on service on the Technical Committee.
> 
> Answers to the candidacy questions are below.
> 
> Thanks,
> John
> 
> 
> 
> Topic: OpenStack Mission
> How do you feel the technical community is doing in meeting the OpenStack
> Mission?
> 
> Just as a refresh: "To produce the ubiquitous OpenSource Cloud Computing
> platform that will meet the needs of public and private clouds regardless
> of size, by being simple to implement and massively scalable."
> 
> So I always find this one a bit challenging to digest to be honest.  I
> think the "ubiquitous" part is coming along and is becoming a reality and I
> also think that there's a decent balance between public and private clouds
> and that the relative term "size" could be interpreted as something that's
> being addressed fairly well thus far.
> 
> Those are the good now for the not so good; "simple to implement"; I
> don't think deployment is  quite as bad as it's made out to be at times,
> but it certainly leaves a bit to be desired.  One thing that's always
> bothered me here is that it's always been "left to the distros" to provide
> their custom deployment tools and we've never been able to even provide a
> common deployment foundation as a community.  I really think that's too
> bad, you can build the greatest software project there is, but if people
> can't comprehend all the pieces let alone install and configure it fairly
> easily it's really not living up to it's potential.
> 
> From the perspective of the TC, I'm really not sure what role the TC is
> playing in the overall mission to be honest.  In my opinion the TC has
> really become mostly a committee relegated to voting on project incubation
> and proposals for things like project mission statements.  It's really not
> very technical in my opinion and it's also not overly effective either.
> 
> In my opinion the TC needs to undergo some changes, it would be great as
> others mentioned to move away from just voting on incubation motions and
> mission statements or gap analysis efforts and actually focus more on
> technical decisions that impact OpenStack as a whole.  For example I think
> it would be great for the TC to take a more active role in really having a
> deep understanding of how all of the various OpenStack projects are
> actually coming together, what they're doing that works, what they're doing
> that's not and perhaps provide some guidance and input as well as technical
> leadership and direction.  I'm certainly not saying they should be an all
> powerful oversight group, but I do think the focus as it stands currently
> is wrong.
> 
> 
> Topic: Technical Committee Mission
> How do you feel the technical committee is doing in meeting the technical
> committee mission?
> (Reading from the Mission Statement here: [2])
> 
> I'm not sure that given the current state of OpenStack and the number of
> projects and proposed projects the TC can be faulted for anything here.
> The fact is that it's become a full time job to just try and keep up to
> date on all the constantly changing projects in the ecosystem, not to
> mention all the newly proposed projects.  I do think that it would be
> helpful if the TC was able to be adjusted and tweaked a bit such that it
> had a more active engagement in technical direction of the project; say for
> example driving things like making installation more of a community effort,
> providing HA options that really work and most of all pushing every project
> in OpenStack to be responsible for making the upgrade process b

Re: [openstack-dev] [api] Forming the API Working Group

[Christopher Yeoh]

Hi Everett,

Great to see things moving with the API Working Group!

On Thu, Oct 9, 2014 at 9:35 AM, Everett Toews 
wrote:

> https://wiki.openstack.org/wiki/API_Working_Group
>
> This is the start of the API Working Group (API WG).
>
> To avoid bike shedding over the name of the working group, I decided to
> title the wiki page API Working Group. Simple, to the point, and avoids
> loaded terms like standards, best practices, guidelines, conventions, etc.
>
> The point isn’t what we name it. The point is what action we take about
> it. I propose the deliverables in the API WG wiki page.
>
>
I agree with what you've written on the wiki page. I think our priority
needs to be to flesh out
https://wiki.openstack.org/wiki/Governance/Proposed/APIGuidelines
so we have something to reference when reviewing specs. At the moment I see
that document as something anyone should be able to document a project's
API convention even if they conflict with another project for the moment.
Once we've got a fair amount of content we can start as a group resolving
any conflicts.



> Speaking of the wiki page, I wrote it very matter-of-factly. As if this is
> the way things are. They’re not. The wiki page is just a starting point. If
> something was missed, add it. If something can be improved, improve it.
> Let’s try to keep it simple though.
>
>
One problem with API WG members reviewing spec proposals that affect the
API is finding the specs in the first place across many different projects
repositories.


> I invite everyone who chimed in on the original thread [1] that kicked
> this off to add themselves as a member committed to making the OpenStack
> APIs better. I’ve Cc’d everyone who asked to be kept in the loop.
>
> I already see some cross project summit topics [2] on APIs. But frankly,
> with the number of people committed to this topic, I’d expect there to be
> more. I encourage everyone to submit more API related sessions with better
> descriptions and goals about what you want to achieve in those sessions.
>
>
Yea if there is enough content in the API guidelines then perhaps some time
can be spent on working on resolving any conflicts in the document so
projects know what direction to head in.

Regards,

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

[openstack-dev] [Fuel] Generic descriptive format for deployment tasks

[Dmitriy Shulyak]

Hi team,
After several discussions i want to propose generic format
for describing deployment tasks, this format is expected to cover
all tasks (e.g pre-deployment and post-deployment), also it should cover
different actions like upgrade/patching

action: upload_file
id: upload_astute
roles: *
parameters:
input: $.data - this is internal mistral thing
timeout: 50

action: tasklib
id: generate_keys
stages: [pre-deployment]
roles: master
parameters:
timeout: 60
command: generate/keys
type: puppet
manifest: /etc/puppet/manifests/key_generator.pp

action: tasklib
id: rsync_puppet
stages: [pre-node]
requires: [upload_astute]
parameters:
timeout: 100
command: rsync/stuff
type: shell
cmd: python rsync.py

action: tasklib
id: ceph
roles: [ceph-osd, ceph-mon]
requires: [rsync_puppet]
parameters:
timeout: 100
command: deployment/ceph
type: puppet
manifest: /etc/puppet/manifests/ceph.pp

action: tasklib
id: glance/image
roles: [controller, primary-controller]
stages: [post-deployment]
parameters:
timeout: 100
command: deployment/glance/image
type: shell
cmd: python upload_image.py

Let me provide some clarifications:
1. As example, we want to generate keys strictly before deployment, and the
1st way to solve
it is to introduce concept of stages, e.g pre-deployment, main, upgrade,
post-deployment.
Another one would be to use virtual roles and/or virtual tasks like
deployment_started, deployment_ended.
We need to consider both, but stages it is what we are using now, and i am
just trying to generalize and make it data-driven.
2. Another internal thing is roles. As you can see in this configs there is
2
specific keywords for roles:
* - means task should be executed on all roles
master - task should be only executed on fuel master node
All other roles should be entities from fuel. If you know other exceptions
- lets discuss them.

I would like to ask team for 2 things:
1. Examine approach and ask questions about any specific tasks, in order to
test
this approach for sanity.
2. If you think that some of the keywords in configuration is not
appropriate, lets discuss it. For example we can not agree on term "stage",
because it is too widely used and basically we need another one.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] TC Candidacy

[Anita Kuno]

confirmed

On 10/10/2014 01:52 AM, David Lyle wrote:
> I would like to announce my candidacy for the Technical Committee.
> 
> I have been working on OpenStack since the beginning of the Grizzly cycle.
> I started working on OpenStack as part of HP's Public Cloud effort. I spent
> two years working to make Horizon work in that scale of environment and
> making Horizon the user facing interface of HP's Public Cloud. I have
> served as a Horizon core reviewer since the Havana cycle and I am starting
> my third release as Horizon PTL. Currently, I am employed by Intel in their
> Open Source Technology Center.
> 
> I have been a regular observer of the Technical Committee during my time as
> PTL. The role of the TC is large and difficult. I appreciate the efforts of
> all those that have served during that time and I would like to thank them
> for their dedication. One takeaway from those observations in the very
> heavy representation on the TC by infrastructure and core services. I think
> the TC would be benefit from more representation higher up the stack. I
> think Heat, Horizon, Solum, TripleO have a unique perspective into
> cross-project issues and the TC would benefit from such representation.
> 
> In my opinion, the fundamental problems the TC needs to address in the Kilo
> cycle are handling growth and cross-project alignment. I'll be honest, I
> don't have a master plan to address these, but I think I'm well equipped
> and motivated to help develop that plan with other members of the TC.
> 
> Thanks for your consideration,
> David Lyle
> 
> 
> Topic: OpenStack Mission: How do you feel the technical community is doing
> in meeting the OpenStack Mission?
> 
> 
> "To produce the ubiquitous OpenSource Cloud Computing platform that will
> meet the needs of public and private clouds regardless of size, by being
> simple to implement and massively scalable."
> 
> I think this is a very broad mission. Breadth is not a problem, but there
> are a few implications in here. One OpenStack needs to be inclusive, to
> accomplish ubiquity we need to strive to allow deployers to meet their
> widely varied needs. So we need to support a large ecosystem. The ecosystem
> around OpenStack is certainly large, but there is a fairly sharp dichotomy
> between OpenStack and not OpenStack, recognizing larger parts of the
> ecosystem is important for ecosystem health. As to public vs private and
> massively scalable aspects, I think we have room for growth. Running a
> public cloud on OpenStack requires not insignificant changes, and OpenStack
> has room for improvement on the scalability front. We need greater feedback
> from the very large deployers to make sure we meet those scalability needs.
> 
> Topic: Technical Committee Mission: How do you feel the technical committee
> is doing in meeting the technical committee mission?
> 
> 
> "The Technical Committee ("TC") is tasked with providing the technical
> leadership for OpenStack as a whole (all official programs, as defined
> below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
> Integration, Quality...), decides on issues affecting multiple programs,
> forms an ultimate appeals board for technical decisions, and generally has
> oversight over all the OpenStack project."
> 
> The technical committee has spent much of the last cycle acting as gate
> keeper. I would like to see it take a larger role in overall architectural
> direction in OpenStack. I believe one of the greatest challenges we face is
> coherency of vision and direction. I think this should be the province of
> the technical committee to act as an arbitrar and architectural board. I
> don't hold that overall technical direction is to be dictated by the TC,
> rather the TC merely helps unify that direction and insures consistency.
> Obviously this is a herculean task, but I believe OpenStack needs more
> clearness in direction.
> 
> Topic: Contributor Motivation: How would you characterize the various
> facets of contributor motivation?
> 
> 
> Contributors are motivated to contribute for various reasons. People
> contribute for personal interest, corporate interest, academic interest,
> and any mix of all three. Corporate interest covers a lot, from users to
> operators, vendors to consumers. Many ideas from our great community of
> diverse contributors helps drive us forward and keeps us honest and
> progressing.
> 
> At the end of the day, OpenStack is cloud software that should be usable.
> We do need to temper the wouldn't it be neat if, with how will this work in
> real world appl

[openstack-dev] [TripleO] prep-source-repos - new tool for managing repos+patchsets?

[James Polley]

I've got a new tool, currently called prep-source-repos, that I'd like to
set up as a new project. Most of the work was done by adamg and lifeless,
with a bit of polish from me to make it ready to be packaged.

The tool is something the tripleo-cd-admins have been using to let us
deploy a cloud from trunk + unlanded patchsets from Gerrit. It takes a YAML
file with a list of repos to clone, then allows for individual gerrit
patches to be added on top. It also creates a file with all the DIB_REPO*
variables required to have DIB use these local patched repos rather than
the upstream repos.

This allows us to test out patches - to TripleO tools, but also to any of
the other openstack tools we install from source - without needing to wait
for them to land.

I believe it's something that can be useful in other places as well though:

* I think that it could replace
http://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/pull-tools
as something we use inside TripleO to pull and update the tools we use
* In https://review.openstack.org/#/c/118426/ jp_at_hp proposed a simpler
tool that applies patches from gerrit to individual repos; I think
prep-source-repos solves the need for this as well
* At one point I was running Gertty from trunk with a whole bunch of
un-landed patches from lifeless and I. To make things easier on myself, I'd
pushed my changes to Gerrit as being a big dependency chain, which didn't
reflect reality. push-source-repose would make it easy to run Gerrit from
upstream trunk + pull in all my unlanded patches, without needed to set up
a fake dependency tree.

The code is currently sitting at
https://github.com/jamezpolley/prep-source-repos, but I'd like to add it to
git.openstack.org, (probably as a stackforge project) if there's consensus
that this is something we'd find useful.

So, right now, I've got two questions for the team:

* Can you think of a better name? prep-source-repos sounds a bit clumsy to
me, but I haven't been able to come up with anything I like better.
* Am I wrong in thinking that this tool is useful enough to be worth
splitting out into its own repo?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev