date:20141007

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/10/14 17:56, Doug Hellmann wrote:
> The Oslo team is responsible for managing code shared between
> projects. There are a LOT more projects than Oslo team members, so
> we created the liaison program at the beginning of the Juno cycle,
> asking each team that uses Oslo libraries to provide one volunteer
> liaison. Our liaisons facilitate communication and work with us to
> make the application code changes needed as code moves out of the
> incubator and into libraries. With this extra help in place, we
> were able to successfully graduate 7 new libraries and begin having
> them adopted across OpenStack.
> 
> With the change-over to the new release cycle, it’s time to ask for
> volunteers to sign up to be liaisons again. If you are interested
> in acting as a liaison for your project, please sign up on the wiki
> page [1]. It would be very helpful to have a full roster before the
> summit, so we can make sure liaisons are invited to participate in
> any relevant discussions there.
> 
> Thanks, Doug
> 
> [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons

Quoting the page: "The liaison should be a core reviewer for the
project." Is it a reasonable limitation? I suspect that being an Oslo
liaison usually does not really require the core status. Any team
member with visible level of participation in the project and decent
communication skills should be able to do the job.

Why I ask: I would probably consider signing up for the liaison
program from Neutron side if 1) the program rules would not be that
tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
against it.

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

iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R
sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN
9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI
bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv
04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf
tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM=
=+HC1
-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] sign up for oslo liaisons for kilo cycle

2014-10-07 Thread Salvatore Orlando

I am totally not against it.
I agree with you that probably the restriction on core-only might be
lifted, but that decision lies with the oslo team.

Salvatore

On 7 October 2014 13:55, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 06/10/14 17:56, Doug Hellmann wrote:
> > The Oslo team is responsible for managing code shared between
> > projects. There are a LOT more projects than Oslo team members, so
> > we created the liaison program at the beginning of the Juno cycle,
> > asking each team that uses Oslo libraries to provide one volunteer
> > liaison. Our liaisons facilitate communication and work with us to
> > make the application code changes needed as code moves out of the
> > incubator and into libraries. With this extra help in place, we
> > were able to successfully graduate 7 new libraries and begin having
> > them adopted across OpenStack.
> >
> > With the change-over to the new release cycle, it’s time to ask for
> > volunteers to sign up to be liaisons again. If you are interested
> > in acting as a liaison for your project, please sign up on the wiki
> > page [1]. It would be very helpful to have a full roster before the
> > summit, so we can make sure liaisons are invited to participate in
> > any relevant discussions there.
> >
> > Thanks, Doug
> >
> > [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
>
> Quoting the page: "The liaison should be a core reviewer for the
> project." Is it a reasonable limitation? I suspect that being an Oslo
> liaison usually does not really require the core status. Any team
> member with visible level of participation in the project and decent
> communication skills should be able to do the job.
>
> Why I ask: I would probably consider signing up for the liaison
> program from Neutron side if 1) the program rules would not be that
> tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
> against it.
>
> Cheers,
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R
> sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN
> 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI
> bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv
> 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf
> tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM=
> =+HC1
> -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] sign up for oslo liaisons for kilo cycle

2014-10-07 Thread Davanum Srinivas

Ihar,

Welcome! and thanks for considering signing up to be liaison :) As
oslo core, i'd support the relaxation. I think the thinking behind the
wording was "it would help if folks were core"

-- dims

On Tue, Oct 7, 2014 at 7:55 AM, Ihar Hrachyshka  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 06/10/14 17:56, Doug Hellmann wrote:
>> The Oslo team is responsible for managing code shared between
>> projects. There are a LOT more projects than Oslo team members, so
>> we created the liaison program at the beginning of the Juno cycle,
>> asking each team that uses Oslo libraries to provide one volunteer
>> liaison. Our liaisons facilitate communication and work with us to
>> make the application code changes needed as code moves out of the
>> incubator and into libraries. With this extra help in place, we
>> were able to successfully graduate 7 new libraries and begin having
>> them adopted across OpenStack.
>>
>> With the change-over to the new release cycle, it’s time to ask for
>> volunteers to sign up to be liaisons again. If you are interested
>> in acting as a liaison for your project, please sign up on the wiki
>> page [1]. It would be very helpful to have a full roster before the
>> summit, so we can make sure liaisons are invited to participate in
>> any relevant discussions there.
>>
>> Thanks, Doug
>>
>> [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
>
> Quoting the page: "The liaison should be a core reviewer for the
> project." Is it a reasonable limitation? I suspect that being an Oslo
> liaison usually does not really require the core status. Any team
> member with visible level of participation in the project and decent
> communication skills should be able to do the job.
>
> Why I ask: I would probably consider signing up for the liaison
> program from Neutron side if 1) the program rules would not be that
> tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
> against it.
>
> Cheers,
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iQEcBAEBCgAGBQJUM9SVAAoJEC5aWaUY1u57jEYIAK3MTR+WwkHP9YxrexRQZl0R
> sJ5Y2fDZVbfUzypLIpOdEizTmPVs7jvHzUZnK48cgTG1RDiuO2BBZA0F08nsZnXN
> 9eJ6VABiD1ZRyctIa9yMeuSIspenDpJYWoPnnE6Z0y0vnJz0JlXnsgHRpvvIOwYI
> bS73fUlpr7X5bHBE4+QT1ByeWVklBjO/TPzmiyzeMONBw2sg2feRXKtWJ0S1COuv
> 04U7hvjbAn7ujP7nC8VhnRsIDqYoZ0l7I0zPuZXKqWLME6JLRL8XYt3GL77RCrLf
> tQJVynpRrAYCgM33NqqEqIxqnHo7gLHDjEj10ekUO+1d6ZFEdR48apA1Zc6Q7YM=
> =+HC1
> -END PGP SIGNATURE-
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

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

Re: [openstack-dev] [devstack] local.conf ini file setting issues

2014-10-07 Thread Robert Li (baoli)

Hi Ian,

I agree with your plan. I¹ve +1ed the first two patches.

I responded to your comments on [3]. Basically I think that iniadd_literal
is necessary. In addition, [3] will also keep the original order of items.

With all of the three patches, I think the end result would be that it¹s
almost exact copy from local.conf to the destination config file.


‹Robert

On 10/6/14, 9:38 PM, "Ian Wienand"  wrote:

>Hi,
>
>Rather than adding more MAGIC_VARIABLE="foo" variables to devstack
>that really only add lines to config files, I've been asking people to
>add them to local.conf and provide additional corresponding
>documentation if required.
>
>However increased use has exposed some issues, now covered by several
>reviews.  There seem to be three issues:
>
>  1. preservation of quotes
>  2. splitting of arguments with an '=' in them
>  3. multi-line support
>
>We have several reviews not dependent on each other but which will all
>conflict.  If we agree, I think we should
>
>  1. merge [1] to handle quotes
>  2. merge [2] to handle '='s
>  3. extract just multi-line support from [3]
>
>All include test-cases, which should increase confidence
>
>--
>
>I did consider re-implementing a python tool to handle this; there
>were some things that made me think twice.  Firstly ini settings in
>local.conf are expected to expand shell-vars (path to neutron plugin
>configs, etc) so you end up shelling out anyway.  Secondly
>ConfigParser doesn't like "[[foo]]" as a section name (drops the
>trailing ], maybe a bug) so you have to start playing games there.
>Using a non-standard library (oslo.config) would be a big change to
>devstack's current usage of dependencies.
>
>-i
>
>[1] https://review.openstack.org/124227
>[2] https://review.openstack.org/124467/
>[3] https://review.openstack.org/124502


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

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 06/10/14 19:10, Mike Bayer wrote:
> 
> On Oct 6, 2014, at 9:56 AM, Ihar Hrachyshka 
> wrote:
> 
>>> 
>>> But we can do better. We should also enforce utf8 on client
>>> side, so that there is no way to run with a different encoding,
>>> and so that we may get rid of additional options in sql
>>> connection strings. I've sent a patch for oslo.db [4] to do
>>> just that.
> 
> i would recommend that we definitely do *not* set explicit client
> encodings on all columns, and go with the most minimal approach for
> whatever the target database is.For example, with Postgresql
> 8.4, utf-8 is not an issue so long as client_encoding is set within
> postgresql.conf.I’ve had this kind of discussion many times in
> the past with folks who are trying to “protect” some subset of
> users that don’t have this setting in their conf file, either
> because they installed from an OSX package or some other weird
> reason, and generally I’m not buying it.There’s no need to
> build tremendous verbosity and fine-grained specificity throughout
> a system in order to appease very narrow edge cases like this.
> It’s not just about potential performance problems, it’s also just
> a schema and code management issue, in that it is complexity that
> IMHO is just not needed.

- From server side, indeed, proper configuration described in
documentation may be enough. Though atm we don't document PostgreSQL
settings anywhere.

[As for MySQL, both server and client encodings are indeed advised to
be set to utf8.]

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?

> 
> For this reason I’m pretty ambivalent overall about any kind of
> utf-8 hardcoding within the application connection logic.  IMHO
> this should be handled at the configurational layer as much as
> possible.  Though as long as it’s just an application time setting,
> and not something hardwired throughout the schema (implying we now
> have to *rely* upon UTF-8 encoding explicitly for all columns
> everywhere…and then what happens if we are on some target database
> that doesn’t quite do things the same way, e.g. DB2, oracle,
> others?), it’s not *too* big of a deal for me if it solves some
> problems right now.

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.

> 
> short answer, there should be no need to drop PG8.X support for
> this reason.   If the client encoding setting is something we want
> hardcoded in the app layer and it fails for those versions (which
> I’m not familiar with? what is the thing that is not actually
> supported prior to libpq 9.1 ?  psycopg2’s set_client_encoding,
> really?   this doesn’t sound familiar two me), we can detect that
> and forego the setting - sqlalchemy dialect has server_version_info
> for this reason.

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

As I said before, we have other ways to set client encoding for psql
clients that use libpq < 9.1, and the thing I try to determine is
whether we consider supporting those versions of libpq.

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

iQEcBAEBCgAGBQJUM9yfAAoJEC5aWaUY1u571T0IALBgfRSL0PY1q9PC/vpiee2B
d++dVM+CU/SRhXh7zlY703K/sdRVvsPGlUNkzPjT0TGa81LbXPKtwVqPIQeUpI5i
a+X9HKHksaeidgLyuOPbSic+hFSoQESoYBswLfb0+vhT9JEn2XwzEyJo83c4MDH3
grgi5Crk+xx2uAa3mnEKCkeCOiq6t6V+7s7DKM8qdAEZOvKWlY3JK5W+AF6Smjlj
XJkywLXkDy+t+jMMIo2XqlR7xIVoy4wSTZRgbqrHpBqxqhL3/wzk31JnQgant8A+
2HF8p+Goy0CxoLOYb0LCE4JiHh6aoHXCcUOXW9BmcVBxfRg7el3OcKWJb9g2Q+M=
=78+Z
-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] Candidate proposals for TC (Technical Committee) positions are now open

2014-10-07 Thread Anita Kuno

On 10/07/2014 05:12 AM, Angus Salkeld wrote:
> On Tue, Oct 7, 2014 at 6:16 PM, Flavio Percoco  wrote:
> 
>> On 10/06/2014 08:58 PM, Anita Kuno wrote:
>>> On 10/06/2014 12:38 PM, Anita Kuno wrote:
 On 10/03/2014 12:16 PM, Flavio Percoco wrote:
> On 10/03/2014 05:38 PM, Tristan Cacqueray wrote:
>> Candidate proposals for the Technical Committee positions (6
>> positions)
>> are now open and will remain open until 05:59 UTC October 10, 2014.
>>
>> Candidates for the Technical Committee Positions: Any Foundation
>> individual member can propose their candidacy for an available,
>> directly-elected TC seat. [0] (except the seven TC members who were
>> elected for a one-year seat last April: Thierry Carrez, Jay Pipes,
>> Vishvananda Ishaya, Michael Still, Jim Blair, Mark McClain, Devananda
>> van der Veen) [1]
>>
>> Propose your candidacy by sending an email to the openstack-dev at
>> lists.openstack.org mailing-list, with the subject: "TC candidacy".
>> Please start your own thread so we have one thread per candidate.
>> Since
>> there will be many people voting for folks with whom they might not
>> have
>> worked, including a platform or statement to help voters make an
>> informed choice is recommended, though not required.
>>
>> NEW: In order to help the electorate learn more about the candidates
>> we
>> have posted a template of questions to which all candidates are
>> requested to respond. [2]
>>
>> Anita and I will confirm candidates with an email to the candidate
>> thread as well as create a link to the confirmed candidate's proposal
>> email on the wikipage for this election. [1]
>>
>> The election will be held from October 10 through to 13:00 UTC October
>> 17, 2014. The electorate are the Foundation individual members that
>> are
>> also committers for one of the official programs projects [3] over the
>> Icehouse-Juno timeframe (September 26, 2013 06:00 UTC to September 26,
>> 2014 05:59 UTC), as well as the extra-ATCs who are acknowledged by the
>> TC. [4]
>>
>> Please see the wikipage for additional details about this election.
>> [1]
>>
>> If you have any questions please be sure to either voice them on the
>> mailing list or email Anita or myself [5] or contact Anita or myself
>> on IRC.
>>
>> Thank you, and I look forward to reading your candidate proposals,
>> Tristan
>>
>> [0]
>> https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee
>> [1] https://wiki.openstack.org/wiki/TC_Elections_October_2014
>> [2]
>>
>> https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions
>> [3]
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml?id=sept-2014-elections
>> Note the tag for this repo, sept-2014-elections.
>> [4]
>>
>> http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=sept-2014-elections
>> [5] Anita: anteaya at anteaya dot info
>>  Tristan: tristan dot cacqueray at enovance dot com
>>
>
> Greetings,
>
> I'd like to take this chance to gently ask, but it's obviously not a
> requirement, to all candidates to share what their opinion with regards
> to the new governance discussion is in their candidacy.
>
> As a voter, I'm interested to know how the new candidates see our
> governance model in the next 6 months and what changes, related to the
> "big tent" discussion, they consider most important.
>
> Thanks,
> Flavio
>
>
 Hi Flavio:
 I had purposely not mentioned the organizational changes in the
 templated questions (which are brand new this time, so these are the
 guinea pig candidates).

 One of the things people are looking for is leaders. At campaign time
 folks with strong stances prevail. However it is the ability to listen
 and consider the opinions of others, especially when disagreement
 arises, that makes our TC as strong as it has been and hopefully will be
 in future.

 Everyone is enjoying the drama of the changes and yes they are dramatic,
 but equally if not more important is the work that will have to take
 place using listening and consideration skills in order to turn
 decisions into outcomes.

 Listening is an incredibly important leadership skill but doesn't get
 much air time during campaigns. If you look at really effective leaders
 though they are listeners, every one. Listeners also rarely state that
 is what they are doing, since they are busy listening.

 Any candidate is welcome to say anything they wish in their candidate
 statement. I appreciate that you are interested in their opinions about
 the new governance model, Flavio, and I appreciate you speaking up about
 it. But regardless of what dec

Re: [openstack-dev] sign up for oslo liaisons for kilo cycle


On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka  wrote:

> Signed PGP part
> On 06/10/14 17:56, Doug Hellmann wrote:
> > The Oslo team is responsible for managing code shared between
> > projects. There are a LOT more projects than Oslo team members, so
> > we created the liaison program at the beginning of the Juno cycle,
> > asking each team that uses Oslo libraries to provide one volunteer
> > liaison. Our liaisons facilitate communication and work with us to
> > make the application code changes needed as code moves out of the
> > incubator and into libraries. With this extra help in place, we
> > were able to successfully graduate 7 new libraries and begin having
> > them adopted across OpenStack.
> >
> > With the change-over to the new release cycle, it’s time to ask for
> > volunteers to sign up to be liaisons again. If you are interested
> > in acting as a liaison for your project, please sign up on the wiki
> > page [1]. It would be very helpful to have a full roster before the
> > summit, so we can make sure liaisons are invited to participate in
> > any relevant discussions there.
> >
> > Thanks, Doug
> >
> > [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
> 
> Quoting the page: "The liaison should be a core reviewer for the
> project." Is it a reasonable limitation? I suspect that being an Oslo
> liaison usually does not really require the core status. Any team
> member with visible level of participation in the project and decent
> communication skills should be able to do the job.
> 
> Why I ask: I would probably consider signing up for the liaison
> program from Neutron side if 1) the program rules would not be that
> tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
> against it.

We need someone who can push patches into the project and understands the code 
well enough to be able to do that without delay. Usually that means a core 
reviewer. If the Neutron team commits to working closely with you on patches to 
avoid delays, that would achieve the same ends.

Doug


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

Re: [openstack-dev] sign up for oslo liaisons for kilo cycle

2014-10-07 Thread Flavio Percoco

On 10/07/2014 02:50 PM, Doug Hellmann wrote:
> 
> On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka  wrote:
> 
>> Signed PGP part
>> On 06/10/14 17:56, Doug Hellmann wrote:
>>> The Oslo team is responsible for managing code shared between
>>> projects. There are a LOT more projects than Oslo team members, so
>>> we created the liaison program at the beginning of the Juno cycle,
>>> asking each team that uses Oslo libraries to provide one volunteer
>>> liaison. Our liaisons facilitate communication and work with us to
>>> make the application code changes needed as code moves out of the
>>> incubator and into libraries. With this extra help in place, we
>>> were able to successfully graduate 7 new libraries and begin having
>>> them adopted across OpenStack.
>>>
>>> With the change-over to the new release cycle, it’s time to ask for
>>> volunteers to sign up to be liaisons again. If you are interested
>>> in acting as a liaison for your project, please sign up on the wiki
>>> page [1]. It would be very helpful to have a full roster before the
>>> summit, so we can make sure liaisons are invited to participate in
>>> any relevant discussions there.
>>>
>>> Thanks, Doug
>>>
>>> [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
>>
>> Quoting the page: "The liaison should be a core reviewer for the
>> project." Is it a reasonable limitation? I suspect that being an Oslo
>> liaison usually does not really require the core status. Any team
>> member with visible level of participation in the project and decent
>> communication skills should be able to do the job.
>>
>> Why I ask: I would probably consider signing up for the liaison
>> program from Neutron side if 1) the program rules would not be that
>> tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
>> against it.
> 
> We need someone who can push patches into the project and understands the 
> code well enough to be able to do that without delay. Usually that means a 
> core reviewer. If the Neutron team commits to working closely with you on 
> patches to avoid delays, that would achieve the same ends.
> 

Agreed with Doug. It's not really a strong requirement. The request of
the liaison to be a core reviewer is more a suggestion for the projects
themselves in order to make the interaction between both teams easier.

That said, we could probably re-word that somehow to reflect the above.

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] sign up for oslo liaisons for kilo cycle

On Tue, Oct 7, 2014 at 7:50 AM, Doug Hellmann  wrote:
>
> On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka  wrote:
>
>> Signed PGP part
>> On 06/10/14 17:56, Doug Hellmann wrote:
>> > The Oslo team is responsible for managing code shared between
>> > projects. There are a LOT more projects than Oslo team members, so
>> > we created the liaison program at the beginning of the Juno cycle,
>> > asking each team that uses Oslo libraries to provide one volunteer
>> > liaison. Our liaisons facilitate communication and work with us to
>> > make the application code changes needed as code moves out of the
>> > incubator and into libraries. With this extra help in place, we
>> > were able to successfully graduate 7 new libraries and begin having
>> > them adopted across OpenStack.
>> >
>> > With the change-over to the new release cycle, it’s time to ask for
>> > volunteers to sign up to be liaisons again. If you are interested
>> > in acting as a liaison for your project, please sign up on the wiki
>> > page [1]. It would be very helpful to have a full roster before the
>> > summit, so we can make sure liaisons are invited to participate in
>> > any relevant discussions there.
>> >
>> > Thanks, Doug
>> >
>> > [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
>>
>> Quoting the page: "The liaison should be a core reviewer for the
>> project." Is it a reasonable limitation? I suspect that being an Oslo
>> liaison usually does not really require the core status. Any team
>> member with visible level of participation in the project and decent
>> communication skills should be able to do the job.
>>
>> Why I ask: I would probably consider signing up for the liaison
>> program from Neutron side if 1) the program rules would not be that
>> tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
>> against it.
>
> We need someone who can push patches into the project and understands the 
> code well enough to be able to do that without delay. Usually that means a 
> core reviewer. If the Neutron team commits to working closely with you on 
> patches to avoid delays, that would achieve the same ends.
>
I am 100% onboard with Ihar being the Neutron team's Osli liaison.
Thanks for signing up Ihar, and thanks for working with us here Doug!

Kyle

> Doug
>
>
> ___
> 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] TC candidacy

2014-10-07 Thread Anne Gentle

I'm Anne Gentle (hi, Anne!) and I'm writing to announce my candidacy for
the technical committee.

I've served on the technical committee for two years and have been working
on OpenStack since September 2010. I'm currently the Documentation PTL. I'd
be honored to continue to represent the cross-project needs as well as the
needs of the users, operators, and admins who keep an OpenStack cloud
running every day. I've responded to the questions below so you can get to
know me a little better. You can also see my review comments on the
governance repo
https://review.openstack.org/#/q/reviewer:self+project:openstack/governance,n,z

Please feel free to ask me questions and challenge my assumptions. I
believe good leaders can take on the tough work and we all know there is
plenty of hard work to go around.
Thanks,
Anne

Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack
Mission?
The technical community consists of a huge blend of people now, thank
goodness, because the mission is a grand sweeping one for private and
public clouds. Plus it has the word ubiquitous in it which makes it even
more wide-reaching. We're making clouds for the planet and I feel we're
tackling, blocking, clearing, and fighting hard to meet the Mission. We're
struggling with the "simple to implement" but we have come a very long way.

Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical
committee mission?
I feel the TC is supportive of the technical contributors to all the
projects that make up OpenStack. We're constantly seeking ways to improve
and challenge programs. We began to hold programs accountable for their
integration. We pushed the limits of the definition of OpenStack by
defining all code that a project maintains as part of OpenStack (defined
sections). Yes, it was a defense on the side of our Active Technical
Contributor community base, but it was a statement about our ideals -
Openness, Transparency, Commonality, Integration, Quality.

Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?
Contributors are motivated in different ways, but we're all humans and
behave like humans do. In Peter Kollock's study of online communities, he
found these motivating factors for participating: reciprocity, reputation,
sense of belonging, efficacy, and need. All of these make sense to me when
put in the docs context, "why would anyone contribute to upstream
documentation?" and I can also draw maps and correlations to the overall
reasons why contributors work on upstream. We need to be aware of what
happens when the "need" stems from corporate motivation, but I know that
OpenStack is a great community to work within and that I can do my part to
demonstrate which motivations I want to encourage in our community.

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?
Hopefully by now you've seen me represent the cross-project ramifications
of this growth rate over the years I've served on the TC. The docs program
has had to adjust the expectations and educate incoming programs about how
OpenStack documentation is not just project-by-project but an umbrella
effort. People come to docs.openstack.org for OpenStack docs, not just nova
or glance docs. I hope I have shown bravery in the face of the rate of
growth and also pragmatism.

Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?
As an admin for the GNOME Outreach Program for Women for the last two
years, I have helped with on-boarding new interns who have to have a patch
in order to complete their application. Really, though, the previous
interns do a lion's share of the work in on-boarding newcomers to our
community. I think this is because their eyes are freshest to the
difficulties you'll encounter while figuring out our unique processes. I'm
also amazed at how a wonderful small community has grown up out of helping
others learn, and that's been the best part about seeing new contributors
coming in. We've done a lot to make installing git review easier and
specifically setting up the gerrit remote. So the very first on-boarding
experiences can get better. Now, the experience of those of us a few years
in isn't great either as reviews are harder and harder to get through and
our gate is stuffed full with patches wanting in. I think we can work on
both experiences at the same time to make it better for all contributors.

Topic: Communication
How would you describe our current state of communication in the OpenStack
community?
Communication with such a wide, growing population can be difficult but I
think we have the channels available with opt-in policies that make sense
for our community. The TC listens on many channels, I know I'm subscribed
to all the mailing lists without filters

Re: [openstack-dev] [nova] Resource tracker

2014-10-07 Thread Daniel P. Berrange

On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote:
> On Mon, Oct 6, 2014 at 6:03 AM, Gary Kotton  wrote:
> 
> >  Hi,
> > At the moment the resource tracker in Nova ignores that statistics that
> > are returned by the hypervisor and it calculates the values on its own. Not
> > only is this highly error prone but it is also very costly – all of the
> > resources on the host are read from the database. Not only the fact that we
> > are doing something very costly is troubling, the fact that we are over
> > calculating resources used by the hypervisor is also an issue. In my
> > opinion this leads us to not fully utilize hosts at our disposal. I have a
> > number of concerns with this approach and would like to know why we are not
> > using the actual resource reported by the hypervisor.
> > The reason for asking this is that I have added a patch which uses the
> > actual hypervisor resources returned and it lead to a discussion on the
> > particular review (https://review.openstack.org/126237).
> >
> 
> So it sounds like you have mentioned two concerns here:
> 
> 1. The current method to calculate hypervisor usage is expensive in terms
> of database access.
> 2. Nova ignores that statistics that are returned by the hypervisor and
> uses its own calculations.
> 
> 
> To #1, maybe we can doing something better, optimize the query, cache the
> result etc. As for #2 nova intentionally doesn't use the hypervisor
> statistics for a few reasons:
> 
> * Make scheduling more deterministic, make it easier to reproduce issues
> etc.
> * Things like memory ballooning and thin provisioning in general, mean that
> the hypervisor is not reporting how much of the resources can be allocated
> but rather how much are currently in use (This behavior can vary from
> hypervisor to hypervisor today AFAIK -- which makes things confusing). So
> if I don't want to over subscribe RAM, and the hypervisor is using memory
> ballooning, the hypervisor statistics are mostly useless. I am sure there
> are more complex schemes that we can come up with that allow us to factor
> in the properties of thin provisioning, but is the extra complexity worth
> it?

That is just an example of problems with the way Nova virt drivers
/currently/ report usage to the schedular. It is easily within the
realm of possibility for the virt drivers to be changed so that they
report stats which take into account things like ballooning and thin
provisioning so that we don't oversubscribe. Ignoring the hypervisor
stats entirely and re-doing the calculations in the resource tracker
code is just a crude workaround really. It is just swapping one set
of problems for a new set of problems. 

> That being said I am fine with discussing in a spec the idea of adding an
> option to use the hypervisor reported statistics, as long as it is off by
> default.

I'm against the idea of adding config options to switch between multiple
codepaths because it is just punting the problem to the admins who are
in an even worse position to decide what is best. It is saying would you
rather your cloud have bug A or have bug B. We should be fixing the data
the hypervisors report so that the resource tracker doesn't have to ignore
them, and give the admins something which just works and avoid having to
choose between 2 differently broken options.


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] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-07 Thread joehuang

Hello, Joshua, 

Thank you for your concerns on OpenStack cascading. I am afraid that I am not 
proper person to give comment on cells, but I would like to speak a little 
about cascading for you mentioned "with its own set of consistency warts I'm 
sure" .

1. For small scale or a cloud within one data centers, one OpenStack instance 
(including cells) without cascading feature can work just like it work today. 
OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... 
like other vendor specific agent/driver( for example, vcenter driver, hyper-v 
driver, linux-agent.. ovs-agent ), and does not change the current architecture 
for Nova/Cinder/Neutron..., and does not affect the aleady developed features 
and deployment capability. The cloud operators can skip the existence of 
OpenStack cascading if they don't want to use it, just like they don't want to 
use some kinds of hypervisor / sdn controller   

2. Could you provide concrete inconsistency issues you are worried about in 
OpenStack cascading? Although we did not implement inconsistency check in the 
PoC source code completely, but because logical VM/Volume/Port/Network... 
objects are stored in the cascading OpenStack, and the physical objects are 
stored in the cascaded OpenStack, uuid mapping between logical object and 
physical object had been built,  it's possible and easy to solve the 
inconsistency issues. Even for flavor, host aggregate, we have method to solve 
the inconsistency issue.

Best Regards

Chaoyi Huang ( joehuang )

From: Joshua Harlow [harlo...@outlook.com]
Sent: 07 October 2014 12:21
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
OpenStack cascading

On Oct 3, 2014, at 2:44 PM, Monty Taylor  wrote:

> On 09/30/2014 12:07 PM, Tim Bell wrote:
>>> -Original Message-
>>> From: John Garbutt [mailto:j...@johngarbutt.com]
>>> Sent: 30 September 2014 15:35
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
>>> OpenStack
>>> cascading
>>>
>>> On 30 September 2014 14:04, joehuang  wrote:
 Hello, Dear TC and all,

 Large cloud operators prefer to deploy multiple OpenStack instances(as
>>> different zones), rather than a single monolithic OpenStack instance 
>>> because of
>>> these reasons:

 1) Multiple data centers distributed geographically;
 2) Multi-vendor business policy;
 3) Server nodes scale up modularized from 00's up to million;
 4) Fault and maintenance isolation between zones (only REST
 interface);

 At the same time, they also want to integrate these OpenStack instances 
 into
>>> one cloud. Instead of proprietary orchestration layer, they want to use 
>>> standard
>>> OpenStack framework for Northbound API compatibility with HEAT/Horizon or
>>> other 3rd ecosystem apps.

 We call this pattern as "OpenStack Cascading", with proposal described by
>>> [1][2]. PoC live demo video can be found[3][4].

 Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in the
>>> OpenStack cascading.

 Kindly ask for cross program design summit session to discuss OpenStack
>>> cascading and the contribution to Kilo.

 Kindly invite those who are interested in the OpenStack cascading to work
>>> together and contribute it to OpenStack.

 (I applied for “other projects” track [5], but it would be better to
 have a discussion as a formal cross program session, because many core
 programs are involved )

 [1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
 [2] PoC source code: https://github.com/stackforge/tricircle
 [3] Live demo video at YouTube:
 https://www.youtube.com/watch?v=OSU6PYRz5qY
 [4] Live demo video at Youku (low quality, for those who can't access
 YouTube)：http://v.youku.com/v_show/id_XNzkzNDQ3MDg4.html
 [5]
 http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg36395
 .html
>>>
>>> There are etherpads for suggesting cross project sessions here:
>>> https://wiki.openstack.org/wiki/Summit/Planning
>>> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
>>>
>>> I am interested at comparing this to Nova's cells concept:
>>> http://docs.openstack.org/trunk/config-reference/content/section_compute-
>>> cells.html
>>>
>>> Cells basically scales out a single datacenter region by aggregating 
>>> multiple child
>>> Nova installations with an API cell.
>>>
>>> Each child cell can be tested in isolation, via its own API, before joining 
>>> it up to
>>> an API cell, that adds it into the region. Each cell logically has its own 
>>> database
>>> and message queue, which helps get more independent failure domains. You can
>>> use cell level scheduling to restrict people or types of instances to

[openstack-dev] [neutron] Priorities for Kilo and the Summit

In today's Neutron meeting, we'll spend a portion of the time starting
to go over the Summit ideas we have proposed on our etherpad here [1].
The list is incredibly long, so I expect the process we use to select
our topics for Paris to include a lot of paring down.

I'd also like to emphasize that for Kilo, I expect the focus to be on
paying down technical debt. In particular, the core team will need to
help focus on finally getting some of the refactoring around things
like Pecan, tasks, etc. done. We'll also need to work closely with the
nova team on the neutron/nova integration points, as well as continue
to refine the short, medium and long-term migration story for
nova-network to neutron. In addition, I expect a focus to come in from
the NFV sub-team in OpenStack as well.

We'll discuss in more detail, but I wanted to give the broader
community an idea of where Neutron's focus will be for the next 6
months.

Thanks,
Kyle

[1] https://etherpad.openstack.org/p/kilo-neutron-summit-topics

___
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

2014-10-07 Thread Duncan Thomas

My data consistency concerts would be around:

1) Defining global state. You can of course hand wave away a lot of
your issues by saying they are all local to the sub-unit, but then
what benefit are you providing .v. just providing a list of endpoints
and teaching the clients to talk to multiple endpoints, which is far
easier to make reliable than a new service generally is. State that
'ought' to be global: quota, usage, floating ips, cinder backups, and
probably a bunch more

2) Data locality expectations. You have to be careful about what
expectations .v. realty you're providing here. If the user experience
is substantially different using your proxy .v. direct API, then I
don't think you are providing a useful service - again, just teach the
clients to be multi-cloud aware. This includes what can be connected
to what (cinder volumes, snaps, backups, networks, etc), replication
behaviours and speeds (swift) and probably a bunch more that I haven't
thought of yet.



On 7 October 2014 14:24, joehuang  wrote:
> Hello, Joshua,
>
> Thank you for your concerns on OpenStack cascading. I am afraid that I am not 
> proper person to give comment on cells, but I would like to speak a little 
> about cascading for you mentioned "with its own set of consistency warts I'm 
> sure" .
>
> 1. For small scale or a cloud within one data centers, one OpenStack instance 
> (including cells) without cascading feature can work just like it work today. 
> OpenStack cascading just introduces Nova-proxy, Cinder-proxy, L2/L3 proxy... 
> like other vendor specific agent/driver( for example, vcenter driver, hyper-v 
> driver, linux-agent.. ovs-agent ), and does not change the current 
> architecture for Nova/Cinder/Neutron..., and does not affect the aleady 
> developed features and deployment capability. The cloud operators can skip 
> the existence of OpenStack cascading if they don't want to use it, just like 
> they don't want to use some kinds of hypervisor / sdn controller 
>
> 2. Could you provide concrete inconsistency issues you are worried about in 
> OpenStack cascading? Although we did not implement inconsistency check in the 
> PoC source code completely, but because logical VM/Volume/Port/Network... 
> objects are stored in the cascading OpenStack, and the physical objects are 
> stored in the cascaded OpenStack, uuid mapping between logical object and 
> physical object had been built,  it's possible and easy to solve the 
> inconsistency issues. Even for flavor, host aggregate, we have method to 
> solve the inconsistency issue.
>
> Best Regards
>
> Chaoyi Huang ( joehuang )
> 
> From: Joshua Harlow [harlo...@outlook.com]
> Sent: 07 October 2014 12:21
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
> OpenStack cascading
>
> On Oct 3, 2014, at 2:44 PM, Monty Taylor  wrote:
>
>> On 09/30/2014 12:07 PM, Tim Bell wrote:
 -Original Message-
 From: John Garbutt [mailto:j...@johngarbutt.com]
 Sent: 30 September 2014 15:35
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
 OpenStack
 cascading

 On 30 September 2014 14:04, joehuang  wrote:
> Hello, Dear TC and all,
>
> Large cloud operators prefer to deploy multiple OpenStack instances(as
 different zones), rather than a single monolithic OpenStack instance 
 because of
 these reasons:
>
> 1) Multiple data centers distributed geographically;
> 2) Multi-vendor business policy;
> 3) Server nodes scale up modularized from 00's up to million;
> 4) Fault and maintenance isolation between zones (only REST
> interface);
>
> At the same time, they also want to integrate these OpenStack instances 
> into
 one cloud. Instead of proprietary orchestration layer, they want to use 
 standard
 OpenStack framework for Northbound API compatibility with HEAT/Horizon or
 other 3rd ecosystem apps.
>
> We call this pattern as "OpenStack Cascading", with proposal described by
 [1][2]. PoC live demo video can be found[3][4].
>
> Nova, Cinder, Neutron, Ceilometer and Glance (optional) are involved in 
> the
 OpenStack cascading.
>
> Kindly ask for cross program design summit session to discuss OpenStack
 cascading and the contribution to Kilo.
>
> Kindly invite those who are interested in the OpenStack cascading to work
 together and contribute it to OpenStack.
>
> (I applied for “other projects” track [5], but it would be better to
> have a discussion as a formal cross program session, because many core
> programs are involved )
>
>
> [1] wiki: https://wiki.openstack.org/wiki/OpenStack_cascading_solution
> [2] PoC source code: https://github.com/stackforge/tricircle
> [3]

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 09:19 AM, Anne Gentle wrote:
> I'm Anne Gentle (hi, Anne!) and I'm writing to announce my candidacy for
> the technical committee.
> 
> I've served on the technical committee for two years and have been working
> on OpenStack since September 2010. I'm currently the Documentation PTL. I'd
> be honored to continue to represent the cross-project needs as well as the
> needs of the users, operators, and admins who keep an OpenStack cloud
> running every day. I've responded to the questions below so you can get to
> know me a little better. You can also see my review comments on the
> governance repo
> https://review.openstack.org/#/q/reviewer:self+project:openstack/governance,n,z
> 
> Please feel free to ask me questions and challenge my assumptions. I
> believe good leaders can take on the tough work and we all know there is
> plenty of hard work to go around.
> Thanks,
> Anne
> 
> Topic: OpenStack Mission
> How do you feel the technical community is doing in meeting the OpenStack
> Mission?
> The technical community consists of a huge blend of people now, thank
> goodness, because the mission is a grand sweeping one for private and
> public clouds. Plus it has the word ubiquitous in it which makes it even
> more wide-reaching. We're making clouds for the planet and I feel we're
> tackling, blocking, clearing, and fighting hard to meet the Mission. We're
> struggling with the "simple to implement" but we have come a very long way.
> 
> Topic: Technical Committee Mission
> How do you feel the technical committee is doing in meeting the technical
> committee mission?
> I feel the TC is supportive of the technical contributors to all the
> projects that make up OpenStack. We're constantly seeking ways to improve
> and challenge programs. We began to hold programs accountable for their
> integration. We pushed the limits of the definition of OpenStack by
> defining all code that a project maintains as part of OpenStack (defined
> sections). Yes, it was a defense on the side of our Active Technical
> Contributor community base, but it was a statement about our ideals -
> Openness, Transparency, Commonality, Integration, Quality.
> 
> Topic: Contributor Motivation
> How would you characterize the various facets of contributor motivation?
> Contributors are motivated in different ways, but we're all humans and
> behave like humans do. In Peter Kollock's study of online communities, he
> found these motivating factors for participating: reciprocity, reputation,
> sense of belonging, efficacy, and need. All of these make sense to me when
> put in the docs context, "why would anyone contribute to upstream
> documentation?" and I can also draw maps and correlations to the overall
> reasons why contributors work on upstream. We need to be aware of what
> happens when the "need" stems from corporate motivation, but I know that
> OpenStack is a great community to work within and that I can do my part to
> demonstrate which motivations I want to encourage in our community.
> 
> 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?
> Hopefully by now you've seen me represent the cross-project ramifications
> of this growth rate over the years I've served on the TC. The docs program
> has had to adjust the expectations and educate incoming programs about how
> OpenStack documentation is not just project-by-project but an umbrella
> effort. People come to docs.openstack.org for OpenStack docs, not just nova
> or glance docs. I hope I have shown bravery in the face of the rate of
> growth and also pragmatism.
> 
> Topic: New Contributor Experience
> How would you characterize the experience new contributors have currently?
> As an admin for the GNOME Outreach Program for Women for the last two
> years, I have helped with on-boarding new interns who have to have a patch
> in order to complete their application. Really, though, the previous
> interns do a lion's share of the work in on-boarding newcomers to our
> community. I think this is because their eyes are freshest to the
> difficulties you'll encounter while figuring out our unique processes. I'm
> also amazed at how a wonderful small community has grown up out of helping
> others learn, and that's been the best part about seeing new contributors
> coming in. We've done a lot to make installing git review easier and
> specifically setting up the gerrit remote. So the very first on-boarding
> experiences can get better. Now, the experience of those of us a few years
> in isn't great either as reviews are harder and harder to get through and
> our gate is stuffed full with patches wanting in. I think we can work on
> both experiences at the same time to make it better for all contributors.
> 
> Topic: Communication
> How would you describe our current state of communication in the OpenStack
> community?
> Communication with such a wide, growing

[openstack-dev] [Fuel] Cluster reconfiguration scenarios

2014-10-07 Thread Dmitriy Shulyak

Hi folks,
I want to discuss cluster reconfiguration scenarios, i am aware of 2 such
bugs:

- ceph-mon not installed on controllers if cluster initially was deployed
without ceph-osd
- config with rabbitmq hosts not updated on non-controlles nodes after
additional controllers is added to cluster [1]

In both cases we need to track node state and change it accordingly to some
event
(additonal ceph-osd, additional controller added to cluster, etc..).
I think that it is generic scenario and our api should support such
modifications.

To track state of node we need to introduce new state - something in lines
of "requires_update".
And extend deployment selection logic to include nodes with this state, if
deploy action will be invoked.

What do you think about such feature? I would be grateful for any other
cases.

[1] https://bugs.launchpad.net/fuel/+bug/1368445
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2014-10-07 Thread Evgeniy L

Hi,

We had a meeting today about plugins on UI, as result of the meeting
we have two approaches and this approaches affect not only UX but
plugins itself.

*1st - disable/enable plugin on settings tab*

   1. user installs the plugin
   2. creates a cluster
   3. configures and enables/disables plugins on settings tab

For user it will look like Ceph plugin checkboxes on settings tab,
if he enables checkbox, then we pass the parameter to orchestrator
as `true`.

Cons:

   - plugin developer should define a checkbox in each plugin (for plugin
   disabling/enabling)
   - on the backend we have to enable all of the plugins for environment,
   because user can define any name for his checkbox and we won't be able to
   find it and make appropriate mapping plugin <-> env
   - since all of the plugins are always "enabled" we have to run tasks for
   all of the plugins, and each plugin should parse astute.yaml in order to
   figure out if it's required to run task current script

Pros:

   - it won't require additional setting or step for wizard
   - user will be able to disable plugin after environment creation

*2nd - enable plugins in wizard*

   1. user installs the plugin
   2. now he can choose specific plugins for his environment in wizard
   3. after cluster is created, he can configure additional parameters on
   settings tab, if plugin provides any

Cons:

   - user won't be able to disable plugin after cluster is created
   - additional step or configuration subcategory in wizard

Pros:

On backend we always know which plugin is disabled and which is enabled.



   - it means we don't provide settings for plugins which are disabled
   - we don't run tasks on slaves if it's not required

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

Re: [openstack-dev] sign up for oslo liaisons for kilo cycle

2014-10-07 Thread Ghe Rivero

Last cycle the Ironic liaison wasn't a core reviewer and things worked. 
So I agree with the idea of relaxing the recommendation.


Ghe Rivero (Ironic liaison)

On 07/10/14 14:50, Doug Hellmann wrote:


On Oct 7, 2014, at 7:55 AM, Ihar Hrachyshka  wrote:


Signed PGP part
On 06/10/14 17:56, Doug Hellmann wrote:

The Oslo team is responsible for managing code shared between
projects. There are a LOT more projects than Oslo team members, so
we created the liaison program at the beginning of the Juno cycle,
asking each team that uses Oslo libraries to provide one volunteer
liaison. Our liaisons facilitate communication and work with us to
make the application code changes needed as code moves out of the
incubator and into libraries. With this extra help in place, we
were able to successfully graduate 7 new libraries and begin having
them adopted across OpenStack.

With the change-over to the new release cycle, it’s time to ask for
volunteers to sign up to be liaisons again. If you are interested
in acting as a liaison for your project, please sign up on the wiki
page [1]. It would be very helpful to have a full roster before the
summit, so we can make sure liaisons are invited to participate in
any relevant discussions there.

Thanks, Doug

[1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons


Quoting the page: "The liaison should be a core reviewer for the
project." Is it a reasonable limitation? I suspect that being an Oslo
liaison usually does not really require the core status. Any team
member with visible level of participation in the project and decent
communication skills should be able to do the job.

Why I ask: I would probably consider signing up for the liaison
program from Neutron side if 1) the program rules would not be that
tight; and 2) current Neutron Oslo liaison (Salvatore?) wouldn't be
against it.


We need someone who can push patches into the project and understands the code 
well enough to be able to do that without delay. Usually that means a core 
reviewer. If the Neutron team commits to working closely with you on patches to 
avoid delays, that would achieve the same ends.

Doug


___
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] [Keystone] Question regarding Service Catalog and Identity entries...

2014-10-07 Thread Ben Meyer

I am trying to use the Python Keystone client to integration
authentication functionality into a project I am contributing to
(https://github.com/rackerlabs/deuce-client).
However, I ran into a situation where if I do the following:

>>> c = keystoneclient.v2_0.client.Client(username='username',
password='password',
auth_url="https://keystone-compatible-service.example.com/v2.0/";)
Failed to retrieve management_url from token

I traced it through the Python Keystoneclient code and it fails due to
not finding the "identity" service entry in the Service Catalog. The
authentication otherwise happens in that it has already received a
"successful" response and a full Service Catalog, aside from the
"missing" identity service. This happens with both version 0.10 and 0.11
python keystone clients; I did not try older clients.

Talking with the service provider, their version does not include itself
in the Service Catalog, and they learned the Keystone itself inserts
itself into the Service Catalog.
I can certainly understand why it having the identity service entry be
part of the Service Catalog, but for them it is (at least for now) not
desirable to do so.

Questions:
- Is it now a standard that Keystone inserts itself into the Service
Catalog?
- Or is the Python Keystone Client broken because it is forcing it to be so?

Thanks,

Benjamen R. Meyer

___
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

2014-10-07 Thread Dmitriy Shulyak

Hi, I would use 1st option.
Consider plugins which is mutually exclusive, and you need to disable
default tasks if plugin is selected.

As example:
- neutron backend plugins

neutron_backend:
  choices:
- ovs
- contrail
  value: ovs

Right now we are using ovs as neutron_backend, but what we will need to do
if plugin will provide completely different backend, as contrail?

In 1st case - in tasks we will introduce simple conditions (in description
or in python code of the plugin):
condition: 'ovs == cluster.attributes.neutron_backend' - for default
workflow

condition: 'contrail == cluster.attributes.neutron_backend' - contrail
plugin workflow

And if we need to exclude some task from workflow - simply select another
value from drop down list.
I believe same applies for glance/cinder backends (lvm/ceph, swift/ceph).
Atleast we are managing them this way right now.

Also, we should not forget about CLI.
I can easily imagine how operator downloads cluster config (big cluster
attributes file) and modifies it accordingly to turn on specific plugins.
How we will manage plugins from cli if plugins will be managed from wizard?


On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L  wrote:

> Hi,
>
> We had a meeting today about plugins on UI, as result of the meeting
> we have two approaches and this approaches affect not only UX but
> plugins itself.
>
> *1st - disable/enable plugin on settings tab*
>
>1. user installs the plugin
>2. creates a cluster
>3. configures and enables/disables plugins on settings tab
>
> For user it will look like Ceph plugin checkboxes on settings tab,
> if he enables checkbox, then we pass the parameter to orchestrator
> as `true`.
>
> Cons:
>
>- plugin developer should define a checkbox in each plugin (for plugin
>disabling/enabling)
>- on the backend we have to enable all of the plugins for environment,
>because user can define any name for his checkbox and we won't be able to
>find it and make appropriate mapping plugin <-> env
>- since all of the plugins are always "enabled" we have to run tasks
>for all of the plugins, and each plugin should parse astute.yaml in order
>to figure out if it's required to run task current script
>
> Pros:
>
>- it won't require additional setting or step for wizard
>- user will be able to disable plugin after environment creation
>
> *2nd - enable plugins in wizard*
>
>1. user installs the plugin
>2. now he can choose specific plugins for his environment in wizard
>3. after cluster is created, he can configure additional parameters on
>settings tab, if plugin provides any
>
> Cons:
>
>- user won't be able to disable plugin after cluster is created
>- additional step or configuration subcategory in wizard
>
> Pros:
>
> On backend we always know which plugin is disabled and which is enabled.
>
>
>
>- it means we don't provide settings for plugins which are disabled
>- we don't run tasks on slaves if it's not required
>
> Thanks,
>
> ___
> 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] [Openstack-dev][nova] git fetch fails with permission denied (publickey)

2014-10-07 Thread Jennifer Mulsow


Thank you, Jeremy. That solved it.

Jennifer Mulsow
Cloud Systems Software Development
IBM Systems & Technology Group



From:   Jeremy Stanley 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   10/06/2014 06:05 PM
Subject:Re: [openstack-dev] [Openstack-dev][nova] git fetch fails with
permission denied (publickey)



On 2014-10-06 17:45:21 -0500 (-0500), Jennifer Mulsow wrote:
[...]
> git remote add origin
ssh://jmul...@review.openstack.org:29418/openstack/nova.git
[...]
> I have double checked that my user name is correct on
> review.openstack.org and in my global git config where I am trying
> to do the fetch.
[...]

The logs for the Gerrit API indicate it could not find any user with
"jmulsow" as the username, and digging in its MySQL database I have
confirmed that is the case. I see a "Jennifer Mulsow" who created a
Gerrit account in April of 2013 who last updated contact information
a few weeks ago, but that account has no username configured at all.

When you are signed into Gerrit's WebUI and visit
https://review.openstack.org/#/settings/ is there anything at all
listed to the right of "Username"? If so, that's what you should use
instead of jmulsow. If there's nothing there at all, then click into
the blank space and (carefully since it can't be changed later)
enter whatever you want it to be.
--
Jeremy Stanley
[attachment "signature.asc" deleted by Jennifer Mulsow/Austin/IBM]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

2014-10-07 Thread Jason Dunsmore

+1!

On Mon, Oct 06 2014, Zane Bitter wrote:

> I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team.
>
> Pavlo has been a consistently active member of the Heat community -
> he's a regular participant in IRC and at meetings, has been making
> plenty of good commits[1] and maintains a very respectable review
> rate[2] with helpful comments. I think he's built up enough experience
> with the code base to be ready for core.
>
> Heat-cores, please vote by replying to this thread. As a reminder of
> your options[3], +1 votes from 5 cores is sufficient; a -1 is treated
> as a veto.
>
> cheers,
> Zane.
>
> [1]
> https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z
> [2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
> [3] https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

Re: [openstack-dev] Treating notifications as a contract

2014-10-07 Thread Chris Dent


On Wed, 3 Sep 2014, Sandy Walsh wrote:


Good goals. When Producer and Consumer know what to expect, things are
good ... "I know to find the Instance ID ". When the consumer
wants to deal with a notification as a generic object, things get tricky
("find the instance ID in the payload", "What is the image type?", "Is
this an error notification?")

Basically, how do we define the principle artifacts for each service and
grant the consumer easy/consistent access to them? (like the 7-W's above)

I'd really like to find a way to solve that problem.


Is that a good summary? What did I leave out or get wrong?


Great start! Let's keep it simple and do-able.


Has there been any further thinking on these topics? Summit is soon
and kilo specs are starting so I imagine more people than just me are
hoping to get rolling on plans.

If there is going to be a discussion at summit I hope people will be
good about keeping some artifacts for those of us watching from afar.

It seems to me that if the notifications ecosystem becomes
sufficiently robust and resilient we ought to be able to achieve
some interesting scale and distributed-ness opporunities throughout
OpenStack, not just in telemetry/metering/eventing (choose your term
of art).

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
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

2014-10-07 Thread Evgeniy L

Hi Dmitry,

>> In 1st case - in tasks we will introduce simple conditions (in
description or in python code of the plugin):

You will be able to do it in the same way in case of 2nd solution.
I mean there is no constraints on conditions defining.

>> Also, we should not forget about CLI

In case of cli we can provide special parameter and user will be able to
create env with specific plugins.

Thanks,

On Tue, Oct 7, 2014 at 6:51 PM, Dmitriy Shulyak 
wrote:

> Hi, I would use 1st option.
> Consider plugins which is mutually exclusive, and you need to disable
> default tasks if plugin is selected.
>
> As example:
> - neutron backend plugins
>
> neutron_backend:
>   choices:
> - ovs
> - contrail
>   value: ovs
>
> Right now we are using ovs as neutron_backend, but what we will need to do
> if plugin will provide completely different backend, as contrail?
>
> In 1st case - in tasks we will introduce simple conditions (in description
> or in python code of the plugin):
> condition: 'ovs == cluster.attributes.neutron_backend' - for default
> workflow
>
> condition: 'contrail == cluster.attributes.neutron_backend' - contrail
> plugin workflow
>
> And if we need to exclude some task from workflow - simply select another
> value from drop down list.
> I believe same applies for glance/cinder backends (lvm/ceph, swift/ceph).
> Atleast we are managing them this way right now.
>
> Also, we should not forget about CLI.
> I can easily imagine how operator downloads cluster config (big cluster
> attributes file) and modifies it accordingly to turn on specific plugins.
> How we will manage plugins from cli if plugins will be managed from
> wizard?
>
>
> On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> We had a meeting today about plugins on UI, as result of the meeting
>> we have two approaches and this approaches affect not only UX but
>> plugins itself.
>>
>> *1st - disable/enable plugin on settings tab*
>>
>>1. user installs the plugin
>>2. creates a cluster
>>3. configures and enables/disables plugins on settings tab
>>
>> For user it will look like Ceph plugin checkboxes on settings tab,
>> if he enables checkbox, then we pass the parameter to orchestrator
>> as `true`.
>>
>> Cons:
>>
>>- plugin developer should define a checkbox in each plugin (for
>>plugin disabling/enabling)
>>- on the backend we have to enable all of the plugins for
>>environment, because user can define any name for his checkbox and we 
>> won't
>>be able to find it and make appropriate mapping plugin <-> env
>>- since all of the plugins are always "enabled" we have to run tasks
>>for all of the plugins, and each plugin should parse astute.yaml in order
>>to figure out if it's required to run task current script
>>
>> Pros:
>>
>>- it won't require additional setting or step for wizard
>>- user will be able to disable plugin after environment creation
>>
>> *2nd - enable plugins in wizard*
>>
>>1. user installs the plugin
>>2. now he can choose specific plugins for his environment in wizard
>>3. after cluster is created, he can configure additional parameters
>>on settings tab, if plugin provides any
>>
>> Cons:
>>
>>- user won't be able to disable plugin after cluster is created
>>- additional step or configuration subcategory in wizard
>>
>> Pros:
>>
>> On backend we always know which plugin is disabled and which is enabled.
>>
>>
>>
>>- it means we don't provide settings for plugins which are disabled
>>- we don't run tasks on slaves if it's not required
>>
>> Thanks,
>>
>> ___
>> 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] [Fuel] Cluster reconfiguration scenarios

2014-10-07 Thread Evgeniy L

Hi,

I'm not sure if we should add the new state in this case, it looks like you
can get this
information dynamically, you already have the state of env which tells you
that
there are new ceph nodes, and there are no ready ceph nodes in the cluster
hence you should install ceph-mon on the controllers.

The same for rabbitmq, if there is new controller, run rabbit
reconfiguration on
non-controllers nodes.

Thanks,

On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak 
wrote:

> Hi folks,
> I want to discuss cluster reconfiguration scenarios, i am aware of 2 such
> bugs:
>
> - ceph-mon not installed on controllers if cluster initially was deployed
> without ceph-osd
> - config with rabbitmq hosts not updated on non-controlles nodes after
> additional controllers is added to cluster [1]
>
> In both cases we need to track node state and change it accordingly to
> some event
> (additonal ceph-osd, additional controller added to cluster, etc..).
> I think that it is generic scenario and our api should support such
> modifications.
>
> To track state of node we need to introduce new state - something in lines
> of "requires_update".
> And extend deployment selection logic to include nodes with this state, if
> deploy action will be invoked.
>
> What do you think about such feature? I would be grateful for any other
> cases.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1368445
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Nominating Pavlo Shchelokovskyy for heat-core

2014-10-07 Thread Jeff Peeler


+1

On 10/06/2014 04:41 PM, Zane Bitter wrote:

I'd like to propose that we add Pavlo Shchelokovskyy to the heat-core team.

Pavlo has been a consistently active member of the Heat community - he's
a regular participant in IRC and at meetings, has been making plenty of
good commits[1] and maintains a very respectable review rate[2] with
helpful comments. I think he's built up enough experience with the code
base to be ready for core.

Heat-cores, please vote by replying to this thread. As a reminder of
your options[3], +1 votes from 5 cores is sufficient; a -1 is treated as
a veto.


Obviously past 5 +1 votes here, but showing full support doesn't hurt.



cheers,
Zane.

[1]
https://review.openstack.org/#/q/owner:%22Pavlo+Shchelokovskyy%22+status:merged+project:openstack/heat,n,z

[2] http://russellbryant.net/openstack-stats/heat-reviewers-30.txt
[3]
https://wiki.openstack.org/wiki/Heat/CoreTeam#Adding_or_Removing_Members



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

[openstack-dev] TC candidacy

2014-10-07 Thread Monty Taylor

Hi everybody!

I'd like to announce my candidacy for re-election to the TC.

tl;dr - Vote for me or vote for someone else you prefer

I've been around the project for quite a while, having been on the phone
calls where we were discussing the name OpenStack - although I'll admit
I had absolutely zero decision making power there. The first decision in
the project I took any active part in shaping was the decision to keep
the code names nova and swift and not to rename each project
openstack-compute and openstack-object-storage.

My main technical focus within OpenStack is in Infra, where I am a
former PTL and current core. I tend to focus energy on cross-project
concerns over individual project concerns. I believe that a strong
OpenStack comes from a high degree of coordination and standardization -
but I think it's important to keep standardization in perspective as a
tool to help us make a better product and not an goal in and of itself.

As an Infra team member, I am a fairly large end-user of OpenStack.
Infra runs across two public clouds and a private cloud run by the
TripleO team. Although I sometimes express it in a non-productive and
rage-filled way, I regularly experience first hand what our end users
experience ... which is both awesome and not-awesome ... and I've been
spending more and more of my effort on improving that experience.

As may be clear from my big-tent blog post, I believe it's highly
important to be inclusive in "who" we are, while at the same time
collectively taking a higher amount of accountability for the quality of
"what" we produce.

Finally, there is a natural tug between exciting new features to make
people's lives better and the quality of the existing features we have.
We've been growing at a rather unprecedented pace over the last four
years, so at the moment I think we need a double-down on quality and
stability with less of a focus on adding features. As with everything
else though, this is a balancing act and the relative importance changes
continually.

Balancing the competing needs such as the ones above is what I believe
the main job of the TC is. We have process, we have policy, we have
governance structure - but ultimately humans need to talk and make
decisions, even if the decision is to do nothing. I think as the TC we
need to own that responsibility and not shrink from it when it's hard or
potentially unpopular.

== The questions ==

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

In case you haven't read it recently:

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

If there is anyone out there who feels we've nailed "simple to
implement" I'd love to meet them. I think we've been focusing on all of
the other parts - I'd like to see more attention placed on "simple to
implement"

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

In case you haven't read it recently:

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

I think over the last year since we became all-elected, the TC has been
doing a better and better job. Historically the TC has been a bit
reluctant to own the words "technical leadership" Over the past cycle or
two, the TC has consistently been stepping more up to the plate on this
topic, and I think that trend needs to continue.

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

I'm pretty sure the majority of our contributors are doing so as part of
their jobs. I think this makes our dynamic a bit different than a
"traditional" Open Source project.

That said - I think we see a very strong set of people who are
passionate about what we're doing evidenced by the number of people who
have worked for multiple companies while working on OpenStack.

I can't speak to everyone's motivation - but I can tell you what mine is.

Cloud is taking over as the way we think about how IT works. It's not an
if, it's a when. But even with that, Cloud is an idea more than a
destination. When we started, there was one legitimate definition for
"Cloud" and it was Amazon. Amazon is a closed-source company run by a
ruthless dictator. I do not want to live in a world where I need his
permission to use a computer.

Over the last four years, we've made significant inroads in redefining
what Cloud can be. Containers and bare-metal are now legitimate building
blocks and I think it's becommin

Re: [openstack-dev] [qa] In-tree functional test vision

2014-10-07 Thread Chris Dent


On Mon, 25 Aug 2014, Joe Gordon wrote:

On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent  wrote:

For constraints: Will tempest be available as a stable library? Is using
tempest (or other same library across all projects) a good or bad thing?
Seems there's some disagreement on both of these.


Yes, there is a separate thread on spinning out a tempest-lib (not sure on
what final name will be yet) that functional tests can use. Although I
think there is a lot  to be done before  needing the tempest-lib.


What's the status of tempest-lib? Looking at the repo it appears
that other things may be taking priority at the moment.

As I said in notifications thread: With summit approaching and kilo
open for business, now seems to be talking about what kinds of
structure we want to apply to in-tree functional testing.

--
Chris Dent tw:@anticdent freenode:cdent
https://tank.peermore.com/tanks/cdent

___
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

2014-10-07 Thread Monty Taylor

On 10/07/2014 06:41 AM, Duncan Thomas wrote:
> My data consistency concerts would be around:
> 
> 1) Defining global state. You can of course hand wave away a lot of
> your issues by saying they are all local to the sub-unit, but then
> what benefit are you providing .v. just providing a list of endpoints
> and teaching the clients to talk to multiple endpoints, which is far
> easier to make reliable than a new service generally is. State that
> 'ought' to be global: quota, usage, floating ips, cinder backups, and
> probably a bunch more

BTW - since infra regularly talks to multiple clouds, I've been working
on splitting supporting code for that into a couple of libraries. Next
pass is to go add support for it to the clients, and it's not really a
lot of work ... so let's assume that the vs. here is going to be
accomplished soonish for the purposes of assessing the above question.

Second BTW - you're certainly right about the first two in the global
list - we keep track of quota and usage ourselves inside of nodepool.
Actually - since nodepool already does a bunch of these things - maybe
we should just slap a REST api on it...

> 2) Data locality expectations. You have to be careful about what
> expectations .v. realty you're providing here. If the user experience
> is substantially different using your proxy .v. direct API, then I
> don't think you are providing a useful service - again, just teach the
> clients to be multi-cloud aware. This includes what can be connected
> to what (cinder volumes, snaps, backups, networks, etc), replication
> behaviours and speeds (swift) and probably a bunch more that I haven't
> thought of yet.
> 
> 
> 
> On 7 October 2014 14:24, joehuang  wrote:
>> Hello, Joshua,
>>
>> Thank you for your concerns on OpenStack cascading. I am afraid that I am 
>> not proper person to give comment on cells, but I would like to speak a 
>> little about cascading for you mentioned "with its own set of consistency 
>> warts I'm sure" .
>>
>> 1. For small scale or a cloud within one data centers, one OpenStack 
>> instance (including cells) without cascading feature can work just like it 
>> work today. OpenStack cascading just introduces Nova-proxy, Cinder-proxy, 
>> L2/L3 proxy... like other vendor specific agent/driver( for example, vcenter 
>> driver, hyper-v driver, linux-agent.. ovs-agent ), and does not change the 
>> current architecture for Nova/Cinder/Neutron..., and does not affect the 
>> aleady developed features and deployment capability. The cloud operators can 
>> skip the existence of OpenStack cascading if they don't want to use it, just 
>> like they don't want to use some kinds of hypervisor / sdn controller 
>>
>> 2. Could you provide concrete inconsistency issues you are worried about in 
>> OpenStack cascading? Although we did not implement inconsistency check in 
>> the PoC source code completely, but because logical 
>> VM/Volume/Port/Network... objects are stored in the cascading OpenStack, and 
>> the physical objects are stored in the cascaded OpenStack, uuid mapping 
>> between logical object and physical object had been built,  it's possible 
>> and easy to solve the inconsistency issues. Even for flavor, host aggregate, 
>> we have method to solve the inconsistency issue.
>>
>> Best Regards
>>
>> Chaoyi Huang ( joehuang )
>> 
>> From: Joshua Harlow [harlo...@outlook.com]
>> Sent: 07 October 2014 12:21
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
>> OpenStack cascading
>>
>> On Oct 3, 2014, at 2:44 PM, Monty Taylor  wrote:
>>
>>> On 09/30/2014 12:07 PM, Tim Bell wrote:
> -Original Message-
> From: John Garbutt [mailto:j...@johngarbutt.com]
> Sent: 30 September 2014 15:35
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] [tc] Multi-clouds integration by 
> OpenStack
> cascading
>
> On 30 September 2014 14:04, joehuang  wrote:
>> Hello, Dear TC and all,
>>
>> Large cloud operators prefer to deploy multiple OpenStack instances(as
> different zones), rather than a single monolithic OpenStack instance 
> because of
> these reasons:
>>
>> 1) Multiple data centers distributed geographically;
>> 2) Multi-vendor business policy;
>> 3) Server nodes scale up modularized from 00's up to million;
>> 4) Fault and maintenance isolation between zones (only REST
>> interface);
>>
>> At the same time, they also want to integrate these OpenStack instances 
>> into
> one cloud. Instead of proprietary orchestration layer, they want to use 
> standard
> OpenStack framework for Northbound API compatibility with HEAT/Horizon or
> other 3rd ecosystem apps.
>>
>> We call this pattern as "OpenStack Cascading", with proposal described by
> [1][2]. PoC live demo vi

Re: [openstack-dev] [Fuel] Cluster reconfiguration scenarios

2014-10-07 Thread Dmitriy Shulyak

We are definitely able to parse all this information at the time of
deployment and generate deployment info
accordingly, but my idea was that additional status will provide more
visibility for operator.
It just wont be obivious - you added controllers/ceph-osd and suddenly your
computes/controllers are in deployment mode.

On Tue, Oct 7, 2014 at 6:17 PM, Evgeniy L  wrote:

> Hi,
>
> I'm not sure if we should add the new state in this case, it looks like
> you can get this
> information dynamically, you already have the state of env which tells you
> that
> there are new ceph nodes, and there are no ready ceph nodes in the cluster
> hence you should install ceph-mon on the controllers.
>
> The same for rabbitmq, if there is new controller, run rabbit
> reconfiguration on
> non-controllers nodes.
>
> Thanks,
>
> On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak 
> wrote:
>
>> Hi folks,
>> I want to discuss cluster reconfiguration scenarios, i am aware of 2 such
>> bugs:
>>
>> - ceph-mon not installed on controllers if cluster initially was deployed
>> without ceph-osd
>> - config with rabbitmq hosts not updated on non-controlles nodes after
>> additional controllers is added to cluster [1]
>>
>> In both cases we need to track node state and change it accordingly to
>> some event
>> (additonal ceph-osd, additional controller added to cluster, etc..).
>> I think that it is generic scenario and our api should support such
>> modifications.
>>
>> To track state of node we need to introduce new state - something in
>> lines of "requires_update".
>> And extend deployment selection logic to include nodes with this state,
>> if deploy action will be invoked.
>>
>> What do you think about such feature? I would be grateful for any other
>> cases.
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1368445
>>
>>
>> ___
>> 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] TC candidacy

confirmed

On 07/10/14 11:25 AM, Monty Taylor wrote:
> Hi everybody!
> 
> I'd like to announce my candidacy for re-election to the TC.
> 
> tl;dr - Vote for me or vote for someone else you prefer
> 
> I've been around the project for quite a while, having been on the phone
> calls where we were discussing the name OpenStack - although I'll admit
> I had absolutely zero decision making power there. The first decision in
> the project I took any active part in shaping was the decision to keep
> the code names nova and swift and not to rename each project
> openstack-compute and openstack-object-storage.
> 
> My main technical focus within OpenStack is in Infra, where I am a
> former PTL and current core. I tend to focus energy on cross-project
> concerns over individual project concerns. I believe that a strong
> OpenStack comes from a high degree of coordination and standardization -
> but I think it's important to keep standardization in perspective as a
> tool to help us make a better product and not an goal in and of itself.
> 
> As an Infra team member, I am a fairly large end-user of OpenStack.
> Infra runs across two public clouds and a private cloud run by the
> TripleO team. Although I sometimes express it in a non-productive and
> rage-filled way, I regularly experience first hand what our end users
> experience ... which is both awesome and not-awesome ... and I've been
> spending more and more of my effort on improving that experience.
> 
> As may be clear from my big-tent blog post, I believe it's highly
> important to be inclusive in "who" we are, while at the same time
> collectively taking a higher amount of accountability for the quality of
> "what" we produce.
> 
> Finally, there is a natural tug between exciting new features to make
> people's lives better and the quality of the existing features we have.
> We've been growing at a rather unprecedented pace over the last four
> years, so at the moment I think we need a double-down on quality and
> stability with less of a focus on adding features. As with everything
> else though, this is a balancing act and the relative importance changes
> continually.
> 
> Balancing the competing needs such as the ones above is what I believe
> the main job of the TC is. We have process, we have policy, we have
> governance structure - but ultimately humans need to talk and make
> decisions, even if the decision is to do nothing. I think as the TC we
> need to own that responsibility and not shrink from it when it's hard or
> potentially unpopular.
> 
> == The questions ==
> 
> Topic: OpenStack Mission
> How do you feel the technical community is doing in meeting the
> OpenStack Mission?
> 
> In case you haven't read it recently:
> 
> "to produce the ubiquitous Open Source Cloud Computing platform that
> will meet the needs of public and private clouds regardless of size, by
> being simple to implement and massively scalable."
> 
> If there is anyone out there who feels we've nailed "simple to
> implement" I'd love to meet them. I think we've been focusing on all of
> the other parts - I'd like to see more attention placed on "simple to
> implement"
> 
> Topic: Technical Committee Mission
> How do you feel the technical committee is doing in meeting the
> technical committee mission?
> 
> In case you haven't read it recently:
> 
> "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."
> 
> I think over the last year since we became all-elected, the TC has been
> doing a better and better job. Historically the TC has been a bit
> reluctant to own the words "technical leadership" Over the past cycle or
> two, the TC has consistently been stepping more up to the plate on this
> topic, and I think that trend needs to continue.
> 
> Topic: Contributor Motivation
> How would you characterize the various facets of contributor motivation?
> 
> I'm pretty sure the majority of our contributors are doing so as part of
> their jobs. I think this makes our dynamic a bit different than a
> "traditional" Open Source project.
> 
> That said - I think we see a very strong set of people who are
> passionate about what we're doing evidenced by the number of people who
> have worked for multiple companies while working on OpenStack.
> 
> I can't speak to everyone's motivation - but I can tell you what mine is.
> 
> Cloud is taking over as the way we think about how IT works. It's not an
> if, it's a when. But even with that, Cloud is an idea more than a
> destination. When we started, there was one legitimate definition for
> "Cloud" and it was Amazon. Amazon is a closed-source company run by a
> ruthless dictator. I

[openstack-dev] Horizon and Keystone: API Versions and Discovery

2014-10-07 Thread Adam Young

Horizon has a config options which says which version of the Keystone 
API it should work against:  V2 or V3.  I am not certain that there is 
still any reason for Horizon to go against V2. However, If we defer the 
decision to Keystone, we come up against the problem of discovery.


On the surface it is easy, as the Keystone client supports  version 
discovery.  The problem is that discovery must be run for each new 
client creation, and Horizon uses a new client per request.  That would 
mean that every request to Horizon that talks to Keystone would generate 
at least one additional request.  Is this significant?


It gets a little worse when you start thinking about all of the other 
services out there.  If each new request that has to talk to multiple 
services needs to run discovery, you can image that soon the majority of 
network chatter would be discovery based.



It seems to me that Horizon should somehow cache this data, and share it 
among clients.  Note that I am not talking about user specific data like 
the endpoints from the service catalog for a specific project.  But the 
overall service catalog, as well as the supported versions of the API, 
should be cacheable.  We can use the standard HTTP cache management API 
on the Keystone side to specify how long Horizon can trust the data to 
be current.


I think this actually goes for the rest of the endpoints as well: we 
want to get to  a much smaller service catalog, and we can do that by 
making the catalog holds on IDs.  The constraints spec for endpoint 
binding will be endpoint only anyway, and so having the rest of the 
endpoint data cached will be valuable there as well.



___
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

2014-10-07 Thread Duncan Thomas

On 7 October 2014 16:30, Monty Taylor  wrote:

> Second BTW - you're certainly right about the first two in the global
> list - we keep track of quota and usage ourselves inside of nodepool.
> Actually - since nodepool already does a bunch of these things - maybe
> we should just slap a REST api on it...

Whether or not it does much for this use-case, Nodepool-aaS would
definitely be useful I think, particularly if it was properly
multi-tenant. It isn't /hard/ to set up, but it's effort and yet
another cog to understand and debug.

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

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

2014-10-07 Thread Mike Bayer

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.

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

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

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

2014-10-07 Thread Henry Gessau

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] TC candidacy

2014-10-07 Thread Zane Bitter


Greetings OpenStackers,
I would like to announce my candidacy for the OpenStack Technical Committee.

I have worked closely with the TC since around the time that Heat was 
incubated, two years ago. I have been a regular participant in TC 
meetings throughout the Juno cycle as the Heat PTL, so I am familiar 
with the current structures and procedures, their back-story, and the 
issues that are before the committee.


I think I can best contribute by digging deep into issues, rooting out 
the points of contention or misunderstanding and building consensus from 
there. If you follow openstack-dev closely you'll probably have seen me 
doing that quite a bit already. I don't claim to have all the answers, 
but I'm pretty good at asking questions.


The OpenStack project has been incredibly successful in building a 
strong community where people want to collaborate on solving problems 
for our common users.[1] We are at a point where we need to readjust the 
structure of the project to better respond to the next phase of that 
success. This is not the first time we have reached such a point; nor 
will it be the last. There is no final form of the OpenStack project; we 
must approach it as we would any engineering problem (_not_, I hasten to 
add, a technical problem): by considering our goals and opportunities, 
making incremental changes, evaluating their effects (both intended and 
unintended), and repeating.


I believe we need to work to reduce entropy in the OpenStack system - 
encouraging shared components and implementations over repeatedly 
reinventing the wheel - without crushing innovation. Those two goals are 
in tension (note that the wheel has been repeatedly reinvented 
throughout history, often to great effect), but they are the ones I will 
be trying to balance. And we must, of course, do this while giving 
operators and end-users confidence in their investments in the OpenStack 
ecosystem.


I think making it easier for projects to join the OpenStack community 
would be a good thing, provided that still entails a commitment to doing 
things the OpenStack way backed up by meaningful oversight by the TC. 
I'm comfortable for now with leaving a high bar for graduation in place, 
though it needs to move around less. While I am in favour of more 
projects in principle, I'll be scrutinising specific projects carefully 
to make sure that they've either been able to apply the feedback part of 
the engineering process I described above with real users, or 
alternatively have solved the simplest possible version of their design 
problem with a view to maximising their flexibility to respond when they 
do get that feedback.[2]


What we're really missing are stepping stones from the lower incubation 
bar to the high graduation bar. We need to do more to help projects 
understand how they can fit in to the bigger picture and what they need 
to do to get there.


That will require greater involvement from the TC, but it appears we 
have already reached the point where the TC itself does not scale. That 
was evident from the Zaqar's second graduation review. One year after 
its incubation, the TC was still debating whether an SQS-like cloud 
messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint: 
none of them[4]), and in the end deferred for another six months to 
figure it out. It's clear that TC members don't have the time to dig 
deeply into all the issues that cross their desks. I already proposed a 
structure whereby subcommittees in each general subject area, comprising 
a representative from each of the relevant projects plus one TC member, 
would do the investigation and mentoring of new projects and report the 
results to the TC.[5] In this model the TC would be responsible for 
setting an overall vision for the project and ensuring that it is 
applied consistently. I would welcome other proposals that could help to 
expand and deepen support for new projects in a way that can scale 
through our next stage of growth. (I am also a strong supporter of 
having formal liaison programs to boost the impact of horizontal, 
cross-project functions without stretching them to breaking point.[1])


As we're figuring out structural changes I think we need to be careful 
to decouple short-term technical issues, like how to scale the gate to a 
larger number of projects that don't all have mutual dependencies, from 
longer-term structural issues. We also need to be very aware of how 
changes we make might be perceived by external parties not sharing the 
same context, including the Foundation Board and especially the DefCore 
subcommittee. Finally, we need to remember that our users see the cloud 
from many different perspectives and that no single perspective can 
capture what is important to our community.[5]


Answers to the TC Election questions are below. I'm happy to answer any 
other questions folks have too, in an open forum of course.


cheers,
Zane.

[1] 
http://lists.openstack.org/piper

Re: [openstack-dev] Horizon and Keystone: API Versions and Discovery

2014-10-07 Thread Dolph Mathews

On Tuesday, October 7, 2014, Adam Young  wrote:

> Horizon has a config options which says which version of the Keystone API
> it should work against:  V2 or V3.  I am not certain that there is still
> any reason for Horizon to go against V2. However, If we defer the decision
> to Keystone, we come up against the problem of discovery.
>
> On the surface it is easy, as the Keystone client supports  version
> discovery.  The problem is that discovery must be run for each new client
> creation, and Horizon uses a new client per request.  That would mean that
> every request to Horizon that talks to Keystone would generate at least one
> additional request.


The response is cacheable.


> Is this significant?
>
> It gets a little worse when you start thinking about all of the other
> services out there.  If each new request that has to talk to multiple
> services needs to run discovery, you can image that soon the majority of
> network chatter would be discovery based.
>
>
> It seems to me that Horizon should somehow cache this data, and share it
> among clients.  Note that I am not talking about user specific data like
> the endpoints from the service catalog for a specific project.  But the
> overall service catalog, as well as the supported versions of the API,
> should be cacheable.  We can use the standard HTTP cache management API on
> the Keystone side to specify how long Horizon can trust the data to be
> current.
>
> I think this actually goes for the rest of the endpoints as well: we want
> to get to  a much smaller service catalog, and we can do that by making the
> catalog holds on IDs.  The constraints spec for endpoint binding will be
> endpoint only anyway, and so having the rest of the endpoint data cached
> will be valuable there as well.
>
>
> ___
> 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] [I18N] compiling translation message catalogs

2014-10-07 Thread Julie Pichon

I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE
packaging: the Horizon team would love to have your opinion on this (it
came up during our weekly meeting).

The current consensus is leaning toward removing the mo files for Juno
RC2 (in a couple of days) rather than wait until Kilo, as this has been
a pain point for (some/all?) distros for a while.

Thank you,

Julie

On 01/10/14 17:04, Akihiro Motoki wrote:
> Hi,
> 
> To display localized strings, we need to compile translated message
> catalogs (PO files) into compiled one (MO files).
> I would like to discuss and get a consensus who and when generate
> compiled message catalogs.
> Inputs from packagers are really appreciated.
> 
> [The current status]
> * Horizon contains compile message catalogs in the git repo. (It is
> just a history and there seems no strong reason to have compiled one
> in the repo. There is a bug report on it.)
> * Other all projects do not contain compiled message catalogs and have
> only PO files.
> 
> [Possible choices]
> I think there are several options. (there may be other options)
> (a) OpenStack does not distribute compiled message catalogs, and only
> provides a command (setup.py integration) to compile message catalogs.
> Deployers or distributors need to compile message catalogs.
> (b) Similar to (a), but compile message catalogs as a part of "pip install".
> (c) OpenStack distributes compiled message catalogs as a part of the release.
> (c1) the git repo maintains compiled message catalogs.
> (c2) only tarball contains compiled message catalogs
> 
> Note that the current Horizon is (c1) and others are (a).
> 
> [Pros/Cons]
> (a) It is a simplest way as OpenStack upstream.
>  Packagers need to compile message catalogs and customize there scripts.
>  Deployers who install openstack from the source need to compile them too.
> (b) It might be a simple approach from users perspective. However to compile
>  message catalogs during installation, we need to install required modules
>  (like babel or django) before running installation (or require
> them as the first
>   citizen in setup.py "require"). I don't think it is much simpler
> compared to
>   option (a).
> (c1) Compiled message catalogs are a kind of binary files and they can
>   be generated from PO files. There is no need to manage two same data.
> (c2) OpenStack is downloaded in several ways (release tarballs is not the
>   only option), so I don't see much merits that the only tarball contains
>   compiled message catalogs. A merit is that compiled message catalogs
>   are available and there is no additional step users need to do.
> 
> My preference is (a), but would like to know broader opinions
> especially from packagers.
> 
> Thanks,
> Akihiro
> 
> ___
> 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

confirmed

On 07/10/14 12:47 PM, Zane Bitter wrote:
> Greetings OpenStackers,
> I would like to announce my candidacy for the OpenStack Technical
> Committee.
> 
> I have worked closely with the TC since around the time that Heat was
> incubated, two years ago. I have been a regular participant in TC
> meetings throughout the Juno cycle as the Heat PTL, so I am familiar
> with the current structures and procedures, their back-story, and the
> issues that are before the committee.
> 
> I think I can best contribute by digging deep into issues, rooting out
> the points of contention or misunderstanding and building consensus from
> there. If you follow openstack-dev closely you'll probably have seen me
> doing that quite a bit already. I don't claim to have all the answers,
> but I'm pretty good at asking questions.
> 
> The OpenStack project has been incredibly successful in building a
> strong community where people want to collaborate on solving problems
> for our common users.[1] We are at a point where we need to readjust the
> structure of the project to better respond to the next phase of that
> success. This is not the first time we have reached such a point; nor
> will it be the last. There is no final form of the OpenStack project; we
> must approach it as we would any engineering problem (_not_, I hasten to
> add, a technical problem): by considering our goals and opportunities,
> making incremental changes, evaluating their effects (both intended and
> unintended), and repeating.
> 
> I believe we need to work to reduce entropy in the OpenStack system -
> encouraging shared components and implementations over repeatedly
> reinventing the wheel - without crushing innovation. Those two goals are
> in tension (note that the wheel has been repeatedly reinvented
> throughout history, often to great effect), but they are the ones I will
> be trying to balance. And we must, of course, do this while giving
> operators and end-users confidence in their investments in the OpenStack
> ecosystem.
> 
> I think making it easier for projects to join the OpenStack community
> would be a good thing, provided that still entails a commitment to doing
> things the OpenStack way backed up by meaningful oversight by the TC.
> I'm comfortable for now with leaving a high bar for graduation in place,
> though it needs to move around less. While I am in favour of more
> projects in principle, I'll be scrutinising specific projects carefully
> to make sure that they've either been able to apply the feedback part of
> the engineering process I described above with real users, or
> alternatively have solved the simplest possible version of their design
> problem with a view to maximising their flexibility to respond when they
> do get that feedback.[2]
> 
> What we're really missing are stepping stones from the lower incubation
> bar to the high graduation bar. We need to do more to help projects
> understand how they can fit in to the bigger picture and what they need
> to do to get there.
> 
> That will require greater involvement from the TC, but it appears we
> have already reached the point where the TC itself does not scale. That
> was evident from the Zaqar's second graduation review. One year after
> its incubation, the TC was still debating whether an SQS-like cloud
> messaging service was most comparable to AMQP, XMPP or SMTP[3] (hint:
> none of them[4]), and in the end deferred for another six months to
> figure it out. It's clear that TC members don't have the time to dig
> deeply into all the issues that cross their desks. I already proposed a
> structure whereby subcommittees in each general subject area, comprising
> a representative from each of the relevant projects plus one TC member,
> would do the investigation and mentoring of new projects and report the
> results to the TC.[5] In this model the TC would be responsible for
> setting an overall vision for the project and ensuring that it is
> applied consistently. I would welcome other proposals that could help to
> expand and deepen support for new projects in a way that can scale
> through our next stage of growth. (I am also a strong supporter of
> having formal liaison programs to boost the impact of horizontal,
> cross-project functions without stretching them to breaking point.[1])
> 
> As we're figuring out structural changes I think we need to be careful
> to decouple short-term technical issues, like how to scale the gate to a
> larger number of projects that don't all have mutual dependencies, from
> longer-term structural issues. We also need to be very aware of how
> changes we make might be perceived by external parties not sharing the
> same context, including the Foundation Board and especially the DefCore
> subcommittee. Finally, we need to remember that our users see the cloud
> from many different perspectives and that no single perspective can
> capture what is important to our community.[5]
> 
> Answers to the TC Election questions are

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Adam Young

On 10/06/2014 05:28 PM, Anita Kuno wrote:

On 10/06/2014 04:11 PM, Adam Young wrote:

On 10/06/2014 03:25 PM, Patricia Ellis wrote:

Hi Adam,

Thanks for taking the time to reply.

I'm more of a web development type than security. I have some maths
background so perhaps something with data analysis.

To date I have done mostly Java, some JavaScript, Html, and MySQL. I
am interested in learning Python. I co-developed a web app to check
and commit time-sheets to a database during my work experience this
summer; I did the database and the checking of the sheets. I, have
also, created an Android app to monitor the fuel consumption in
multiple vehicles, using the Android SQLite Database for storage.

I am looking to get someone to work on a Javascript based web client to
replace Horizon.

Can I just say that I think using new people looking to have work
experience with OpenStack to further pet projects, without telling them
it is a pet project and not considered a project which others may
consider OpenStack to be not the best approach for encouraging new people.

Good points:

Not knocking your project, Adam, since I know nothing about it, and this
isn't the first time I have seen this happen. But I do believe that
folks asking to help out with something are looking to gain transferable
skills so that they have something to offer a potential employeer who is
looking for work experience with OpenStack. That would be what I would
be looking for anyway.
No offense taken. I think you are looking out for the interest of the
poster and people wityh similar interests.

I can verify how hard to cut off a chunk for a new developer: I had an
intern I was working with this summer. Most of the time was spent on
learning the development process. It would not be appropriate for
someone in Patricia's position to try and come in and get a bug fix
through. That limits the number of projects available.

Typically, and internship or a senior project like this is the correct
place for a proof of concept or side project. The project can be done
with a focus more on functionality and less on stability.

We should come up with a published list of "intern and senior projects
proposals"

New people have no idea what are considered transferable skills within
OpenStack unless we tell them.

Thanks,
Anita.

There has been some work along these lines already.

Beyond that, most of the projects I have are Python based Keystone
features. You can see the kinds of things I am considering here:

https://review.openstack.org/#/q/status:open+project:openstack/keystone-specs+owner:%22ayoung+%253Cayoung%2540redhat.com%253E%22,n,z

On 6 October 2014 18:37, Adam Young mailto:ayo...@redhat.com>> wrote:

On 10/06/2014 01:14 PM, Patricia Ellis wrote:

My name is Patricia Ellis, I am a fourth year software
development student at Cork Institute of Technology. I am looking
for ideas for my final year project. I have six weeks to get my
proposal together and then 13 weeks to implement it. I am hoping
you might have a suitable project on your wish list, one which is
of the ”low hanging fruit” variety as my time frame is tight.

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

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

Patricia,

I am Keystone core developer. I have several ideas. It really
depends on your skills and interests.

Are you a security person?

If not, are you a web development type person?

___
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] a need to assert user ownership in preserved state

2014-10-07 Thread Clint Byrum

Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:
> Hi
> 
> > On 6 Oct 2014, at 17:41, Clint Byrum  wrote:
> > We have to be _extremely_ careful in how we manage this. I actually think
> > it has potential to really blow up in our faces.
> 
> Yes, anything we do here has the potential to be extremely ruinous for 
> operators, but the reality is that any existing TripleO deployment is at 
> pretty severe risk of blowing up because of UIDs/GIDs changing when they 
> update.
> 
> > We need to give people
> > a way to move forward without us merging a patch, and at the same time
> > we need to make sure we provide a consistent set of UIDs for anything
> > people may want to deploy with diskimage-builder.
> 
> IMO the only desirable option *has* to be that we statically define UIDs and 
> GIDs in the elements, because:
>  1: Requires no data fragments to be kept safe and fed to subsequent build 
> processes
>  2: Doesn't do anything dynamic on first boot that could take hours/days
>  3: Can be thoroughly audited at build time to ensure correctness
> 
> As you rightly point out though, any existing deployments will definitely be 
> disrupted by this, but as I said above, all we'd be doing there is moving the 
> needle from "possible/probable" to "definite".
> 
> Since the only leftovers we have from their previous image builds, are the 
> images themselves, we could add the ability for a DIB run to extract IDs from 
> a previous image, but this couldn't be required as a default build option, so 
> we'd still risk existing deployments if they don't notice this feature.
> 
> We could create a script that would spider an existing cloud and extract its 
> ID mappings, to produce a fragment to feed into future builds, but again 
> we're relying on operators to know that they need to do this.
> 

Wel... they'd know they need to do _something_ because their UIDs
and GIDs are all horked up (technical term).

> Instead, I agree with Greg's view that this is our fault and we should fix 
> it. We didn't think of this sooner, and as a result, our users are at risk. 
> If we don't entirely fix this ourselves, we will be both expecting them to 
> become aware of this issue and expecting them to do additional work to 
> mitigate it.
> 
> To that end, I think we should audit all of our elements for use of 
> /mnt/state/ and use the specific knowledge we have of the software they 
> relate to, to build one-time ID migration scripts, which would:
>  1: Execute before any related services start
>  2: Compare the now-static ID mappings against known files in /mnt/state
>  3: chown/chgrp any files/directories that need migrating
>  4: store a flag file in /mnt/state indicating that this process doesn't need 
> to run again
> 
> It does mean they have a potentially painfully long update process once, but 
> the result will be a completely stable, static arrangement that will not 
> require them to preserve precious build fragments for the rest of time. Nor 
> does it require some odd run-time remapping, or any additional mechanisms to 
> centralise user management (e.g. LDAP. Please, no LDAP!)
> 
> I think that tying ourselves and our operators into knots because we're 
> afraid of the hit of one-time data migration, is crazy.
> 
> AFAICS, the only risk left at that point, is elements that other people are 
> maintaining. If we consider that to be a sufficient risk, we can still build 
> the mechanism for injecting ID values from a previous build (essentially just 
> seeding the static values that we'd be setting anyway) and apologise to the 
> users who need that, or who don't discover its existence and break their 
> clouds.

I'm not afraid of running migrations once. I want to make sure we never
_plan_ to run migrations as part of regular operation.

I agree with most of what you've written, but first I'd start with this:

* Create an element which exports /etc/passwd and /etc/group from build
process.

* Create an element which imports /etc/passwd and /etc/group from local
disk into image. This will have an element-provides of uid-gid-map

* Create a separate element called 'static-users' which also provides
uid-gid-map. Contains a map of uids and gids, and creates users early on
with static UIDs/GIDs only. Disables usual commands used to add users and
groups (error message should explain well enough that user can add their
own element that provides uid-gid-map or switch to importing/exporting).

* Make use-ephemeral depend on uid-gid-map.

* Make tripleo-ci build with static-users, and recommend it in TripleO
documentation.

Once that is done, we will be producing builds with static users. If you
want to create a user for base TripleO, you'll need to do it by hand in
the static-users element. If you are downstream and want to do things
differently that should be easy, just provide your own uid-gid-map
element.

As for migrations, that is fairly simple and can be done generically,
I've already written a script

Re: [openstack-dev] [nova] Resource tracker

2014-10-07 Thread Vishvananda Ishaya


On Oct 7, 2014, at 6:21 AM, Daniel P. Berrange  wrote:

> On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote:
>> On Mon, Oct 6, 2014 at 6:03 AM, Gary Kotton  wrote:
>> 
>>> Hi,
>>> At the moment the resource tracker in Nova ignores that statistics that
>>> are returned by the hypervisor and it calculates the values on its own. Not
>>> only is this highly error prone but it is also very costly – all of the
>>> resources on the host are read from the database. Not only the fact that we
>>> are doing something very costly is troubling, the fact that we are over
>>> calculating resources used by the hypervisor is also an issue. In my
>>> opinion this leads us to not fully utilize hosts at our disposal. I have a
>>> number of concerns with this approach and would like to know why we are not
>>> using the actual resource reported by the hypervisor.
>>> The reason for asking this is that I have added a patch which uses the
>>> actual hypervisor resources returned and it lead to a discussion on the
>>> particular review (https://review.openstack.org/126237).
>>> 
>> 
>> So it sounds like you have mentioned two concerns here:
>> 
>> 1. The current method to calculate hypervisor usage is expensive in terms
>> of database access.
>> 2. Nova ignores that statistics that are returned by the hypervisor and
>> uses its own calculations.
>> 
>> 
>> To #1, maybe we can doing something better, optimize the query, cache the
>> result etc. As for #2 nova intentionally doesn't use the hypervisor
>> statistics for a few reasons:
>> 
>> * Make scheduling more deterministic, make it easier to reproduce issues
>> etc.
>> * Things like memory ballooning and thin provisioning in general, mean that
>> the hypervisor is not reporting how much of the resources can be allocated
>> but rather how much are currently in use (This behavior can vary from
>> hypervisor to hypervisor today AFAIK -- which makes things confusing). So
>> if I don't want to over subscribe RAM, and the hypervisor is using memory
>> ballooning, the hypervisor statistics are mostly useless. I am sure there
>> are more complex schemes that we can come up with that allow us to factor
>> in the properties of thin provisioning, but is the extra complexity worth
>> it?
> 
> That is just an example of problems with the way Nova virt drivers
> /currently/ report usage to the schedular. It is easily within the
> realm of possibility for the virt drivers to be changed so that they
> report stats which take into account things like ballooning and thin
> provisioning so that we don't oversubscribe. Ignoring the hypervisor
> stats entirely and re-doing the calculations in the resource tracker
> code is just a crude workaround really. It is just swapping one set
> of problems for a new set of problems.

+1 lets make the hypervisors report detailed enough information that we
can do it without having to recalculate.

Vish

> 
>> That being said I am fine with discussing in a spec the idea of adding an
>> option to use the hypervisor reported statistics, as long as it is off by
>> default.
> 
> I'm against the idea of adding config options to switch between multiple
> codepaths because it is just punting the problem to the admins who are
> in an even worse position to decide what is best. It is saying would you
> rather your cloud have bug A or have bug B. We should be fixing the data
> the hypervisors report so that the resource tracker doesn't have to ignore
> them, and give the admins something which just works and avoid having to
> choose between 2 differently broken options.
> 
> 
> 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



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

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Anita Kuno

On 10/07/2014 01:38 PM, Adam Young wrote:
> On 10/06/2014 05:28 PM, Anita Kuno wrote:
>> On 10/06/2014 04:11 PM, Adam Young wrote:
>>> On 10/06/2014 03:25 PM, Patricia Ellis wrote:
 Hi Adam,

 Thanks for taking the time to reply.

 I'm more of a web development type than security. I have some maths
 background so perhaps something with data analysis.

 To date I have done mostly Java, some JavaScript, Html, and MySQL. I
 am interested in learning Python. I co-developed a web app to check
 and commit time-sheets to a database during my work experience this
 summer; I did the database and the checking of the sheets. I, have
 also, created an Android app to monitor the fuel consumption in
 multiple vehicles, using the Android SQLite Database for storage.

>>> I am looking to get someone to work on a Javascript based web client to
>>> replace Horizon.
>> Can I just say that I think using new people looking to have work
>> experience with OpenStack to further pet projects, without telling them
>> it is a pet project and not considered a project which others may
>> consider OpenStack to be not the best approach for encouraging new
>> people.
> Good points:
> 
>> Not knocking your project, Adam, since I know nothing about it, and this
>> isn't the first time I have seen this happen. But I do believe that
>> folks asking to help out with something are looking to gain transferable
>> skills so that they have something to offer a potential employeer who is
>> looking for work experience with OpenStack. That would be what I would
>> be looking for anyway.
> No offense taken.  I think you are looking out for the interest of the
> poster and people wityh similar interests.
Thanks for understanding, Adam.
> 
> I can verify how hard to cut off a chunk for a new developer:  I had an
> intern I was working with this summer.  Most of the time was spent on
> learning the development process.
Exactly! I think this is a very salient point which is missed both by
people in Patricia's situation as well as the ones who send them here.

>  It would not be appropriate for
> someone in Patricia's position to try and come in and get a bug fix
> through.
Now on this point, I'm going to disagree, simply because I don't have
enough information on what Patricia's position actually is. I can guess
but until I hear from Patricia herself, I'm just guessing and I would
much rather know. It was my desire to know more about Patricia's
position that motivated my suggestion she join irc and perhaps ask a few
questions, allowing others to ask questions of her.

When interacting with other folks who enter under similar circumstances,
my first question invariably is "What is your goal?". I truly hope
Patricia has something better than "to get a good mark" because folks
with that goal rarely interest me, but who knows. I haven't had the
chance to ask.

>  That limits the number of projects available.
Now here is where I would like to interact with program administrators
at institutions such as Patricia's to ask them why a project? We have
over 300 including stackforge, why task a student with starting their
own, why not encourage them to learn our development process which then
can enable them to work on any of the 300 in various stages of development.
> 
> 
> Typically, and internship or a senior project like this is the correct
> place for a proof of concept or side project.
Well I guess I would like to change things a bit and interact more
closely with institutions so they are encouraging students to mix it up
with the rest of us (reviewing for marks, that appeals to me) rather
than working on their own on the side. They get what the prof wanted but
they don't get as much as they could get for their time in terms of what
would be useful after they get that rolled up piece of paper secured
with a ribbon. Also there are hiring managers afoot in them thar hills
masquerading as devs, who knows what might happen if you actually work
with them for 3 - 6 weeks what fate might bestow on you.

>  The project can be done
> with a focus more on functionality and less on stability.
> 
> 
> We should come up with a published list of "intern and senior projects
> proposals"
I agree that is would be helpful, not only to students, but also to
OpenStack to have a published list of endpoints (whatever they may be)
that allows newcomers to be productive while getting what they need to
show off to evaluators while also growing skills that will be useful to
them long term. Having them learn how to do work that benefits Openstack
(how about reviews?) wouldn't hurt us either.

Thanks Adam,
Anita.

> 
>> New people have no idea what are considered transferable skills within
>> OpenStack unless we tell them.
>>
>> Thanks,
>> Anita.
>>
>>>   There has been some work along these lines already.
>>>
>>> Beyond that, most of the projects I have are Python based Keystone
>>> features.  You can see the kinds of things I am

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Jay Faulkner

On Oct 7, 2014, at 10:38 AM, Adam Young  wrote:

> We should come up with a published list of "intern and senior projects 
> proposals"

I know there is a low-hanging-fruit tag in the bug tracker, and this summer 
when we had two interns on our team working on Openstack we had them both 
“onboard” to the development process by having them find and resolve 
low-hanging-fruit tagged bugs in IPA and Ironic.

I’d strongly suggest this list start with us being more vigilant about tagging 
bugs as low-hanging-fruit and then having those act as a gateway into the 
community. At Open Source Bridge this year, in a session about getting 
newcomers interested in open source, easy/l-h-f bugs were indicated as a 
strongly preferred way to get someone involved. Even to the level of suggesting 
a more senior developer could make the bug report better, with more breadcrumbs 
for a new person, to make it even easier to get started.

Just a thought :).

Thanks,
Jay Faulkner

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

Re: [openstack-dev] [nova] Resource tracker

2014-10-07 Thread Joe Gordon

On Tue, Oct 7, 2014 at 10:56 AM, Vishvananda Ishaya 
wrote:

>
> On Oct 7, 2014, at 6:21 AM, Daniel P. Berrange 
> wrote:
>
> > On Mon, Oct 06, 2014 at 02:55:20PM -0700, Joe Gordon wrote:
> >> On Mon, Oct 6, 2014 at 6:03 AM, Gary Kotton  wrote:
> >>
> >>> Hi,
> >>> At the moment the resource tracker in Nova ignores that statistics that
> >>> are returned by the hypervisor and it calculates the values on its
> own. Not
> >>> only is this highly error prone but it is also very costly – all of the
> >>> resources on the host are read from the database. Not only the fact
> that we
> >>> are doing something very costly is troubling, the fact that we are over
> >>> calculating resources used by the hypervisor is also an issue. In my
> >>> opinion this leads us to not fully utilize hosts at our disposal. I
> have a
> >>> number of concerns with this approach and would like to know why we
> are not
> >>> using the actual resource reported by the hypervisor.
> >>> The reason for asking this is that I have added a patch which uses the
> >>> actual hypervisor resources returned and it lead to a discussion on the
> >>> particular review (https://review.openstack.org/126237).
> >>>
> >>
> >> So it sounds like you have mentioned two concerns here:
> >>
> >> 1. The current method to calculate hypervisor usage is expensive in
> terms
> >> of database access.
> >> 2. Nova ignores that statistics that are returned by the hypervisor and
> >> uses its own calculations.
> >>
> >>
> >> To #1, maybe we can doing something better, optimize the query, cache
> the
> >> result etc. As for #2 nova intentionally doesn't use the hypervisor
> >> statistics for a few reasons:
> >>
> >> * Make scheduling more deterministic, make it easier to reproduce issues
> >> etc.
> >> * Things like memory ballooning and thin provisioning in general, mean
> that
> >> the hypervisor is not reporting how much of the resources can be
> allocated
> >> but rather how much are currently in use (This behavior can vary from
> >> hypervisor to hypervisor today AFAIK -- which makes things confusing).
> So
> >> if I don't want to over subscribe RAM, and the hypervisor is using
> memory
> >> ballooning, the hypervisor statistics are mostly useless. I am sure
> there
> >> are more complex schemes that we can come up with that allow us to
> factor
> >> in the properties of thin provisioning, but is the extra complexity
> worth
> >> it?
> >
> > That is just an example of problems with the way Nova virt drivers
> > /currently/ report usage to the schedular. It is easily within the
> > realm of possibility for the virt drivers to be changed so that they
> > report stats which take into account things like ballooning and thin
> > provisioning so that we don't oversubscribe. Ignoring the hypervisor
> > stats entirely and re-doing the calculations in the resource tracker
> > code is just a crude workaround really. It is just swapping one set
> > of problems for a new set of problems.
>

I agree, lets make reported hypervisor stats actually useful for
scheduling. This would mean we can have fewer config options (currently the
operator has to set aside resources for the underlying OS via a config
option).


>
> +1 lets make the hypervisors report detailed enough information that we
> can do it without having to recalculate.
>

Do we have any idea of how expensive recalculating this information is?


>
> Vish
>
> >
> >> That being said I am fine with discussing in a spec the idea of adding
> an
> >> option to use the hypervisor reported statistics, as long as it is off
> by
> >> default.
> >
> > I'm against the idea of adding config options to switch between multiple
> > codepaths because it is just punting the problem to the admins who are
> > in an even worse position to decide what is best. It is saying would you
> > rather your cloud have bug A or have bug B. We should be fixing the data
> > the hypervisors report so that the resource tracker doesn't have to
> ignore
> > them, and give the admins something which just works and avoid having to
> > choose between 2 differently broken options.
>
>
> >
> > Regards,
> > Daniel
> > --
> > |: http://berrange.com  -o-
> http://www.flickr.com/photos/dberrange/ :|
> > |: http://libvirt.org  -o-
> http://virt-manager.org :|
> > |: http://autobuild.org   -o-
> http://search.cpan.org/~danberr/ :|
> > |: http://entangle-photo.org   -o-
> http://live.gnome.org/gtk-vnc :|
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/ope

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Duncan Thomas

On 7 October 2014 19:01, Anita Kuno  wrote:
> On 10/07/2014 01:38 PM, Adam Young wrote:
>> On 10/06/2014 05:28 PM, Anita Kuno wrote:
>>> On 10/06/2014 04:11 PM, Adam Young wrote:
 I am looking to get someone to work on a Javascript based web client to
 replace Horizon.

>>> Can I just say that I think using new people looking to have work
>>> experience with OpenStack to further pet projects, without telling them
>>> it is a pet project and not considered a project which others may
>>> consider OpenStack to be not the best approach for encouraging new
>>> people.

I think writing a client / gui for openstack is one of the best single
projects you can do to get a good overview of the whole stack.

>>> Not knocking your project, Adam, since I know nothing about it, and this
>>> isn't the first time I have seen this happen. But I do believe that
>>> folks asking to help out with something are looking to gain transferable
>>> skills so that they have something to offer a potential employeer who is
>>> looking for work experience with OpenStack. That would be what I would
>>> be looking for anyway.

>> No offense taken.  I think you are looking out for the interest of the
>> poster and people wityh similar interests.



>>  It would not be appropriate for
>> someone in Patricia's position to try and come in and get a bug fix
>> through.

> Now on this point, I'm going to disagree, simply because I don't have
> enough information on what Patricia's position actually is. I can guess
> but until I hear from Patricia herself, I'm just guessing and I would
> much rather know. It was my desire to know more about Patricia's
> position that motivated my suggestion she join irc and perhaps ask a few
> questions, allowing others to ask questions of her.
>
> When interacting with other folks who enter under similar circumstances,
> my first question invariably is "What is your goal?". I truly hope
> Patricia has something better than "to get a good mark" because folks
> with that goal rarely interest me, but who knows. I haven't had the
> chance to ask.

If you're doing a final year project and your highest goal isn't 'to
get a good mark', then you're doing yourself a serious disservice. You
can have all sorts of secondary goals, but by the point in your
academic career where you're doing your final year project, your main
goal is to prove you're learnt and can apply all of the skills that
your course has covered. This actually involves a very different
process to getting something done in the 'real world'.

>>  That limits the number of projects available.
> Now here is where I would like to interact with program administrators
> at institutions such as Patricia's to ask them why a project? We have
> over 300 including stackforge, why task a student with starting their
> own, why not encourage them to learn our development process which then
> can enable them to work on any of the 300 in various stages of development.

Extremely difficult to get a decent academic project and therefore a
good mark out of an existing project that has had any substantial
amount of work done on it. Not impossible, but flicking through a pile
of old final year projects that got good marks shows that stand-alone
start-to-finish projects tend to get better marks. (I've looked into
this quite a bit)





-- 
Duncan Thomas

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

[openstack-dev] TC candidacy

2014-10-07 Thread Dean Troyer

I am Dean Troyer here to nominate myself as a candidate for the upcoming
Technical Committee election.

I have been involved with OpenStack for a long time, working on the
implementation at NASA of what became Nova. Since then I have been heavily
involved in a number of projects: I was an early contributor to DevStack
and served as its PTL during its short tenure as a stand-alone program, and
started Grenade to use DevStack as the basis for upgrade testing. I also
started the OpenStackClient project to address the disparity in user
interface experience in our CLI tools and have been working down the client
stack to improve the application developer experience using the client
libraries. I currently work for Nebula Inc. from my home in the hotbed of
overachiever baseball, Kansas City MO.

Recently some ideas I wrote down regarding the technical relationship of
OpenStack projects escaped into the wild and became part of the current
re-thinking of what OpenStack should look like. I think these ideas are a
result from a practical approach to building useful systems and identifying
the natural characteristics of both the projects and the people driving
them. Technical relationships might not define organizational
relationships, but they often look similar in the end.

The major changes being discussed are required as a result of the
tremendous growth of OpenStack and the changes in incentives for
contribution. This growth also feeds a desire to be all things to all
participants that simply is not possible at this scale. We can not rewind
the clock to the simpler times of 5 projects, but we can recover some of
the characteristics of those days by growing through division into a larger
number of smaller tents.

I'll be happy to answer specific questions beyond the ones below…

Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack
Mission?
I think the rapid growth in the number of incubated/integrated projects has
diluted the TC focus and attention and it has become clear that ignoring
the natural strata of OpenStack projects is not working.

Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical
committee mission?
I think this and the previous question are intertwined at this point and it
is time to do a sanity check on where we are and where we want to go. This
conversation has started and there is no clear answer yet.

Topic: Contributor Motivation
How would you characterize the various facets of contributor motivation?
I think at a high level this is one of the motivations to re-evaluate our
existing structure. We are a corporate-driven project and in spite of
individual efforts to remain independent the corporate influence is being
felt in ways that the individuals may have not anticipated, ie, being
'Integrated' is the most valuable attribute for a project, and is the
indicator for investment for many corporate managers.

At an individual level I see people who want to make a better cloud and
make the tools and components to get us there. We have some procedural
things to smooth out (CLA, etc) and some significant scaling issues to
address (review backlogs) in order to retain and utilize the energy being
brought to OpenStack by new contributors.

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?
As I wrote above, we have lost focus as we have attempted to widen the
scope of integrated projects. Rather than do a smaller number of things
very well the pressure is to do a lot of things.

Topic: New Contributor Experience
How would you characterize the experience new contributors have currently?
The mechanics of contributing (CLA, accounts, etc) could be much better. I
am not convinced that the CLA is providing value. The percentage of initial
contributions that I see that are more than trivial spelling fixes or
similar is low, as they need to focus on the process rather than the
content just to get going.

Topic: Communication
How would you describe our current state of communication in the OpenStack
community?
There are enough different communication channels available that it is hard
for anyone to monitor them all and still have time to write. I do think in
general we have done a good job of herding conversations toward the mailing
lists and logged IRC channels. Twitter and personal blogs are other common
avenues and may or may not be easy to discover if one doesn't already know
about them.

Topic: Relationship with the Foundation Board
The technical committee interacts with the foundation board on several
different fronts. How would you describe these interactions?
I have mostly seen the interaction around the DefCore work and have found
it interesting that neither side seems to want to say “This Is OpenStack”
for fear of stepping on toes.


dt

-- 

Dean Troyer
dtro...@gmail.com

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 02:26 PM, Dean Troyer wrote:
> I am Dean Troyer here to nominate myself as a candidate for the upcoming
> Technical Committee election.
> 
> I have been involved with OpenStack for a long time, working on the
> implementation at NASA of what became Nova. Since then I have been heavily
> involved in a number of projects: I was an early contributor to DevStack
> and served as its PTL during its short tenure as a stand-alone program, and
> started Grenade to use DevStack as the basis for upgrade testing. I also
> started the OpenStackClient project to address the disparity in user
> interface experience in our CLI tools and have been working down the client
> stack to improve the application developer experience using the client
> libraries. I currently work for Nebula Inc. from my home in the hotbed of
> overachiever baseball, Kansas City MO.
> 
> Recently some ideas I wrote down regarding the technical relationship of
> OpenStack projects escaped into the wild and became part of the current
> re-thinking of what OpenStack should look like. I think these ideas are a
> result from a practical approach to building useful systems and identifying
> the natural characteristics of both the projects and the people driving
> them. Technical relationships might not define organizational
> relationships, but they often look similar in the end.
> 
> The major changes being discussed are required as a result of the
> tremendous growth of OpenStack and the changes in incentives for
> contribution. This growth also feeds a desire to be all things to all
> participants that simply is not possible at this scale. We can not rewind
> the clock to the simpler times of 5 projects, but we can recover some of
> the characteristics of those days by growing through division into a larger
> number of smaller tents.
> 
> I'll be happy to answer specific questions beyond the ones below…
> 
> Topic: OpenStack Mission
> How do you feel the technical community is doing in meeting the OpenStack
> Mission?
> I think the rapid growth in the number of incubated/integrated projects has
> diluted the TC focus and attention and it has become clear that ignoring
> the natural strata of OpenStack projects is not working.
> 
> Topic: Technical Committee Mission
> How do you feel the technical committee is doing in meeting the technical
> committee mission?
> I think this and the previous question are intertwined at this point and it
> is time to do a sanity check on where we are and where we want to go. This
> conversation has started and there is no clear answer yet.
> 
> Topic: Contributor Motivation
> How would you characterize the various facets of contributor motivation?
> I think at a high level this is one of the motivations to re-evaluate our
> existing structure. We are a corporate-driven project and in spite of
> individual efforts to remain independent the corporate influence is being
> felt in ways that the individuals may have not anticipated, ie, being
> 'Integrated' is the most valuable attribute for a project, and is the
> indicator for investment for many corporate managers.
> 
> At an individual level I see people who want to make a better cloud and
> make the tools and components to get us there. We have some procedural
> things to smooth out (CLA, etc) and some significant scaling issues to
> address (review backlogs) in order to retain and utilize the energy being
> brought to OpenStack by new contributors.
> 
> 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?
> As I wrote above, we have lost focus as we have attempted to widen the
> scope of integrated projects. Rather than do a smaller number of things
> very well the pressure is to do a lot of things.
> 
> Topic: New Contributor Experience
> How would you characterize the experience new contributors have currently?
> The mechanics of contributing (CLA, accounts, etc) could be much better. I
> am not convinced that the CLA is providing value. The percentage of initial
> contributions that I see that are more than trivial spelling fixes or
> similar is low, as they need to focus on the process rather than the
> content just to get going.
> 
> Topic: Communication
> How would you describe our current state of communication in the OpenStack
> community?
> There are enough different communication channels available that it is hard
> for anyone to monitor them all and still have time to write. I do think in
> general we have done a good job of herding conversations toward the mailing
> lists and logged IRC channels. Twitter and personal blogs are other common
> avenues and may or may not be easy to discover if one doesn't already know
> about them.
> 
> Topic: Relationship with the Foundation Board
> The technical committee interacts with the foundation board on several
> different fronts. How would you describe these interactions?
> I have most

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Adam Lawson

Is the OP looking to help patch bugs with an individual program or to use
Openstack to deploy an interesting use case? The latter is how I
interpreted the question.


*Adam Lawson*

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


On Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas 
wrote:

> On 7 October 2014 19:01, Anita Kuno  wrote:
> > On 10/07/2014 01:38 PM, Adam Young wrote:
> >> On 10/06/2014 05:28 PM, Anita Kuno wrote:
> >>> On 10/06/2014 04:11 PM, Adam Young wrote:
>  I am looking to get someone to work on a Javascript based web client
> to
>  replace Horizon.
>
> >>> Can I just say that I think using new people looking to have work
> >>> experience with OpenStack to further pet projects, without telling them
> >>> it is a pet project and not considered a project which others may
> >>> consider OpenStack to be not the best approach for encouraging new
> >>> people.
>
> I think writing a client / gui for openstack is one of the best single
> projects you can do to get a good overview of the whole stack.
>
> >>> Not knocking your project, Adam, since I know nothing about it, and
> this
> >>> isn't the first time I have seen this happen. But I do believe that
> >>> folks asking to help out with something are looking to gain
> transferable
> >>> skills so that they have something to offer a potential employeer who
> is
> >>> looking for work experience with OpenStack. That would be what I would
> >>> be looking for anyway.
>
> >> No offense taken.  I think you are looking out for the interest of the
> >> poster and people wityh similar interests.
>
> 
>
> >>  It would not be appropriate for
> >> someone in Patricia's position to try and come in and get a bug fix
> >> through.
>
> > Now on this point, I'm going to disagree, simply because I don't have
> > enough information on what Patricia's position actually is. I can guess
> > but until I hear from Patricia herself, I'm just guessing and I would
> > much rather know. It was my desire to know more about Patricia's
> > position that motivated my suggestion she join irc and perhaps ask a few
> > questions, allowing others to ask questions of her.
> >
> > When interacting with other folks who enter under similar circumstances,
> > my first question invariably is "What is your goal?". I truly hope
> > Patricia has something better than "to get a good mark" because folks
> > with that goal rarely interest me, but who knows. I haven't had the
> > chance to ask.
>
> If you're doing a final year project and your highest goal isn't 'to
> get a good mark', then you're doing yourself a serious disservice. You
> can have all sorts of secondary goals, but by the point in your
> academic career where you're doing your final year project, your main
> goal is to prove you're learnt and can apply all of the skills that
> your course has covered. This actually involves a very different
> process to getting something done in the 'real world'.
>
> >>  That limits the number of projects available.
> > Now here is where I would like to interact with program administrators
> > at institutions such as Patricia's to ask them why a project? We have
> > over 300 including stackforge, why task a student with starting their
> > own, why not encourage them to learn our development process which then
> > can enable them to work on any of the 300 in various stages of
> development.
>
> Extremely difficult to get a decent academic project and therefore a
> good mark out of an existing project that has had any substantial
> amount of work done on it. Not impossible, but flicking through a pile
> of old final year projects that got good marks shows that stand-alone
> start-to-finish projects tend to get better marks. (I've looked into
> this quite a bit)
>
>
>
>
>
> --
> Duncan Thomas
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo] Meeting time

2014-10-07 Thread Roman Podoliaka

Hi all,

Last Friday we decided to find a better time for the weekly team
meeting. Keeping in mind that DST ends soon (October the 26th in
Europe, November the 2nd in the US), I think, we can choose from:

- Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
- Thursdays at 1600 UTC [2]: #openstack-meeting-3
- Thursdays at 1700 UTC [3]: #openstack-meeting-3
- Fridays at 1600 UTC (current time, may be ok when DST ends) [4]:
#openstack-meeting-alt, #openstack-meeting-3

(assuming the information about meeting rooms availability provided
here [0] is correct)

Basically, anything earlier than 1600 UTC will be too early for those
who live in CA after November the 2nd. And 1700+ UTC is beer o'clock
here in Europe :)

Alternatively, we could ask Infra  to add the meeting bot directly to
#openstack-oslo channel and have the weekly meeting there on any day
we like around 1600 UTC (#openstack-oslo is not really crowded, so it
shouldn't be a problem to use it for a meeting once a week).

Please let me know what you think.

Thanks,
Roman

[0] 
https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics

[1] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=3&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224

[2] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224

[3] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=17&min=0&sec=0&p1=367&p2=195&p3=179&p4=224

[4] 
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=7&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224

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

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

2014-10-07 Thread Ivar Lazzaro

Hi,

There are mainly two things you need to know when proposing a new Neutron
Plugin (or even any Openstack feature):

- The process [0];
- The tools [1].

Although the above documents cover those two points pretty well, I can give
you a high level overview of what the process looks like.
I'll not cover the "how to implement a plugin" part since it looks like you
are already past that :)

In order to add a new plugin/feature to the neutron repo, you first need to
propose it through our *specification process*.
The first step is to file a blueprint on launchpad [2] (register a
blueprint), in which you very briefly explain what you are trying to
attempt.
You can find many examples on how to write a blueprint in [2], but it'll
more or less look like this:

> *name: ferryboat-l2-plugin**title: L2 Neutron Plugin for supporting
> Ferryboat framework*

>
> *Summary:*
> *This proposal tracks the implementation of a new Neutron core plugin
> which allows the user **to implement L2 networks on the Ferryboat
> technology. In its first release, the plugin will support:*
>
> *- Port, Subnet, Network APIs;*
> *- Router APIs;**- Floating IPs;*
> *Security group support is planned for further iterations.*

Once you have filed the blueprint, you can publish your spec[3](look at
"Spec + Blueprints lifecycle" section) in the spec repo[4].
To do that, follow the Gerrit Workflow ([1] for details).
In a nutshell, you need to:

- Clone the spec repository locally,
- Write a specification following the template, it should be targeted to
Kilo (specs/kilo)
- Run "git review" so that it can be reviewed by the core dev team.

Once you do that, you spec will be published for review in the Openstack's
review board [5], where it'll have to wait for some core reviewer's
attention in order to
get approved.

Now to the actual patch:
When the specification gets approved (or even in parallel actually), you
can publish you Ferryboat plugin code for review just like you did for the
spec.
GerritWorkflow[1] will provide you a very clear understanding on how to
configure/use git in order to be able to do that.
So, again, you'll have to clone the Neutron's repository, add your code in
a local branch properly named, and then run "git review" so that it gets
published in the
review board.
In order to get approved and finally merged in the main Neutron repo, your
plugin needs to pass at least the following criteria:

- Pass all the unit tests;
- Its own unit tests have to be implemented! With as much code coverage as
possible;
- The Spec discussed above have to be approved and properly targeted;
- A *Third party CI system [5] *needs to be in place and positively voting
your patch;
- At least 2 core developers need to approve the patch based on its
compliance in terms of functionalities and code quality.

For those who implement a Neutron plugin for the first time, the Third
Party Ci system is usually the moment in which things get very hard!
The documentation pointed in [5][6], plus participating the weakly CI
meetings, should be enough for you to understand what needs to be done.
Very rapidly, Neutron needs to make sure that your plugin actually works,
and you want to make sure that no changes are trying to break your plugin!
To reach the goal,
you'll need to setup a continuous integration system "at home" which votes
a rightful amount of patches in review in order to validate that your
implementation is not
broken. Without a CI in place you plugin won't be approved, and removed if
already in tree.

The above should cover roughly 60% of the whole process, there are other
small details like the commit format, unit testing, and other things that
would be useless to overload here.
More than that, I suggest you to go on the IRC channels and look for help
there. My IRC alias is ivar-lazzaro, feel free to contact me :)

Last but not least, the first push in Openstack (especially if it's
something so big as a vendor plugin) is always tough! You'll go through a
TON of review rounds and nasty issues.
But don't be discouraged! It gets way better once you grasp the whole
process :)

Cheers,
Ivar.

[0] https://wiki.openstack.org/wiki/NeutronDevelopment
[1] https://wiki.openstack.org/wiki/Gerrit_Workflow
[2] https://launchpad.net/neutron
[3] https://wiki.openstack.org/wiki/Neutron/BlueprintTemplate
[4] https://github.com/openstack/neutron-specs
[5]
https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
[4] https://github.com/openstack/neutron

[5] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[6] http://ci.openstack.org/third_party.html
[7] https://wiki.openstack.org/wiki/IRC

On Sun, Oct 5, 2014 at 9:51 PM, thanh le giang 
wrote:

> Hi all
>
>
>
> I want to add a plugin to the Public Neutron Repository. Although I have
> read the gerrit workflow and Neutron Development page (
> https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know clearly
> how we can add our plugin

Re: [openstack-dev] [oslo] Meeting time


On Oct 7, 2014, at 3:01 PM, Roman Podoliaka  wrote:

> Hi all,
> 
> Last Friday we decided to find a better time for the weekly team
> meeting. Keeping in mind that DST ends soon (October the 26th in
> Europe, November the 2nd in the US), I think, we can choose from:
> 
> - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
> - Thursdays at 1600 UTC [2]: #openstack-meeting-3
> - Thursdays at 1700 UTC [3]: #openstack-meeting-3
> - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]:
> #openstack-meeting-alt, #openstack-meeting-3
> 
> (assuming the information about meeting rooms availability provided
> here [0] is correct)

Thanks for putting this list together, Roman.

> 
> Basically, anything earlier than 1600 UTC will be too early for those
> who live in CA after November the 2nd. And 1700+ UTC is beer o'clock
> here in Europe :)

Right, I think we were trying to move it off of Friday evening especially. :-)

> 
> Alternatively, we could ask Infra  to add the meeting bot directly to
> #openstack-oslo channel and have the weekly meeting there on any day
> we like around 1600 UTC (#openstack-oslo is not really crowded, so it
> shouldn't be a problem to use it for a meeting once a week).

I remember talking about that at some point, but I don’t remember why we 
decided against it. Since we have several options for earlier in the week using 
the existing meeting rooms I think it’s safe to pick one of those.

I have a slight preference for the Monday time slot, but all of them work for 
me. Does anyone else have a preference or a hard conflict with any of these 
times?

Doug

> 
> Please let me know what you think.
> 
> Thanks,
> Roman
> 
> [0] 
> https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
> 
> [1] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=3&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [2] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [3] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=17&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [4] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=7&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/10/14 06:51, thanh le giang wrote:
> Hi all
> 
> 
> 
> I want to add a plugin to the Public Neutron Repository. Although I
> have read the gerrit workflow and Neutron Development page 
> (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know 
> clearly how we can add our plugin to neutron repository. Could you 
> please share me the process?
> 

Note that there are discussions to move all (or most) plugins outside
the neutron tree (can't find the link atm, but it's mentioned in [1]).
So in the end, your plugin may end up in a separate repository.

[1]: https://etherpad.openstack.org/p/kilo-neutron-summit-topics

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

iQEaBAEBCgAGBQJUNDzwAAoJEC5aWaUY1u57O08H8Pwm93FbLr7SR9LUiVg114eJ
9jKsuhOBartQMidKHXMfCTxC6lYtqFkaZdjnHuZ6ADFAQsDEzucHxHiJZx0SmiIs
uD0NJeqLrS3UR0RJZMya5InfF1wso7B3CAXuGejAuQB0D08K7qR3nSRNGqcUn3k5
RVn6JNJk5DicuXrtrOOzvlUuPNeHx9b1/YfKhiC2J1Bl1WttOXzedZMXcRhlTBGN
wtWfyl4OzKLHPTvumUkT6NMoHyg0zHs/FBM7caOOzo3xsA+pq89E6q+mY5un6zUy
KKQI36zhIBvVUE0eIqekm9zqV+2AJxQnb+H6U4vRrAFMxjArvjUpgnLDN70T
=ow33
-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] [TripleO] a need to assert user ownership in preserved state

2014-10-07 Thread Robert Collins

On 8 October 2014 06:49, Clint Byrum  wrote:
> Excerpts from Chris Jones's message of 2014-10-07 04:35:33 -0700:

>> AFAICS, the only risk left at that point, is elements that other people are 
>> maintaining. If we consider that to be a sufficient risk, we can still build 
>> the mechanism for injecting ID values from a previous build (essentially 
>> just seeding the static values that we'd be setting anyway) and apologise to 
>> the users who need that, or who don't discover its existence and break their 
>> clouds.
>
> I'm not afraid of running migrations once. I want to make sure we never
> _plan_ to run migrations as part of regular operation.

If I can make a suggestion...

Set a marker in the image indicating whether it has fixed uuids or
not. Calculate that by comparing the contents of the computed passwd
and groups db's to the static reference we've put together.

Secondly, at the end of migrations.d write a marker file in /mnt/state
that indicates we're fully synced. This flag should contain a uuid of
the image and whether or not that image had fixed ids - or something
like that.

Then, the chown migration should activate if either a) the image
doesn't have fully fixed uuids, or b) the marker file is missing, or
c) the marker file has a different uuid and indicates the prior image
didn't have fixed ids.

-Rob

-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

2014-10-07 Thread Chris Jones

Hi

> On 7 Oct 2014, at 18:49, Clint Byrum  wrote:
> * Create an element which imports /etc/passwd and /etc/group from local
> disk into image. This will have an element-provides of uid-gid-map

I don't think it should import those files wholesale, IMO that's making way too 
many assumptions about the similarity of the two builds.

I think this needs to be at least somewhat driven from the elements themselves 
- they need to declare the users/groups they need and likely offer a default 
UID/GID for each.
The element you describe could consult the elements to determine which 
users/groups need to be created, pull the values it needs from the passwd/group 
files if they exist, or fall back on the offered static defaults if not, then 
use normal tools to create the user/group (mainly so we respect whatever libnss 
settings the operator has chosen).

> * Create a separate element called 'static-users' which also provides
> uid-gid-map. Contains a map of uids and gids, and creates users early on

I don't like the idea of keeping the map in a single element, for several 
reasons:
 1: Harder to maintain across multiple element repos (e.g. we have two repos, 
do we have a static-users equivalent in each?)
 2: Harder for downstreams to fork if they want to add an element we don't carry
 3: Harder for devs to commit to, especially if it means they need to 
simultaneously land something in di-b and t-i-e.

> with static UIDs/GIDs only. Disables usual commands used to add users and
> groups (error message should explain well enough that user can add their

Are you suggesting disabling those during build time only, or runtime too? I 
strongly dislike the latter and I'm not thrilled about the former. I'd rather 
we leave them as-is and audit the passwd/group files at the end of the build, 
vs what we were expecting from the elements.

(we should also be aware that by enforcing this, we'll be increasing the number 
of elements we need to supply, because any dependencies that get pulled in 
during the build, which create users/groups, will now error/fail the build)

> As for migrations, that is fairly simple and can be done generically,
> I've already written a script that does it fairly reliably. The only

Curious to see how that works - how can it know that /mnt/state/some/random/dir 
currently listed as "ceilometer" was actually owned by "swift" on the previous 
boot?

Cheers,

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

Re: [openstack-dev] [oslo] Meeting time

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/10/14 21:01, Roman Podoliaka wrote:
> Hi all,
> 
> Last Friday we decided to find a better time for the weekly team 
> meeting. Keeping in mind that DST ends soon (October the 26th in 
> Europe, November the 2nd in the US), I think, we can choose from:
> 
> - Mondays at 1600 UTC [1]: #openstack-meeting-alt,
> #openstack-meeting-3 - Thursdays at 1600 UTC [2]:
> #openstack-meeting-3 - Thursdays at 1700 UTC [3]:
> #openstack-meeting-3 - Fridays at 1600 UTC (current time, may be ok
> when DST ends) [4]: #openstack-meeting-alt, #openstack-meeting-3

Friday is beer day (especially here in Czech Republic!); Thursdays are
harsh in terms of meetings in my calendar (though 1600 is bearable). I
vote for Mondays.

> 
> (assuming the information about meeting rooms availability
> provided here [0] is correct)
> 
> Basically, anything earlier than 1600 UTC will be too early for
> those who live in CA after November the 2nd. And 1700+ UTC is beer
> o'clock here in Europe :)
> 
> Alternatively, we could ask Infra  to add the meeting bot directly
> to #openstack-oslo channel and have the weekly meeting there on any
> day we like around 1600 UTC (#openstack-oslo is not really crowded,
> so it shouldn't be a problem to use it for a meeting once a week).
> 
> Please let me know what you think.
> 
> Thanks, Roman
> 
> [0]
> https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
>
>  [1]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=3&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>
>  [2]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>
>  [3]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=17&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>
>  [4]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=7&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>
>  ___ 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)

iQEcBAEBCgAGBQJUND18AAoJEC5aWaUY1u57zFYIAI7xbaKnrfly6IUlJxG8Of8d
n21PY05Jr/3vqq+sb+7E+a7Ty0xN1Rk2ehgUZsAMeQl59uH6JAqMoLavZjdfMkUO
jxziRcR/si8wJ0LL1cXW0v5FDTYfYHoGkeJcmF1kbbOIVeezvhC2Ow7MkldIWZJk
UmvUqGHshawERb0Hf1LIYnyU03mkg+F/lcdoT0xnLmI5UKEGVE9KjLsG8/mJ5aW0
uOiN0rgOR1+0sP6TWJArDD303feTcr+/ibeAgCmCEuLi0u/h54RnXRTdRScwPMdG
ZMeDc/BcB3TY1wCnmMxvxLDDcIiZ6YIlpLPmmdDPXlxQf1OCgPJ24pBTSu9Hrww=
=Ofcz
-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] [Neutron][LBaaS][Octavia] Floating IP management

2014-10-07 Thread Brandon Logan

I'll add some more info to this as well:

Neutron LBaaS creates the neutron port for the VIP in the plugin layer
before drivers ever have any control.  In the case of an async driver,
it will then call the driver's create method, and then return to the
user the vip info.  This means the user will know the VIP before the
driver even finishes creating the load balancer.

So if Octavia is just going to create a floating IP and then associate
that floating IP to the neutron port, there is the problem of the user
not ever seeing the correct VIP (which would be the floating iP).

So really, we need to have a very detailed discussion on what the
options are for us to get this to work for those of us intending to use
floating ips as VIPs while also working for those only requiring a
neutron port.  I'm pretty sure this will require changing the way V2
behaves, but there's more discussion points needed on that.  Luckily, V2
is in a feature branch and not merged into Neutron master, so we can
change it pretty easily.  Phil and I will bring this up in the meeting
tomorrow, which may lead to a meeting topic in the neutron lbaas
meeting.

Thanks,
Brandon

On Mon, 2014-10-06 at 17:40 +, Phillip Toohill wrote:
> Hello All, 
> 
> I wanted to start a discussion on floating IP management and ultimately
> decide how the LBaaS group wants to handle the association. 
> 
> There is a need to utilize floating IPs(FLIP) and its API calls to
> associate a FLIP to the neutron port that we currently spin up. 
> 
> See DOCS here:
> 
> > http://docs.openstack.org/api/openstack-network/2.0/content/floatingip_create.html
> 
> Currently, LBaaS will make internal service calls (clean interface :/) to 
> create and attach a Neutron port. 
> The VIP from this port is added to the Loadbalancer object of the Load 
> balancer configuration and returned to the user.
> 
> This creates a bit of a problem if we want to associate a FLIP with the port 
> and display the FLIP to the user instead of
> the ports VIP because the port is currently created and attached in the 
> plugin and there is no code anywhere to handle the FLIP
> association. 
> 
> To keep this short and to the point:
> 
> We need to discuss where and how we want to handle this association. I have a 
> few questions to start it off. 
> 
> Do we want to add logic in the plugin to call the FLIP association API?
> 
> If we have logic in the plugin should we have configuration that identifies 
> weather to use/return the FLIP instead the port VIP?
> 
> Would we rather have logic for FLIP association in the drivers?
> 
> If logic is in the drivers would we still return the port VIP to the user 
> then later overwrite it with the FLIP? 
> Or would we have configuration to not return the port VIP initially, but an 
> additional query would show the associated FLIP.
> 
> 
> Is there an internal service call for this, and if so would we use it instead 
> of API calls? 
> 
> 
> Theres plenty of other thoughts and questions to be asked and discussed in 
> regards to FLIP handling, 
> hopefully this will get us going. I'm certain I may not be completely 
> understanding this and 
> is the hopes of this email to clarify any uncertainties. 
> 
> 
> 
> 
> 
> ___
> 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] What's Up Doc? Oct 7 2014

2014-10-07 Thread Anne Gentle

Hi everyone,

Be sure to read the discussions on openstack-dev about scaling
documentation efforts across projects. Lots of great discussion on this
thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-October/047802.html

We've got a new gerrit dashboard for doc reviews that shows works in
progress as well as doc patches that have merged in the last week. Try it
for yourself with http://is.gd/M4wghC

This past week saw a lot of driver doc patches proposed and landing for
storage and Hyper-V updates. We're happy to review those but I think we're
carefully considering more pointers to outside documentation for driver
configuration so that driver maintainers don't have to duplicate
maintenance of docs. I'd love discussion on this point -- at the Ops meetup
for example, they suggested just pointing to the external sites for those
docs. Makes sense to me, but I want discussion.

In addition, the install guide work is ongoing. You can see the test matrix
here: https://wiki.openstack.org/wiki/JunoDocTesting and note that testing
is not yet started on release candidates. Feel free to test and fill in the
matrix as you go. For the OpenStack dashboard (horizon) on Ubuntu, we're
awaiting updates for a python-xstatic package dependency.

Also the networking guide has a small subteam working on it. The TOC for
the networking guide is available at:
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
So far we have three blog entries and some test results back from Phil
Hopkins. We need more content for this guide so please do send it in with
any format you have.

The Foundation has offered web designers to revise our (aging)
docs.openstack.org site design and I met with them and Tom Fifield last
week to go over the requirements and scope of the project. Looking forward
to a refresh for sure.

For API documentation, I'm still working through a large change to remove
the docs.openstack.org/api documents and point to the reference page at
http://developer.openstack.org/api-ref.html. In this change I need to
propose patches for these projects specs repo:
nova (compute-api) v2, v2.1
swift (object-api) v1
glance (image-api) v1, v1.1, v2
keystone (identity-api) v2.0, v3
neutron (netconn-api) v1.0, v2.0
cinder (volume-api) v1.0, v2.0
Then I can delete the repos in the parentheses above.

Some projects don't have this type of document in a separate -api
repo that I know of, which is just fine:
trove
ceilometer
heat
sahara
ironic
zaqar (marconi)
barbican
designate
manila

I hope this cleanup can move us forward in API documentation questions of
what docs, where to source and publish, and for whom do we write them. My
current thinking is that there should be specs written for and by
contributor devs, and also reference docs written for app devs by
contributor devs and api writers.

This week I'm at the Grace Hopper conference with 7,999 other women in
technology. Matt Kassawara has agreed to run the docs team meeting in
#openstack-meeting tomorrow at 14:00 UTC (09:00 Central). Agenda is here:
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting

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

[openstack-dev] [Neutron] How to write extension

2014-10-07 Thread Sławek Kapłoński

Hello,

Can You send me some examples or link to tutorial how to write extension to 
neutron. I'm using ML2 plugin in neutron and I want to add some new 
functionality and API methods to this neutron. So imho I should do it via 
extension but how exactly write it that it will work in existing ML2 plugin?

---
Best regards
Sławek Kapłoński
sla...@kaplonski.pl

signature.asc
Description: This is a digitally signed message part.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] Meeting time

2014-10-07 Thread Mike Bayer


On Oct 7, 2014, at 3:15 PM, Doug Hellmann  wrote:

> 
> I remember talking about that at some point, but I don’t remember why we 
> decided against it. Since we have several options for earlier in the week 
> using the existing meeting rooms I think it’s safe to pick one of those.
> 
> I have a slight preference for the Monday time slot, but all of them work for 
> me. Does anyone else have a preference or a hard conflict with any of these 
> times?

I’m fine with whatever.




> 
> Doug
> 
>> 
>> Please let me know what you think.
>> 
>> Thanks,
>> Roman
>> 
>> [0] 
>> https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
>> 
>> [1] 
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=3&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>> 
>> [2] 
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>> 
>> [3] 
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=17&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>> 
>> [4] 
>> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=7&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

2014-10-07 Thread Robert Kukura

If you are thinking about adding a new neutron core plugin, please 
consider whether you could accomplish what you need with an ML2 
MechanismDriver instead. Its a lot less code to write, review, and maintain.


-Bob

On 10/6/14 12:51 AM, thanh le giang wrote:


Hi all

I want to add a plugin to the Public Neutron Repository. Although I 
have read the gerrit workflow and Neutron Development page 
(https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know 
clearly how we can add our plugin to neutron repository. Could you 
please share me the process?


Thanks and best regards,


--
L.G.Thanh

Email:legiangt...@gmail.com 
lgth...@fit.hcmus.edu.vn 


___
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] a need to assert user ownership in preserved state

2014-10-07 Thread Clint Byrum

Excerpts from Chris Jones's message of 2014-10-07 12:23:20 -0700:
> Hi
> 
> > On 7 Oct 2014, at 18:49, Clint Byrum  wrote:
> > * Create an element which imports /etc/passwd and /etc/group from local
> > disk into image. This will have an element-provides of uid-gid-map
> 
> I don't think it should import those files wholesale, IMO that's making way 
> too many assumptions about the similarity of the two builds.
> 

Disagree on the grounds that the point of this is to deal with people
who already have images and want to update them. We're not trying to
enable people to deploy radically different OS's or anything like that.

> I think this needs to be at least somewhat driven from the elements 
> themselves - they need to declare the users/groups they need and likely offer 
> a default UID/GID for each.
> The element you describe could consult the elements to determine which 
> users/groups need to be created, pull the values it needs from the 
> passwd/group files if they exist, or fall back on the offered static defaults 
> if not, then use normal tools to create the user/group (mainly so we respect 
> whatever libnss settings the operator has chosen).
> 

That is a lot of complexity for the case that we don't want people to
use (constantly carrying /etc/passwd and /etc/group forward).

> > * Create a separate element called 'static-users' which also provides
> > uid-gid-map. Contains a map of uids and gids, and creates users early on
> 
> I don't like the idea of keeping the map in a single element, for several 
> reasons:
>  1: Harder to maintain across multiple element repos (e.g. we have two repos, 
> do we have a static-users equivalent in each?)
>  2: Harder for downstreams to fork if they want to add an element we don't 
> carry
>  3: Harder for devs to commit to, especially if it means they need to 
> simultaneously land something in di-b and t-i-e.
> 

I think that makes sense. The per-element expressions will still need
to be coalesced into one place to check for conflicts. I suppose if we
use "add only" tools that will work.

> > with static UIDs/GIDs only. Disables usual commands used to add users and
> > groups (error message should explain well enough that user can add their
> 
> Are you suggesting disabling those during build time only, or runtime too? I 
> strongly dislike the latter and I'm not thrilled about the former. I'd rather 
> we leave them as-is and audit the passwd/group files at the end of the build, 
> vs what we were expecting from the elements.
> 
> (we should also be aware that by enforcing this, we'll be increasing the 
> number of elements we need to supply, because any dependencies that get 
> pulled in during the build, which create users/groups, will now error/fail 
> the build)
> 

So I think we still do care about these. MySQL puts its files on
/mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files
on /mnt/state. If an element installs a package that needs a user, we
have to treat that as our responsibility to handle, because we want to
preserve /mnt/state.

> > As for migrations, that is fairly simple and can be done generically,
> > I've already written a script that does it fairly reliably. The only
> 
> Curious to see how that works - how can it know that 
> /mnt/state/some/random/dir currently listed as "ceilometer" was actually 
> owned by "swift" on the previous boot?

It also has to have access to the previous image's /etc/passwd and
/etc/group. In the context I wrote it in, updating via ansible, I can
cheat and copy that into /mnt/state before rebuilding the box. But we
can do that in our elements too. :)

___
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

2014-10-07 Thread Joe Gordon

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.
>
>
We have had a subset of nova-core manage the blueprints for a while now
with good results.  I look forward to hearing how this works out for
Neutron in Kilo.




> 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

On Tue, Oct 7, 2014 at 2:20 PM, Ihar Hrachyshka  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 06/10/14 06:51, thanh le giang wrote:
>> Hi all
>>
>>
>>
>> I want to add a plugin to the Public Neutron Repository. Although I
>> have read the gerrit workflow and Neutron Development page
>> (https://wiki.openstack.org/wiki/NeutronDevelopment), I don't know
>> clearly how we can add our plugin to neutron repository. Could you
>> please share me the process?
>>
>
> Note that there are discussions to move all (or most) plugins outside
> the neutron tree (can't find the link atm, but it's mentioned in [1]).
> So in the end, your plugin may end up in a separate repository.
>
> [1]: https://etherpad.openstack.org/p/kilo-neutron-summit-topics
>
Yes, this is very likely to happen in Kilo and it's one of the
refactoring related items the team will focus on in Kilo. I hope next
week to have this more documented on an etherpad for folks to consume
prior to the Summit.

Thanks,
Kyle


> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iQEaBAEBCgAGBQJUNDzwAAoJEC5aWaUY1u57O08H8Pwm93FbLr7SR9LUiVg114eJ
> 9jKsuhOBartQMidKHXMfCTxC6lYtqFkaZdjnHuZ6ADFAQsDEzucHxHiJZx0SmiIs
> uD0NJeqLrS3UR0RJZMya5InfF1wso7B3CAXuGejAuQB0D08K7qR3nSRNGqcUn3k5
> RVn6JNJk5DicuXrtrOOzvlUuPNeHx9b1/YfKhiC2J1Bl1WttOXzedZMXcRhlTBGN
> wtWfyl4OzKLHPTvumUkT6NMoHyg0zHs/FBM7caOOzo3xsA+pq89E6q+mY5un6zUy
> KKQI36zhIBvVUE0eIqekm9zqV+2AJxQnb+H6U4vRrAFMxjArvjUpgnLDN70T
> =ow33
> -END PGP SIGNATURE-
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

2014-10-07 Thread Kevin Benton

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

Re: [openstack-dev] [Infra] Meeting Tuesday October 7th at 19:00 UTC

2014-10-07 Thread Elizabeth K. Joseph

On Mon, Oct 6, 2014 at 4:06 PM, Elizabeth K. Joseph
 wrote:
> The OpenStack Infrastructure (Infra) team is hosting our weekly
> meeting on Tuesday October 7th, at 19:00 UTC in #openstack-meeting

Meeting minutes and log are now available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-10-07-19.00.log.html

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

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

Re: [openstack-dev] [qa] In-tree functional test vision

2014-10-07 Thread Matthew Treinish

On Tue, Oct 07, 2014 at 04:28:23PM +0100, Chris Dent wrote:
> On Mon, 25 Aug 2014, Joe Gordon wrote:
> >On Mon, Aug 4, 2014 at 3:29 AM, Chris Dent  wrote:
> >>For constraints: Will tempest be available as a stable library? Is using
> >>tempest (or other same library across all projects) a good or bad thing?
> >>Seems there's some disagreement on both of these.
> >
> >Yes, there is a separate thread on spinning out a tempest-lib (not sure on
> >what final name will be yet) that functional tests can use. Although I
> >think there is a lot  to be done before  needing the tempest-lib.
> 
> What's the status of tempest-lib? Looking at the repo it appears
> that other things may be taking priority at the moment.

Things were blocked briefly by global requirements freeze. I'll hopefully be
cutting the first release this week, just waiting on one patch to go through.
We already have most of the pieces in place already to start using it on ci 
jobs so it should just be a matter of getting: 
https://review.openstack.org/#/c/122478/ landed before you can import it
anywhere. That being said it's still a lower priority dev item compared to some
other tasks, mostly because we don't have too many interfaces in tempest which
are considered stable enough to migrate yet. The long term scope of the library
hasn't been clearly defined yest, so not entirely clear what things are worth
migrating into the library at this point. 

Next up I expect to migrate the auth layer and the base rest client. This will
allow projects to build service specific clients out of tree, which I've seen
commonly done for projects prior to incubation. This won't include the service
clients in tempest though, because we expect to make some changes to that
interface soon. That being said I'm not sure how long the additional library
migrations will take.

> 
> As I said in notifications thread: With summit approaching and kilo
> open for business, now seems to be talking about what kinds of
> structure we want to apply to in-tree functional testing.
> 

There is nothing stopping you from doing this. Tempest-lib is not a requirement
for doing this at all, and should really only be useful for some specific types
of testing. It shouldn't be required for functional testing in general. Also, at
this point tempest-lib only contains the CLI testing framework which is hardly
useful for spinning up project specific functional testing.

-Matt Treinish

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

[openstack-dev] TC candidacy

2014-10-07 Thread Russell Bryant

Hello, everyone!

I would like to run for re-election on the Technical Committee. I have
been an elected member of the TC since it was created in the Fall of
2012 [1]. I have been contributing to OpenStack since late 2011 (commits
[2] reviews [3]). My most substantial contributions have been to Nova,
where I also served as the PTL for the Havana and Icehouse releases. For
further details on my background, see openhub [4] or linkedin [5].

I have been a proactive member of the TC.  I take my broad experience
with the project and work to turn it into change that puts us in a
better position for the future.  Some specific examples of actions I’ve
taken may help demonstrate this.

Over the last cycle it became clear that the TC could do a better job at
communicating what we’re up to to the broader community.  I helped
launch an ongoing effort to blog about TC activities.  I wrote the first
[9] and third [10] posts of this series. We now intend to rotate the
authorship of these posts through a group of willing TC members.

I’ve become deeply familiar with the history of Neutron vs. nova-network
through my work with the Nova project.  During my second term as the
Nova PTL, we unfortunately reached a point where we had to unfreeze
development on nova-network [11].  I wanted to find ways to help improve
the current situation and help prevent it from happening again.  I
identified policy that could be added (must have explicit deprecation
and migration plan in place before graduation) [12] for the future.  To
help with the current situation, I proposed that we kick off a round of
project reviews where we review all existing projects against our
incubation and graduation requirements [13].  This process resulted in a
gap analysis and plans for filling those gaps for Neutron [14], Trove,
Ceilometer, Horizon, Glance, and Heat.  We are now much closer to being
able to deprecate nova-network than we were 6 months ago thanks to some
very hard work by the Neutron team.  I think these reviews were very
productive and I hope to help continue this process with the TC going
forward.

The TC has the critical role to evolve and scale our structure and
processes to ensure the ongoing health of our development community.
We’ve worked through important changes in every cycle so far.  From
recent discussions it is quite clear that it is time for another round
of big changes to how we organize our teams and projects. The TC itself
has even become a bottleneck in some cases.  I see resolving these
issues as a top priority for the TC over the next release cycle.

There are far too many things wrapped up in the incubation and
integration statuses.  They communicate different things to different
audiences.  This overload has led to a lot of conflict.  It’s a high
priority for me to ensure that with whatever changes we make, we value
an inclusive community that lets projects doing good work be a part of
OpenStack.  We need to rework the organization such that what we’re
communicating is the most useful information for each audience.  At the
same time, we need allow this growth in such a way that it doesn’t
provide unbearable strain on horizontal project resources like
documentation, infrastructure, or release management.  The incubated and
integrated statuses are not doing the job, but I’m confident that we can
work through our next evolution, and I would like to be a part of
ensuring that happens.

Thank you all for your consideration. It’s an honor and a pleasure to
work with you. If there’s anything you would like to discuss, please
feel free to reach out to me.


Below you will find my answers to the provided questions [6].

*** Topic: OpenStack Mission

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

To recap, the mission statement is “to produce the ubiquitous Open
Source Cloud Computing platform that will meet the needs of public and
private clouds regardless of size, by being simple to implement and
massively scalable.”

“ubiquitous” - I think the part we’re doing great here.  OpenStack is
growing like crazy and is being used all over the place.  The list of
supporting companies [7] is impressive.  The number and diversity of our
contributors is even more impressive.  With that said, we shouldn’t get
comfortable.  There is a lot more to go.

“public and private clouds” - I think we do a nice job working to
support both of these use cases.

“regardless of size”, “massively scalable” - This one probably depends
on who you ask.  :-)  Our scalability depends on the project.  In some
areas we’re doing great.  In all areas, we have more improvements to
make.  I think our biggest failure here has been how well we communicate
what to expect to the rest of the community.  Some people expect that
they can take every component of the integrated release to large public
cloud scale.  That isn’t true and we’ve done a poor job of setting
expectations here.  This is something I’d like to improve on.

“simple t

Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?

2014-10-07 Thread Dirk Müller

2014-10-02 14:19 GMT+02:00 Duncan Thomas :

Hi,

> What is actually needed is those who rely on the stable branch(es)
> existence need to step forward and dedicate resources to it. Putting
> the work on people not interested is just the same as killing them
> off, except slower, messier and creating more anger and otehr
> community fallout along the way.

I'm paid by one of those distros that are interested in stable branch
maintenance but have no idea what needs to be done other than saying
"I'm interested in helping out". I've been proposing patches to
backport every once in a while already and being frustrated that it
takes weeks if not months for someone to review them and potentially
merge. What are the queries that people are supposed to look at ? How
can I help in pushing patches or look for gating failures *specific*
to stable/ branches?

Thanks,
Dirk

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

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

2014-10-07 Thread Chris Jones

Hi

> On 7 Oct 2014, at 20:47, Clint Byrum  wrote:
>> 
>> I don't think it should import those files wholesale, IMO that's making way 
>> too many assumptions about the similarity of the two builds.
> Disagree on the grounds that the point of this is to deal with people
> who already have images and want to update them. We're not trying to
> enable people to deploy radically different OS's or anything like that.

My point is that we don't know what else is changing under the hood. Switching 
OS is a bit extreme, but we don't know that they're not going to pull in an OS 
upgrade at the same time and have everything change substantially, or even just 
introduce one additional dependency which we would destroy the uid/gid for.

>> I think this needs to be at least somewhat driven from the elements 
>> themselves - they need to declare the users/groups they need and likely 
>> offer a default UID/GID for each.
>> The element you describe could consult the elements to determine which 
>> users/groups need to be created, pull the values it needs from the 
>> passwd/group files if they exist, or fall back on the offered static 
>> defaults if not, then use normal tools to create the user/group (mainly so 
>> we respect whatever libnss settings the operator has chosen).
>> 
> 
> That is a lot of complexity for the case that we don't want people to
> use (constantly carrying /etc/passwd and /etc/group forward).

As tchaypo pointed out on IRC, if we do this static route, we are laying down a 
great big concrete slab of opinion in our images. I'm all for opinionated 
software, but we need to give people an out, which means we probably want to 
have a way for the suggested default UID/GIDs to be overridden, i.e. roughly 
what I described. We can just use that override to inject the pre-existing 
passwd/group values, if we so desire.

> I think that makes sense. The per-element expressions will still need
> to be coalesced into one place to check for conflicts. I suppose if we

Definitely. If we use normal system tools to create the users/groups, the build 
will fail if there are conflicts.

> So I think we still do care about these. MySQL puts its files on
> /mnt/state. RabbitMQ puts its files on /mnt/state. icinga puts its files
> on /mnt/state. If an element installs a package that needs a user, we
> have to treat that as our responsibility to handle, because we want to
> preserve /mnt/state.

Agreed. I just wanted to put a note on the table that we will have to care 
about these things :)

> It also has to have access to the previous image's /etc/passwd and
> /etc/group. In the context I wrote it in, updating via ansible, I can

*nods*

Cheers,

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

[openstack-dev] [Sahara] Juno RC2 available

2014-10-07 Thread Thierry Carrez

Hello everyone,

Due to various regressions and documentation issues in the published
Sahara RC1, we generated a new Juno release candidate for Sahara:

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

Unless new release-critical issues are found that warrant a release
candidate respin, this RC2 will be formally released as Sahara 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/sahara/tree/proposed/juno

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

https://bugs.launchpad.net/sahara/+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] TC candidacy

I am announcing my candidacy for a position on the OpenStack Technical
Committee.

I am currently employed by HP to work upstream on OpenStack. I started
contributing in 2012, not long after joining DreamHost. I am one of
the founding members of the Ceilometer project, and a core reviewer
for the requirements and unified command line interface projects. I am
also part of the team working on the Python 3 transition, and have
contributed to several of the infrastructure projects. Kilo will be my
third term serving as PTL for the Oslo project, and I have served on
the Technical Committee for the last year. In addition to my technical
contributions, I helped to found and still help to organize the
OpenStack meetup group in Atlanta, Georgia.

I've included the answers to the formally posed election questions
below, but please follow up here with any other questions you might
have for me.

The OpenStack community is the most exciting and welcoming group I
have interacted with in more than 20 years of contributing to open
source projects. I'm looking forward to continuing to being a part
of the community and serving the project.

Thank you,
Doug

Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
Commit history: https://review.openstack.org/#/q/owner:2472,n,z
Stackalytics: http://stackalytics.com/?user_id=doug-hellmann
Foundation: http://www.openstack.org/community/members/profile/359
OpenHUB: https://www.openhub.net/accounts/doughellmann
Freenode: dhellmann
Website: http://doughellmann.com



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

I am amazed by what our community produces. We have some truly
exceptional development teams building great software. We regularly
add new components to the system, and our feature set is as diverse as
the community. Our work is not perfect, but as we continue to refine
it based on experience and input from users, we are continually
improving the way we work and what we produce.

However, there are recurring themes in the user feedback after every
release: We need to make OpenStack easier to operate, easier to use,
and easier to debug. We are starting to build cross-project teams to
work more directly on some of these areas, and it's important that we
give priority to that work and consider usability and scalability as
features.

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

We're fulfilling most of the mission, but we can do better.

The Zaqar graduation discussion is a good example of an area where we
need to rethink how we bring new project teams into OpenStack. There
are several similar suggestions to drop our current incubation and
integration process completely, and that is one option. Another is to
set up the resources we would need to do an objective technical
evaluation for projects. I favor a combination of those two ideas,
evaluating projects on several criteria from the users' perspective,
but deciding the "official" status of a team based on community
considerations.

We have also recognized that we need some way to handle cross-project
initiatives such as improving our logging to make debugging easier,
but we do not yet have a formal structure in place to accomplish those
goals. The way we set up working groups for those sorts of jobs is
going to depend on the outcome of the bigger governance discussion,
but I think they should be organized by the TC.

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

I don't know if we have numbers, but my impression is that most of our
contributions come from people employed at least in part to work on
OpenStack. Their commitment to the project as a whole, outside of
their area of specialty, varies for a lot of reasons. We want everyone
to have a strong commitment to the whole project, but that's not
always realistic, because it's not always up to the individual to
decide how much time or effort they can put into working on OpenStack,
or into a given area. That's perfectly normal and OK. We can, and do,
welcome contributions from all sorts of people for all sorts of
reasons.

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

Growing so quickly is forcing us to think about how we organize our
selves and make changes explicitly, and more rapidly, rather than
allowing for a slower evolution.  We've had a lot of blog posts and
mailing list threads talking about ways to handle the growth through
governance model changes to the project. These are important decisions
for us to make as a community, and we need to weigh both sides of each
issue carefully.

For example, we want to be more inclusive and bring more project teams
into OpenStack, but doing that further strains our cross-pro

Re: [openstack-dev] [All] [I18N] compiling translation message catalogs

2014-10-07 Thread Dirk Müller

Hi Julie,

> I'm adding a couple of people on cc: with an interest in Ubuntu and SUSE
> packaging: the Horizon team would love to have your opinion on this (it
> came up during our weekly meeting).

I was somehow not CC'ed although I'm the SUSE packager for OpenStack.
In my opinion a) is the option we prefer, we're actually removing and
ignoring the .mo files from git and (re-) build them as part of
packaging. Using the git-maintained build results would be a
distribution packaging policy violation for us.

Whether it needs to be done before Juno or after: I personally don't
care either way, there are much more serious issues in Juno than
this..


Greetings,
Dirk

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

Re: [openstack-dev] [all] icehouse failure rates are somewhat catastrophic - who is actually maintaining it?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 07/10/14 22:25, Dirk Müller wrote:
> 2014-10-02 14:19 GMT+02:00 Duncan Thomas
> :
> 
> Hi,
> 
>> What is actually needed is those who rely on the stable
>> branch(es) existence need to step forward and dedicate resources
>> to it. Putting the work on people not interested is just the same
>> as killing them off, except slower, messier and creating more
>> anger and otehr community fallout along the way.
> 
> I'm paid by one of those distros that are interested in stable
> branch maintenance but have no idea what needs to be done other
> than saying "I'm interested in helping out". I've been proposing
> patches to backport every once in a while already and being
> frustrated that it takes weeks if not months for someone to review
> them and potentially merge. What are the queries that people are
> supposed to look at ? How can I help in pushing patches or look for
> gating failures *specific* to stable/ branches?

First, check out [1]. Also please subscribe to openstack-stable-maint@
mailing list [2]. You can start helping the team by applying the rules
from [1] to existing backport reviews. Once team members see your work
for a while, you will be able to join the team and get +2 vote for
stable branches.

Welcome!

[1]: https://wiki.openstack.org/wiki/StableBranch
[2]:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint

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

iQEcBAEBCgAGBQJUNE5dAAoJEC5aWaUY1u57cpoH/2Y8qTTRg1IBWBB7O+VnezWc
LEHEi1ydXwpu75kPMI5YWlPx4YWSFKRD6DOd30bUgSsoW7rI/d1LtelfvE3ubdS3
8D6qt1Rvlw15xpX8GbVaABlezxeQufufCMp0wioV0OkrlryyF0dvE1iopwnIjnAi
hD8rfbAO8LUW8ra0hkteRFac3oPVzGBGhWu67ijxvec3Oh7p7gV4AlMj2tm2n5JE
fhzxPLnPTqVa8zqJYdZBIr7nHfZtvx9bxGMPAqJP40e15x/toaVJquBEM43HaVs+
2YX5sGWrxmZaP6w8TJRcbBqny0hfK8n3IWgY6d8NVa4FqgwibdHY22hi7jnMuoU=
=hLF9
-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] TC candidacy

confirmed

On 07/10/14 04:21 PM, Russell Bryant wrote:
> Hello, everyone!
> 
> I would like to run for re-election on the Technical Committee. I have
> been an elected member of the TC since it was created in the Fall of
> 2012 [1]. I have been contributing to OpenStack since late 2011 (commits
> [2] reviews [3]). My most substantial contributions have been to Nova,
> where I also served as the PTL for the Havana and Icehouse releases. For
> further details on my background, see openhub [4] or linkedin [5].
> 
> I have been a proactive member of the TC.  I take my broad experience
> with the project and work to turn it into change that puts us in a
> better position for the future.  Some specific examples of actions I’ve
> taken may help demonstrate this.
> 
> Over the last cycle it became clear that the TC could do a better job at
> communicating what we’re up to to the broader community.  I helped
> launch an ongoing effort to blog about TC activities.  I wrote the first
> [9] and third [10] posts of this series. We now intend to rotate the
> authorship of these posts through a group of willing TC members.
> 
> I’ve become deeply familiar with the history of Neutron vs. nova-network
> through my work with the Nova project.  During my second term as the
> Nova PTL, we unfortunately reached a point where we had to unfreeze
> development on nova-network [11].  I wanted to find ways to help improve
> the current situation and help prevent it from happening again.  I
> identified policy that could be added (must have explicit deprecation
> and migration plan in place before graduation) [12] for the future.  To
> help with the current situation, I proposed that we kick off a round of
> project reviews where we review all existing projects against our
> incubation and graduation requirements [13].  This process resulted in a
> gap analysis and plans for filling those gaps for Neutron [14], Trove,
> Ceilometer, Horizon, Glance, and Heat.  We are now much closer to being
> able to deprecate nova-network than we were 6 months ago thanks to some
> very hard work by the Neutron team.  I think these reviews were very
> productive and I hope to help continue this process with the TC going
> forward.
> 
> The TC has the critical role to evolve and scale our structure and
> processes to ensure the ongoing health of our development community.
> We’ve worked through important changes in every cycle so far.  From
> recent discussions it is quite clear that it is time for another round
> of big changes to how we organize our teams and projects. The TC itself
> has even become a bottleneck in some cases.  I see resolving these
> issues as a top priority for the TC over the next release cycle.
> 
> There are far too many things wrapped up in the incubation and
> integration statuses.  They communicate different things to different
> audiences.  This overload has led to a lot of conflict.  It’s a high
> priority for me to ensure that with whatever changes we make, we value
> an inclusive community that lets projects doing good work be a part of
> OpenStack.  We need to rework the organization such that what we’re
> communicating is the most useful information for each audience.  At the
> same time, we need allow this growth in such a way that it doesn’t
> provide unbearable strain on horizontal project resources like
> documentation, infrastructure, or release management.  The incubated and
> integrated statuses are not doing the job, but I’m confident that we can
> work through our next evolution, and I would like to be a part of
> ensuring that happens.
> 
> Thank you all for your consideration. It’s an honor and a pleasure to
> work with you. If there’s anything you would like to discuss, please
> feel free to reach out to me.
> 
> 
> Below you will find my answers to the provided questions [6].
> 
> *** Topic: OpenStack Mission
> 
> How do you feel the technical community is doing in meeting the
> OpenStack Mission?
> 
> To recap, the mission statement is “to produce the ubiquitous Open
> Source Cloud Computing platform that will meet the needs of public and
> private clouds regardless of size, by being simple to implement and
> massively scalable.”
> 
> “ubiquitous” - I think the part we’re doing great here.  OpenStack is
> growing like crazy and is being used all over the place.  The list of
> supporting companies [7] is impressive.  The number and diversity of our
> contributors is even more impressive.  With that said, we shouldn’t get
> comfortable.  There is a lot more to go.
> 
> “public and private clouds” - I think we do a nice job working to
> support both of these use cases.
> 
> “regardless of size”, “massively scalable” - This one probably depends
> on who you ask.  :-)  Our scalability depends on the project.  In some
> areas we’re doing great.  In all areas, we have more improvements to
> make.  I think our biggest failure here has been how well we communicate
> what to expect to the rest of the community.

Re: [openstack-dev] TC candidacy

confirmed

On 07/10/14 04:30 PM, Doug Hellmann wrote:
> I am announcing my candidacy for a position on the OpenStack Technical
> Committee.
> 
> I am currently employed by HP to work upstream on OpenStack. I started
> contributing in 2012, not long after joining DreamHost. I am one of
> the founding members of the Ceilometer project, and a core reviewer
> for the requirements and unified command line interface projects. I am
> also part of the team working on the Python 3 transition, and have
> contributed to several of the infrastructure projects. Kilo will be my
> third term serving as PTL for the Oslo project, and I have served on
> the Technical Committee for the last year. In addition to my technical
> contributions, I helped to found and still help to organize the
> OpenStack meetup group in Atlanta, Georgia.
> 
> I've included the answers to the formally posed election questions
> below, but please follow up here with any other questions you might
> have for me.
> 
> The OpenStack community is the most exciting and welcoming group I
> have interacted with in more than 20 years of contributing to open
> source projects. I'm looking forward to continuing to being a part
> of the community and serving the project.
> 
> Thank you,
> Doug
> 
> Review history: https://review.openstack.org/#/q/reviewer:2472,n,z
> Commit history: https://review.openstack.org/#/q/owner:2472,n,z
> Stackalytics: http://stackalytics.com/?user_id=doug-hellmann
> Foundation: http://www.openstack.org/community/members/profile/359
> OpenHUB: https://www.openhub.net/accounts/doughellmann
> Freenode: dhellmann
> Website: http://doughellmann.com
> 
> 
> 
> * Topic: OpenStack Mission
> *
> * How do you feel the technical community is doing in meeting the
> * OpenStack Mission?
> 
> I am amazed by what our community produces. We have some truly
> exceptional development teams building great software. We regularly
> add new components to the system, and our feature set is as diverse as
> the community. Our work is not perfect, but as we continue to refine
> it based on experience and input from users, we are continually
> improving the way we work and what we produce.
> 
> However, there are recurring themes in the user feedback after every
> release: We need to make OpenStack easier to operate, easier to use,
> and easier to debug. We are starting to build cross-project teams to
> work more directly on some of these areas, and it's important that we
> give priority to that work and consider usability and scalability as
> features.
> 
> * Topic: Technical Committee Mission
> *
> * How do you feel the technical committee is doing in meeting the
> * technical committee mission?
> 
> We're fulfilling most of the mission, but we can do better.
> 
> The Zaqar graduation discussion is a good example of an area where we
> need to rethink how we bring new project teams into OpenStack. There
> are several similar suggestions to drop our current incubation and
> integration process completely, and that is one option. Another is to
> set up the resources we would need to do an objective technical
> evaluation for projects. I favor a combination of those two ideas,
> evaluating projects on several criteria from the users' perspective,
> but deciding the "official" status of a team based on community
> considerations.
> 
> We have also recognized that we need some way to handle cross-project
> initiatives such as improving our logging to make debugging easier,
> but we do not yet have a formal structure in place to accomplish those
> goals. The way we set up working groups for those sorts of jobs is
> going to depend on the outcome of the bigger governance discussion,
> but I think they should be organized by the TC.
> 
> * Topic: Contributor Motivation
> *
> * How would you characterize the various facets of contributor
> * motivation?
> 
> I don't know if we have numbers, but my impression is that most of our
> contributions come from people employed at least in part to work on
> OpenStack. Their commitment to the project as a whole, outside of
> their area of specialty, varies for a lot of reasons. We want everyone
> to have a strong commitment to the whole project, but that's not
> always realistic, because it's not always up to the individual to
> decide how much time or effort they can put into working on OpenStack,
> or into a given area. That's perfectly normal and OK. We can, and do,
> welcome contributions from all sorts of people for all sorts of
> reasons.
> 
> * 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?
> 
> Growing so quickly is forcing us to think about how we organize our
> selves and make changes explicitly, and more rapidly, rather than
> allowing for a slower evolution.  We've had a lot of blog posts and
> mailing list threads talking about ways to handle the growth through
> governance model changes

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Sergey Lukjanov

Regarding to the Sahara, we could discuss it in the ML separately or you
could join the #openstack-sahara channel at freenode.

There is a big area of doing things inside and on top of Sahara.

thanks.

On Tue, Oct 7, 2014 at 11:41 AM, Adam Lawson  wrote:

> Is the OP looking to help patch bugs with an individual program or to use
> Openstack to deploy an interesting use case? The latter is how I
> interpreted the question.
>
>
> *Adam Lawson*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
> On Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas 
> wrote:
>
>> On 7 October 2014 19:01, Anita Kuno  wrote:
>> > On 10/07/2014 01:38 PM, Adam Young wrote:
>> >> On 10/06/2014 05:28 PM, Anita Kuno wrote:
>> >>> On 10/06/2014 04:11 PM, Adam Young wrote:
>>  I am looking to get someone to work on a Javascript based web client
>> to
>>  replace Horizon.
>>
>> >>> Can I just say that I think using new people looking to have work
>> >>> experience with OpenStack to further pet projects, without telling
>> them
>> >>> it is a pet project and not considered a project which others may
>> >>> consider OpenStack to be not the best approach for encouraging new
>> >>> people.
>>
>> I think writing a client / gui for openstack is one of the best single
>> projects you can do to get a good overview of the whole stack.
>>
>> >>> Not knocking your project, Adam, since I know nothing about it, and
>> this
>> >>> isn't the first time I have seen this happen. But I do believe that
>> >>> folks asking to help out with something are looking to gain
>> transferable
>> >>> skills so that they have something to offer a potential employeer who
>> is
>> >>> looking for work experience with OpenStack. That would be what I would
>> >>> be looking for anyway.
>>
>> >> No offense taken.  I think you are looking out for the interest of the
>> >> poster and people wityh similar interests.
>>
>> 
>>
>> >>  It would not be appropriate for
>> >> someone in Patricia's position to try and come in and get a bug fix
>> >> through.
>>
>> > Now on this point, I'm going to disagree, simply because I don't have
>> > enough information on what Patricia's position actually is. I can guess
>> > but until I hear from Patricia herself, I'm just guessing and I would
>> > much rather know. It was my desire to know more about Patricia's
>> > position that motivated my suggestion she join irc and perhaps ask a few
>> > questions, allowing others to ask questions of her.
>> >
>> > When interacting with other folks who enter under similar circumstances,
>> > my first question invariably is "What is your goal?". I truly hope
>> > Patricia has something better than "to get a good mark" because folks
>> > with that goal rarely interest me, but who knows. I haven't had the
>> > chance to ask.
>>
>> If you're doing a final year project and your highest goal isn't 'to
>> get a good mark', then you're doing yourself a serious disservice. You
>> can have all sorts of secondary goals, but by the point in your
>> academic career where you're doing your final year project, your main
>> goal is to prove you're learnt and can apply all of the skills that
>> your course has covered. This actually involves a very different
>> process to getting something done in the 'real world'.
>>
>> >>  That limits the number of projects available.
>> > Now here is where I would like to interact with program administrators
>> > at institutions such as Patricia's to ask them why a project? We have
>> > over 300 including stackforge, why task a student with starting their
>> > own, why not encourage them to learn our development process which then
>> > can enable them to work on any of the 300 in various stages of
>> development.
>>
>> Extremely difficult to get a decent academic project and therefore a
>> good mark out of an existing project that has had any substantial
>> amount of work done on it. Not impossible, but flicking through a pile
>> of old final year projects that got good marks shows that stand-alone
>> start-to-finish projects tend to get better marks. (I've looked into
>> this quite a bit)
>>
>>
>>
>>
>>
>> --
>> Duncan Thomas
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
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] ETSI NFV gap analysis [NFV]

2014-10-07 Thread Steve Gordon

- Original Message -
> From: "Alan Kavanagh" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> I believe pointing it to the NFV Wiki would be good and that way it can be
> discussed during one of the weekly meetings run by Steven et.al and match
> the list to what is being requested to what is identified in the wiki list
> as a good starting point.
> /Alan

Hi all,

I've uploaded the document here:


https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf

Many items are tracked (and in fact linked inline in the document itself) in 
the list that we have already compiled on the wiki, but there are certainly 
gaps over and above those as you work your way down the list.

Thanks,

Steve

> -Original Message-
> From: Sylvain Bauza [mailto:sba...@redhat.com]
> Sent: October-06-14 9:19 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] ETSI NFV gap analysis [NFV]
> 
> 
> Le 05/10/2014 09:22, MENDELSOHN, ITAI (ITAI) a écrit :
> > Team,
> >
> > Following my action item from last week  IRC.
> > It seems that the document is ready for submission by ETSI NFV team.
> > It was written in a liaison form as this is how they are used to operate.
> > They are wondering who should they send it to...
> > IMHO it seems a good idea that the NFV sub group will "receive" it in
> > behalf of the community.
> >
> > Thoughts?
> >
> > Itai
> 
> I don't know the legal conditions of the publication of this document, but I
> would assume it would be worth of interest within the whole OpenStack
> community so anyone could see what's missing and contribute to it.
> 
> 
> At least pointing the document to the NFV wiki page sounds important,
> provided this communication can be done this way (ie. no opt-in list for
> people looking at the doc)
> 
> -Sylvain
> 
> >
> > Sent from my iPhone
> > ___
> > 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
> 

-- 
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform

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

Re: [openstack-dev] Treating notifications as a contract

2014-10-07 Thread Sandy Walsh


>From: Chris Dent [chd...@redhat.com] Tuesday, October 07, 2014 12:07 PM
>
>On Wed, 3 Sep 2014, Sandy Walsh wrote:
>
>> Good goals. When Producer and Consumer know what to expect, things are
>> good ... "I know to find the Instance ID ". When the consumer
>> wants to deal with a notification as a generic object, things get tricky
>> ("find the instance ID in the payload", "What is the image type?", "Is
>> this an error notification?")
>>
>> Basically, how do we define the principle artifacts for each service and
>> grant the consumer easy/consistent access to them? (like the 7-W's above)
>>
>> I'd really like to find a way to solve that problem.
>>
>>> Is that a good summary? What did I leave out or get wrong?
>>
>> Great start! Let's keep it simple and do-able.
>
>Has there been any further thinking on these topics? Summit is soon
>and kilo specs are starting so I imagine more people than just me are
>hoping to get rolling on plans.
>
>If there is going to be a discussion at summit I hope people will be
>good about keeping some artifacts for those of us watching from afar.
>
>It seems to me that if the notifications ecosystem becomes
>sufficiently robust and resilient we ought to be able to achieve
>some interesting scale and distributed-ness opporunities throughout
>OpenStack, not just in telemetry/metering/eventing (choose your term
>of art).

Haven't had any time to get anything written down (pressing deadlines with 
StackTach.v3) but open to suggestions. Perhaps we should just add something to 
the olso.messaging etherpad to find time at the summit to talk about it?

-S


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

Re: [openstack-dev] [oslo] Meeting time

2014-10-07 Thread Ben Nemec

Any of the proposed times work for me.

-Ben

On 10/07/2014 02:01 PM, Roman Podoliaka wrote:
> Hi all,
> 
> Last Friday we decided to find a better time for the weekly team
> meeting. Keeping in mind that DST ends soon (October the 26th in
> Europe, November the 2nd in the US), I think, we can choose from:
> 
> - Mondays at 1600 UTC [1]: #openstack-meeting-alt, #openstack-meeting-3
> - Thursdays at 1600 UTC [2]: #openstack-meeting-3
> - Thursdays at 1700 UTC [3]: #openstack-meeting-3
> - Fridays at 1600 UTC (current time, may be ok when DST ends) [4]:
> #openstack-meeting-alt, #openstack-meeting-3
> 
> (assuming the information about meeting rooms availability provided
> here [0] is correct)
> 
> Basically, anything earlier than 1600 UTC will be too early for those
> who live in CA after November the 2nd. And 1700+ UTC is beer o'clock
> here in Europe :)
> 
> Alternatively, we could ask Infra  to add the meeting bot directly to
> #openstack-oslo channel and have the weekly meeting there on any day
> we like around 1600 UTC (#openstack-oslo is not really crowded, so it
> shouldn't be a problem to use it for a meeting once a week).
> 
> Please let me know what you think.
> 
> Thanks,
> Roman
> 
> [0] 
> https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics
> 
> [1] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=3&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [2] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [3] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=6&hour=17&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> [4] 
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=11&day=7&hour=16&min=0&sec=0&p1=367&p2=195&p3=179&p4=224
> 
> ___
> 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] Suggestions for students final year project

2014-10-07 Thread Patricia Ellis

Thank you all for your attention,

In answer to Anita, in a way my goal is to get a good mark as I have been
getting good marks so far. I had a project proposal of my own, a web app
for a friend of mine but my supervisor didn't think it good enough to get
me a good mark and she suggested I approach you. Final year projects don't
seem to be about showing off what we have learned over the last 3/4 years
rather to show off what we haven't learned at college. I started off my
degree from a very low foundation of knowledge about programming and found
I really liked the coding side of things so I switched to a software
development degree in second year. It is very difficult to get the balance
right when you realize how little you know about the subject, the more I
learn the bigger the field seems to be getting.
I will spend some time investigating the links you sent me.

On 7 October 2014 19:41, Adam Lawson  wrote:

> Is the OP looking to help patch bugs with an individual program or to use
> Openstack to deploy an interesting use case? The latter is how I
> interpreted the question.
>
>
> *Adam Lawson*
>
> AQORN, Inc.
> 427 North Tatnall Street
> Ste. 58461
> Wilmington, Delaware 19801-2230
> Toll-free: (844) 4-AQORN-NOW ext. 101
> International: +1 302-387-4660
> Direct: +1 916-246-2072
>
>
> On Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas 
> wrote:
>
>> On 7 October 2014 19:01, Anita Kuno  wrote:
>> > On 10/07/2014 01:38 PM, Adam Young wrote:
>> >> On 10/06/2014 05:28 PM, Anita Kuno wrote:
>> >>> On 10/06/2014 04:11 PM, Adam Young wrote:
>>  I am looking to get someone to work on a Javascript based web client
>> to
>>  replace Horizon.
>>
>> >>> Can I just say that I think using new people looking to have work
>> >>> experience with OpenStack to further pet projects, without telling
>> them
>> >>> it is a pet project and not considered a project which others may
>> >>> consider OpenStack to be not the best approach for encouraging new
>> >>> people.
>>
>> I think writing a client / gui for openstack is one of the best single
>> projects you can do to get a good overview of the whole stack.
>>
>> >>> Not knocking your project, Adam, since I know nothing about it, and
>> this
>> >>> isn't the first time I have seen this happen. But I do believe that
>> >>> folks asking to help out with something are looking to gain
>> transferable
>> >>> skills so that they have something to offer a potential employeer who
>> is
>> >>> looking for work experience with OpenStack. That would be what I would
>> >>> be looking for anyway.
>>
>> >> No offense taken.  I think you are looking out for the interest of the
>> >> poster and people wityh similar interests.
>>
>> 
>>
>> >>  It would not be appropriate for
>> >> someone in Patricia's position to try and come in and get a bug fix
>> >> through.
>>
>> > Now on this point, I'm going to disagree, simply because I don't have
>> > enough information on what Patricia's position actually is. I can guess
>> > but until I hear from Patricia herself, I'm just guessing and I would
>> > much rather know. It was my desire to know more about Patricia's
>> > position that motivated my suggestion she join irc and perhaps ask a few
>> > questions, allowing others to ask questions of her.
>> >
>> > When interacting with other folks who enter under similar circumstances,
>> > my first question invariably is "What is your goal?". I truly hope
>> > Patricia has something better than "to get a good mark" because folks
>> > with that goal rarely interest me, but who knows. I haven't had the
>> > chance to ask.
>>
>> If you're doing a final year project and your highest goal isn't 'to
>> get a good mark', then you're doing yourself a serious disservice. You
>> can have all sorts of secondary goals, but by the point in your
>> academic career where you're doing your final year project, your main
>> goal is to prove you're learnt and can apply all of the skills that
>> your course has covered. This actually involves a very different
>> process to getting something done in the 'real world'.
>>
>> >>  That limits the number of projects available.
>> > Now here is where I would like to interact with program administrators
>> > at institutions such as Patricia's to ask them why a project? We have
>> > over 300 including stackforge, why task a student with starting their
>> > own, why not encourage them to learn our development process which then
>> > can enable them to work on any of the 300 in various stages of
>> development.
>>
>> Extremely difficult to get a decent academic project and therefore a
>> good mark out of an existing project that has had any substantial
>> amount of work done on it. Not impossible, but flicking through a pile
>> of old final year projects that got good marks shows that stand-alone
>> start-to-finish projects tend to get better marks. (I've looked into
>> this quite a bit)
>>
>>
>>
>>
>>
>> --
>> Duncan Thomas
>>
>> ___
>>

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

2014-10-07 Thread Clint Byrum

Excerpts from Chris Jones's message of 2014-10-07 13:27:07 -0700:
> Hi
> 
> > On 7 Oct 2014, at 20:47, Clint Byrum  wrote:
> >> 
> >> I don't think it should import those files wholesale, IMO that's making 
> >> way too many assumptions about the similarity of the two builds.
> > Disagree on the grounds that the point of this is to deal with people
> > who already have images and want to update them. We're not trying to
> > enable people to deploy radically different OS's or anything like that.
> 
> My point is that we don't know what else is changing under the hood. 
> Switching OS is a bit extreme, but we don't know that they're not going to 
> pull in an OS upgrade at the same time and have everything change 
> substantially, or even just introduce one additional dependency which we 
> would destroy the uid/gid for.
> 

Ok, any time we can fail at build time is good, so merging is important. I 
agree now.

> >> I think this needs to be at least somewhat driven from the elements 
> >> themselves - they need to declare the users/groups they need and likely 
> >> offer a default UID/GID for each.
> >> The element you describe could consult the elements to determine which 
> >> users/groups need to be created, pull the values it needs from the 
> >> passwd/group files if they exist, or fall back on the offered static 
> >> defaults if not, then use normal tools to create the user/group (mainly so 
> >> we respect whatever libnss settings the operator has chosen).
> >> 
> > 
> > That is a lot of complexity for the case that we don't want people to
> > use (constantly carrying /etc/passwd and /etc/group forward).
> 
> As tchaypo pointed out on IRC, if we do this static route, we are laying down 
> a great big concrete slab of opinion in our images. I'm all for opinionated 
> software, but we need to give people an out, which means we probably want to 
> have a way for the suggested default UID/GIDs to be overridden, i.e. roughly 
> what I described. We can just use that override to inject the pre-existing 
> passwd/group values, if we so desire.
> 

Mmk. I think having an override is important, but I feel that we can do it
in a more straight forward manner. I may not have thought it all the way
through.

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

Re: [openstack-dev] Treating notifications as a contract

2014-10-07 Thread Sandy Walsh

>
>From: Sandy Walsh [sandy.wa...@rackspace.com] Tuesday, October 07, 2014 6:07 PM
>
>Haven't had any time to get anything written down (pressing deadlines with 
>StackTach.v3) but open to suggestions. Perhaps we should just add something to 
>the olso.messaging etherpad to find time at the summit to talk about it?
>
>-S

Actually, that's not really true.

The Monasca team has been playing with schema definitions for their wire
format (a variation on the kind of notification we ultimately want). And
http://apiary.io/ is introducing support for structure schemas soon. Perhaps
we can start with some schema proposals there? JSON-Schema based?

For green-field installations, CADF is a possibility, but for already
established services we will to document what's in place first.

At some point we'll need a cross-project effort to identify all the important
characteristics of the various services.

Also, we've been finding no end of problems with the wild-west payload
section.

For example, look at all the different places we have to look to find the
instance UUID from Nova. 

https://github.com/SandyWalsh/stacktach-sandbox/blob/verifier/winchester/event_definitions.yaml#L12-L17

Likewise for project_id, flavor_id, deleted_at, etc.

Definitely need a solution to this. 
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Suggestions for students final year project

2014-10-07 Thread Anita Kuno

On 10/07/2014 05:21 PM, Patricia Ellis wrote:
> Thank you all for your attention,
> 
> In answer to Anita, in a way my goal is to get a good mark as I have been
> getting good marks so far.
Great. Thanks for getting back to us.

Out of the replies thus far Duncan seems to have the most experience
(that has been mentioned) in getting a good mark. He tends to hang out
in the #openstack-cinder channel and, lucky you, is in your timezone. I
would suggest having a follow up conversation with him to maximize your
effectiveness at getting a good mark.

I'm still interested in having that conversation with you, Adam, since I
think you have some thoughts I would like to support.

Thanks Patricia,
Anita.

> I had a project proposal of my own, a web app
> for a friend of mine but my supervisor didn't think it good enough to get
> me a good mark and she suggested I approach you. Final year projects don't
> seem to be about showing off what we have learned over the last 3/4 years
> rather to show off what we haven't learned at college. I started off my
> degree from a very low foundation of knowledge about programming and found
> I really liked the coding side of things so I switched to a software
> development degree in second year. It is very difficult to get the balance
> right when you realize how little you know about the subject, the more I
> learn the bigger the field seems to be getting.
> I will spend some time investigating the links you sent me.
> 
> On 7 October 2014 19:41, Adam Lawson  wrote:
> 
>> Is the OP looking to help patch bugs with an individual program or to use
>> Openstack to deploy an interesting use case? The latter is how I
>> interpreted the question.
>>
>>
>> *Adam Lawson*
>>
>> AQORN, Inc.
>> 427 North Tatnall Street
>> Ste. 58461
>> Wilmington, Delaware 19801-2230
>> Toll-free: (844) 4-AQORN-NOW ext. 101
>> International: +1 302-387-4660
>> Direct: +1 916-246-2072
>>
>>
>> On Tue, Oct 7, 2014 at 11:24 AM, Duncan Thomas 
>> wrote:
>>
>>> On 7 October 2014 19:01, Anita Kuno  wrote:
 On 10/07/2014 01:38 PM, Adam Young wrote:
> On 10/06/2014 05:28 PM, Anita Kuno wrote:
>> On 10/06/2014 04:11 PM, Adam Young wrote:
>>> I am looking to get someone to work on a Javascript based web client
>>> to
>>> replace Horizon.
>>>
>> Can I just say that I think using new people looking to have work
>> experience with OpenStack to further pet projects, without telling
>>> them
>> it is a pet project and not considered a project which others may
>> consider OpenStack to be not the best approach for encouraging new
>> people.
>>>
>>> I think writing a client / gui for openstack is one of the best single
>>> projects you can do to get a good overview of the whole stack.
>>>
>> Not knocking your project, Adam, since I know nothing about it, and
>>> this
>> isn't the first time I have seen this happen. But I do believe that
>> folks asking to help out with something are looking to gain
>>> transferable
>> skills so that they have something to offer a potential employeer who
>>> is
>> looking for work experience with OpenStack. That would be what I would
>> be looking for anyway.
>>>
> No offense taken.  I think you are looking out for the interest of the
> poster and people wityh similar interests.
>>>
>>> 
>>>
>  It would not be appropriate for
> someone in Patricia's position to try and come in and get a bug fix
> through.
>>>
 Now on this point, I'm going to disagree, simply because I don't have
 enough information on what Patricia's position actually is. I can guess
 but until I hear from Patricia herself, I'm just guessing and I would
 much rather know. It was my desire to know more about Patricia's
 position that motivated my suggestion she join irc and perhaps ask a few
 questions, allowing others to ask questions of her.

 When interacting with other folks who enter under similar circumstances,
 my first question invariably is "What is your goal?". I truly hope
 Patricia has something better than "to get a good mark" because folks
 with that goal rarely interest me, but who knows. I haven't had the
 chance to ask.
>>>
>>> If you're doing a final year project and your highest goal isn't 'to
>>> get a good mark', then you're doing yourself a serious disservice. You
>>> can have all sorts of secondary goals, but by the point in your
>>> academic career where you're doing your final year project, your main
>>> goal is to prove you're learnt and can apply all of the skills that
>>> your course has covered. This actually involves a very different
>>> process to getting something done in the 'real world'.
>>>
>  That limits the number of projects available.
 Now here is where I would like to interact with program administrators
 at institutions such as Patricia's to ask them why a project? We have
 over 300 including stackforge, why task a student with starting their

[openstack-dev] cross-project liaison list