Re: [openstack-dev] [all] the trouble with names

[Chris Dent]

On Fri, 5 Feb 2016, Sean Dague wrote:


I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).


We should revisit this ^ issue at some point because honestly if people
can't spend the time and energy to reach consensus, we're screwed and
we're going to continue to look like a giant enterprisey boondoggle
rather than a legitimate and useful "Ubiquitous Open Source Cloud
Platform".

But fine:


I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.


1. service type as described in option 2
2. managed by the api-wg with appeal to the TC
3. be limited to those services that (wish to/need to/should) be present
   in the service catalog

As discussed elsewhere 3 is a feature not a bug. We should endeavor
to keep the service catalog clean, tidy, and limited as a control on
OpenStack itself is clean, tidy and limited.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Anita Kuno]

On 02/05/2016 02:41 PM, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
>> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
>> wrote:
>>
>>> So, is Poppy "open core"?
>>>
>>
>> It doesn't follow the 'spirit' of open core, but it does have some of the
>> characteristics, in that the open code is not all that useful, or maybe
>> even testable, without the commercial component(s) (at this time).
>>
>> So while Poppy may not fully qualify for the open core label, it still
>> fails some of the tests that we want to see, such as a usable open source
>> implementation.
>>
>> dt
>>
> 
> Testability is certainly an issue. There are ways to deal with the
> limitations, though. Is it any different from the other third-party
> CI we support for hardware drivers? Maybe it means no project wants
> to rely on Poppy because there's no way to set up integration tests.
> That's OK. We have other projects that don't have dependencies.
> 
> I'm not comfortable separating the intent aspect of the definition
> of "open core" from the effect. We set rules for the community to
> codify the culture and to discourage bad behavior. Nothing the Poppy
> team has done qualifies as bad behavior. What is the point of
> penalizing them with a strict interpretation of a rule meant to
> address a different problem?
> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
I think we create problems for ourselves if we start equating the use of
the word no with punishment or penalty.

Sometimes no is a response that is chosen by one party for reasons
having nothing to do with punishment or penalty.

I think the two are separate.

Thank you,
Anita.

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Cody A.W. Somerville]

There are a lot of good questions and points being raised in this thread
but I think it might be appropriate to say we've opened a can of worms. As
mentioned by Doug there is a rather specific case[1] being considered that
I think provides some important context and framing.

It is clear that there are some that feel Poppy[2] should not be an
official OpenStack project. Deciding what is and what isn't an OpenStack
project is important for a number of reasons including protection of the
brand/identity of the project and the community; being faithful to our
principles; and logistical/resource constraints. It is a complicated and
nuanced topic with many considerations as evidenced by the many
conversations and opinions raised as part of the transition to the "big
tent model". I'll agree with Anita that it is a remarkable point of
strength that we've been able to communicate and find the consensus that we
have on these subjects when it is clear from even this short thread that
there is such a rich diversity of concerns, motivations, and agendas.

I'd like to suggest we tightly scope this discussion and subsequent
decision to Poppy exclusively. The reason for this is two fold. The first
is so that a timely resolution and answer can be provided to the Poppy
team. The second is that I think once we've answered the specific questions
and concerns about Poppy (some of which I believe are novel in nature)
we'll be in a better position to then inductively reason about the problem
and derive the more generalized rule or principle that I think Thierry was
hoping to establish.

In that vein, I'll try to summarize the questions or concerns I've seen
raised here and in the TC meeting[3] - apologies if I've missed any:

Poppy is an OpenStack project designed to make CDN services easier to
consume with a generic vendor-neutral API[4]. The concern is that it only
has support for commercial CDN service providers. It does not have support
for a CDN service that is Open Source.

 1. Is Poppy "open core"[5] or violate OpenStack's 'Four Opens'[6]?
 2. Do we have a requirement that the primary component/backend (or at
least one of the components/backends) driven/abstracted/orchestrated by a
project (directly or via driver/plugin/et al) be considered Open Source? If
yes, is there room for an exception when one simply doesn't exist? Is there
special consideration for "services" (ie. think GPL vs. AGPL)?
 3. Does a project that only enables the use of commercial
services/projects belong in OpenStack?
 4. Does Poppy violate existing requirements around testing/CI[7][8]?
 5. Does dependency on Casandra make Poppy non-free?
 6. Does a project that only enables the use of non-OpenStack
services/projects belong in OpenStack?

Some additional facts that have been pointed out include:

 - It currently only supports Akamai - which makes sense to be the first
provider, Akamai is the CDN provider for Rackspace[9] and the project is
mostly developed by Rackspace[10] - but implementation is underway for
Fastly, Amazon CloudFront, and MaxCDN[11].
 - It currently only supports Rackspace DNS but support for Designate is
planned[11] (only a stub exists in tree currently).

I'm going to ponder the above and I'll respond with my thoughts.

As for the following, they are all important and deserve deliberation but
I'd respectfully suggest we table them for another day - or at least
separately - so they get the attention and consideration they deserve:

 a) definitions for production-grade or scalable;
 b) new sets of requirements or standards for official projects, such as
the former;
 c) new requirements or conventions around feature parity or priority
between plugins/drivers/et al for Open Source vs. proprietary components;
 d) changing conventions around hosting of non-official projects;
 e) changing requirements around testing/CI;
 f) deciding anything already part of OpenStack isn't open enough or
unsuitable to be an OpenStack project; or
 g) material change or extension to the shared or common understanding of
"Open Core" in relation to deciding if Poppy is or is not open core.

[1] https://review.openstack.org/#/c/273756/
[2] http://www.poppycdn.org/
[3] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.html
[4] https://wiki.openstack.org/wiki/Poppy
[5] https://en.wikipedia.org/wiki/Open_core
[6] https://wiki.openstack.org/wiki/Open OR
https://governance.openstack.org/reference/opens.html
[7]
https://governance.openstack.org/reference/project-testing-interface.html
[8] Additional requirements exist such as must not install non-free
software in our hosted CI.
[9] https://www.rackspace.com/cloud/cdn-content-delivery-network
[10]
http://stackalytics.com/?project_type=all=all=poppy=commits
[11] https://github.com/openstack/poppy#features


Best regards,

Cody

-- 
Cody A.W. Somerville
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Pavel Bondar]

On 05.02.2016 12:28, Salvatore Orlando wrote:
>
>
> On 5 February 2016 at 04:12, Armando M.  > wrote:
>
>
>
> On 4 February 2016 at 08:22, John Belamaric
> > wrote:
>
>
> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin
> > wrote:
> >
> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar
> > wrote:
> >> I am trying to bring more attention to [1] to make final
> decision on
> >> approach to use.
> >> There are a few point that are not 100% clear for me at
> this point.
> >>
> >> 1) Do we plan to switch all current clouds to pluggable ipam
> >> implementation in Mitaka?
> >
> > I think our plan originally was only to deprecate the
> non-pluggable
> > implementation in Mitaka and remove it in Newton.  However,
> this is
> > worth some more consideration.  The pluggable version of the
> reference
> > implementation should, in theory, be at parity with the current
> > non-pluggable implementation.  We've tested it before and shown
> > parity.  What we're missing is regular testing in the gate
> to ensure
> > it continues this way.
> >
>
> Yes, it certainly should be at parity, and gate testing to
> ensure it would be best.
>
> >> yes -->
> >> Then data migration can be done as alembic_migration and it
> is what
> >> currently implemented in [2] PS54.
> >> In this case during upgrade from Liberty to Mitaka all
> users are
> >> unconditionally switched to reference ipam driver
> >> from built-in ipam implementation.
> >> If operator wants to continue using build-in ipam
> implementation it can
> >> manually turn off ipam_driver in neutron.conf
> >> immediately after upgrade (data is not deleted from old
> tables).
> >
> > This has a certain appeal to it.  I think the migration will be
> > straight-forward since the table structure doesn't really
> change much.
> > Doing this as an alembic migration would be the easiest from an
> > upgrade point of view because it fits seamlessly in to our
> current
> > upgrade strategy.
> >
> > If we go this way, we should get this in soon so that we can
> get the
> > gate and others running with this code for the remainder of
> the cycle.
> >
>
> If we do this, and the operator reverts back to the
> non-pluggable version,
> then we will leave stale records in the new IPAM tables. At
> the very least,
> we would need a way to clean those up and to migrate at a
> later time.
>
> >> no -->
> >> Operator is free to choose whether it will switch to
> pluggable ipam
> >> implementation
> >> and when. And it leads to no automatic data migration.
> >> In this case operator is supplied with script for migration
> to pluggable
> >> ipam (and probably from pluggable ipam),
> >> which can be executed by operator during upgrade or at any
> point after
> >> upgrade is done.
> >> I was testing this approach in [2] PS53 (have unresolved
> issues in it
> >> for now).
> >
> > If there is some risk in changing over then this should still be
> > considered.  But, the more I think about it, the more I
> think that we
> > should just make the switch seamlessly for the operator and
> be done
> > with it.  This approach puts a certain burden on the operator to
> > choose when to do the migration and go through the steps
> manually to
> > do it.  And, since our intention is to deprecate and remove the
> > non-pluggable implementation, it is inevitable that they
> will have to
> > eventually switch anyway.
> >
> > This also makes testing much more difficult.  If we go this
> route, we
> > really should be testing both equally.  Does this mean that
> we need to
> > set up a whole new job to run the pluggable implementation
> along side
> > the old implementation?  This kind of feels like a nightmare
> to me.
> > What do you think?
> >
>
> Originally (as I mentioned in the meeting), I was thinking
> that we should not automatically migrate. However, I see the
> appeal of your arguments. Seamless is best, of course. But if
> we offer going back to non-pluggable, (which I think we need
> to at 

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

[Jay Pipes]

On 02/05/2016 09:58 AM, Sam Yaple wrote:

Since Nova has no backup mechanism this is clearly a gap and that was the issue
Ekko wants to solve.


Nova has had backups for a long time:

http://developer.openstack.org/api-ref-compute-v2.1.html#createBackup

Best,
-jay

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

[openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Morgan Fainberg]

Looking over the state [and relatively untested nature] of the Keystone EC2
API and S3Token APIs, I want to propose deprecating these mechanisms of
auth within Keystone at this time.

These systems have been historically poorly tested and supported and have
remained broken / incompatible for long periods at a time. With the move
that the EC2-API team is taking the code from nova out-of-tree, I would
like to propose that the auth mechanisms are also moved out of tree and
into the purview of the team focused on providing a solid EC2 compatibility
layer for OpenStack.

This will allow the EC2-API team to better ensure the long term viability
and compatibility of the required auth systems and can free this all from
the requirement to propose code to keystone to handle forward momentum as
required to support future/new signature versions and movement within the
libraries that rely on clear AWS compatibility.

This should ideally be moved to something standalone that can handle the
translation of EC2 or S3Token Auth to native Keystone api calls.

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

[openstack-dev] [Docs] Changes for OpenStack API guides

[Smigiel, Dariusz]

Hello Anne,
I'm working on "moving to Keystone v3 API" spec for Neutron [1].
HenryG mentioned, that in next release or so, there will be change how to 
describe changes connected to API [2].
In spec I'm mentioning, that some changes are required to Networking API v2 
[3], so would like to know, how it supposed to be handled.

If you could point me to some place where I can find extra info about changes, 
It would be very helpful.

Thanks,
Dariusz (dasm) Smigiel

[1] https://review.openstack.org/#/c/257362/
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
[3] http://developer.openstack.org/api-ref-networking-v2.html

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

Re: [openstack-dev] [QA][Neutron] IPv6 related intermittent test failures

[Armando M.]

On 3 February 2016 at 18:49, Armando M.  wrote:

>
>
> On 3 February 2016 at 04:28, Sean Dague  wrote:
>
>> On 02/02/2016 10:03 PM, Matthew Treinish wrote:
>> > On Tue, Feb 02, 2016 at 05:09:47PM -0800, Armando M. wrote:
>> >> Folks,
>> >>
>> >> We have some IPv6 related bugs [1,2,3] that have been lingering for
>> some
>> >> time now. They have been hurting the gate (e.g. [4] the most recent
>> >> offending failure) and since it looks like they have been without
>> owners
>> >> nor a plan of action for some time, I made the hard decision of
>> skipping
>> >> them [5] ahead of the busy times ahead.
>> >
>> > So TBH I don't think the failure rate for these tests are really at a
>> point
>> > necessitating a skip:
>> >
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_multi_prefix_slaac
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_dhcp6_stateless_from_os
>> >
>> http://status.openstack.org/openstack-health/#/test/tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
>> >
>> > (also just a cool side-note, you can see the very obvious performance
>> regression
>> > caused by the keystonemiddleware release and when we excluded that
>> version in
>> > requirements)
>> >
>> > Well, test_dualnet_dhcp6_stateless_from_os is kinda there with a ~10%
>> failure
>> > rate, but the other 2 really aren't. I normally would be -1 on the skip
>> patch
>> > because of that. We try to save the skips for cases where the bugs are
>> really
>> > severe and preventing productivity at a large scale.
>> >
>> > But, in this case these ipv6 tests are kinda of out of place in
>> tempest. Having
>> > all the permutations of possible ip allocation configurations always
>> seemed a
>> > bit too heavy handed. These tests are also consistently in the top 10
>> slowest
>> > for a run. We really should have trimmed down this set a while ago so
>> we're only
>> > have a single case in tempest. Neutron should own the other possible
>> > configurations as an in-tree test.
>> >
>> > Brian Haley has a patch up from Dec. that was trying to clean it up:
>> >
>> > https://review.openstack.org/#/c/239868/
>> >
>> > We probably should revisit that soon, since quite clearly no one is
>> looking at
>> > these right now.
>>
>> We definitely shouldn't be running all the IPv6 tests.
>>
>> But I also think the assumption that the failure rate is low is not a
>> valid reason to keep a test. Unreliable tests that don't have anyone
>> looking into them should be deleted. They are providing negative value.
>> Because people just recheck past them even if their code made the race
>> worse. So any legitimate issues they are exposing are being ignored.
>>
>> If the neutron PTL wants tests pulled, we should just do it.
>>
>>
> Thanks for the support! Having said, I think it's important to make a
> judgement call on a case by case basis, because removing tests blindly
> might as well backfire.
>
> In this specific instance and all things considered, merging [2] (or even
> better [1]) feel like a net gain.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/239868/
> [2] https://review.openstack.org/#/c/275457/
>
>

Btw I did respin [1], because I am still seeing intermittent failures.

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

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Russell Bryant]

On 02/05/2016 10:36 AM, Neil Jerram wrote:
> As some others have said, I see the current discussion as being about
> the chain of accountability, from a stadium project, through Neutron, up
> to the OpenStack TC and board.  IIUC, Armando and other cores feel that
> there is a gap there - because they can't reasonably understand and
> vouch for all the stadium projects to the same standard they can for
> core Neutron.  Plus it seems (from the current
> https://review.openstack.org/#/c/275888/9 text) that there is a desire
> for strong core team overlap between openstack/neutron and all Neutron
> stadium projects.
> 
> As the lead of networking-calico, I think it's a reasonable call to say
> that networking-calico (and similar projects) should therefore be
> OpenStack big tent projects, rather than Neutron stadium, and hence the
> reviews I've just left.

Thanks, Neil.  You've summarized this well.  A more clear and accurate
chain of accountability is indeed what we're trying to get to here.

-- 
Russell Bryant

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

Re: [openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

[Kyle Mestery]

On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric  wrote:
> Hi all,
>
> Back in November, there was a discussion [1] on the mailing list around 
> release:independent projects, which was wrapped up by Thierry in [2]. 
> However, I have a couple lingering questions that have come up.
>
> In networking-infoblox, we have a 1.0.0 version of our driver that we 
> released a few months ago, and it is maintained in a the stable/liberty 
> branch. We just released 2.0.0 out of master, but 2.0.0 is compatible with 
> Liberty and Mitaka. So, from a branching perspective, is it permissible to 
> push all the 2.0.0 changes into stable/liberty? Those would be largely 
> functional changes, not simple bug fixes. If not, should we even *have* a 
> stable/liberty branch?
>
If you're in the Neutron Stadium, and thus following OpenStack stable
backport rules, you cannot backport functional features like you want.
If you remove yourself from the stadium, you don't have that issue and
can backport whatever you want to whatever branch you want. This is
why for some vendor networking sub-projects it may make more sense to
be outside the stadium, because it would align with how you want to do
your own releases.

> The primary reason this is important is to ensure that users and distributors 
> pull the correct version of the driver. The 1.0.0 version is pretty limited 
> and we definitely want the 2.0.0 to be the one packaged with Liberty 
> distributions. So, ideally we would be able to push all the 2.0.0 code into 
> stable/liberty since it is completely compatible - that would make it simple 
> for distributors to get the right driver.
>
> John
>
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

[John Belamaric]

Hi all,

Back in November, there was a discussion [1] on the mailing list around 
release:independent projects, which was wrapped up by Thierry in [2]. However, 
I have a couple lingering questions that have come up.

In networking-infoblox, we have a 1.0.0 version of our driver that we released 
a few months ago, and it is maintained in a the stable/liberty branch. We just 
released 2.0.0 out of master, but 2.0.0 is compatible with Liberty and Mitaka. 
So, from a branching perspective, is it permissible to push all the 2.0.0 
changes into stable/liberty? Those would be largely functional changes, not 
simple bug fixes. If not, should we even *have* a stable/liberty branch? 

The primary reason this is important is to ensure that users and distributors 
pull the correct version of the driver. The 1.0.0 version is pretty limited and 
we definitely want the 2.0.0 to be the one packaged with Liberty distributions. 
So, ideally we would be able to push all the 2.0.0 code into stable/liberty 
since it is completely compatible - that would make it simple for distributors 
to get the right driver.

John


[1] 
http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Eichberger, German]

+1

From: Bertrand LALLAU 
>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, February 5, 2016 at 12:26 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
Octavia Core

+1

On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley 
> wrote:
+1

Doug


> On Feb 4, 2016, at 7:06 PM, Brandon Logan 
> > wrote:
>
> +1
>
>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
>> +1 from me!
>> 
>> From: Michael Johnson >
>> Sent: Thursday, February 4, 2016 7:03 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
>> Octavia Core
>>
>> Octavia Team,
>>
>> I would like to nominate Stephen Balukoff as a core reviewer for the
>> OpenStack Octavia project.  His contributions[1] are in line with
>> other cores and he has been an active member of our community.
>>
>> Octavia cores please vote by replying to this e-mail.
>>
>> Michael
>>
>> [1] http://stackalytics.com/report/contribution/octavia/90
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [Docs] Changes for OpenStack API guides

[Anne Gentle]

Hi --
Here's some specs for you to peruse to get a lot of background, and the
blog post and -dev mailing list post that went out. You can also ask me
directly, annegentle on IRC or through email. It's a lot and only two-three
people are working on this effort centrally with the rest of the work
across all projects.

http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
http://www.openstack.org/blog/2016/01/whats-next-for-application-developer-guides/

http://specs.openstack.org/openstack/docs-specs/specs/mitaka/app-guides-mitaka-vision.html
http://specs.openstack.org/openstack/docs-specs/specs/liberty/api-site.html

The latest progress is in these reviews:
Run a virtual server to serve REST API: https://review.openstack.org/276484
Build scripts to copy Swagger to developer.openstack.org:
https://review.openstack.org/#/c/269809/
Migration script to make Swagger from current WADL:
https://review.openstack.org/#/c/270819/

In January I sent emails directly to all the API liaisons from
http://specs.openstack.org/openstack/api-wg/liaisons.html so sounds like
the word is getting out! Thanks for asking.

Anne


On Fri, Feb 5, 2016 at 9:50 AM, Smigiel, Dariusz 
wrote:

> Hello Anne,
>
> I’m working on “moving to Keystone v3 API” spec for Neutron [1].
>
> HenryG mentioned, that in next release or so, there will be change how to
> describe changes connected to API [2].
>
> In spec I’m mentioning, that some changes are required to Networking API
> v2 [3], so would like to know, how it supposed to be handled.
>
>
>
> If you could point me to some place where I can find extra info about
> changes, It would be very helpful.
>
>
>
> Thanks,
>
> Dariusz (dasm) Smigiel
>
>
>
> [1] https://review.openstack.org/#/c/257362/
>
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
>
> [3] http://developer.openstack.org/api-ref-networking-v2.html
>
>
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Neil Jerram]

On 05/02/16 16:31, Pavel Bondar wrote:
> On 05.02.2016 12:28, Salvatore Orlando wrote:
>>
>>
>> On 5 February 2016 at 04:12, Armando M. > > wrote:
>>
>>
>>
>> On 4 February 2016 at 08:22, John Belamaric
>> <jbelama...@infoblox.com> wrote:
>>
>>
>> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > > wrote:
>> >
>> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar > > wrote:
>> >> I am trying to bring more attention to [1] to make final decision 
>> on
>> >> approach to use.
>> >> There are a few point that are not 100% clear for me at this 
>> point.
>> >>
>> >> 1) Do we plan to switch all current clouds to pluggable ipam
>> >> implementation in Mitaka?

I possibly shouldn't comment at all, as I don't know the history, and 
wasn't around when the fundamental design decisions here were being made.

However, it seems a shame to me that this was done in a way that needs a 
DB migration at all.  (And I would have thought it possible for the 
default pluggable IPAM driver to use the same DB state as the 
non-pluggable IPAM backend, given that it is delivering the same 
semantics.)  Without that, I believe it should be a no-brainer to switch 
unconditionally to the pluggable IPAM backend.

Sorry if that's unhelpful...

Neil


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

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

[Sam Yaple]

On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes  wrote:

> On 02/05/2016 09:58 AM, Sam Yaple wrote:
>
>> Since Nova has no backup mechanism this is clearly a gap and that was the
>> issue
>> Ekko wants to solve.
>>
>
> Nova has had backups for a long time:
>
> http://developer.openstack.org/api-ref-compute-v2.1.html#createBackup
>
> I always forget to qualify that statement don't I? Nova does not have a
mechanism for _incremental_ backups. Nor does Nova have compression or
encryption because AFAIK that api only creates a snapshot. I would also
point out again that snapshots != backups, at least not for those who care
about backups.

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Russell Bryant]

On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> Even before OpenStack had a name, our "Four Opens" principles were
> created to define how we would operate as a community. The first open,
> "Open Source", added the following precision: "We do not produce 'open
> core' software". What does this mean in 2016 ?
> 
> Back in 2010 when OpenStack was started, this was a key difference with
> the other open source cloud platform (Eucalyptus) which was following an
> Open Core strategy with a crippled community edition and an "enterprise
> version". OpenStack was then the property of a single entity
> (Rackspace), so giving strong signals that we would never follow such a
> strategy was essential to form a real community.
> 
> Fast-forward today, the open source project is driven by a non-profit
> independent Foundation, which could not even do an "enterprise edition"
> if it wanted to. However, member companies build "enterprise products"
> on top of the Apache-licensed upstream project. And we have drivers that
> expose functionality in proprietary components. So what does it mean to
> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> time for us to refresh this.

Nice summary.  I agree that some clarification would be helpful given to
match our current reality.

> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open
> source effort. It should have a fully-functional, production-grade open
> source implementation. If you need proprietary software or a commercial
> entity to fully use the functionality of a project or getting serious
> about it, then it should not be accepted in OpenStack as an official
> project. It can still live as a non-official project and even be hosted
> under OpenStack infrastructure, but it should not be part of
> "OpenStack". That is how I would interpret "no open core" in OpenStack
> 2016.
> 
> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
> 
> Comments ?
> 

I agree with your take.  I'm not too worried about coming up with a
strict definition for what a reasonable open source backend is.  We can
throw in some desirable traits like you have done, and then leave it to
the TC to evaluate.  I think that's a reasonable part of the TC's job.

-- 
Russell Bryant

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

Re: [openstack-dev] [all] the trouble with names

[Neil Jerram]

On 05/02/16 13:50, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 7:13 AM, Neil Jerram  > wrote:
>
> On 04/02/16 11:40, Sean Dague wrote:
> > What options do we have?
> >
> > 1) Use the names we already have: nova, glance, swift, etc.
> >
> > Upside, collision problem is solved. Downside, you need a secret decoder
> > ring to figure out what project does what.
>
> This is my preference.  Yes, it means that there is an education hurdle
> for anyone new to OpenStack to overcome.  But once that is done, there
> is a concise and precise term that they and we can all use and
> understand.
>
>
> Have a look at the browser User-Agent headers and let me know how that
> has worked out for them:
>
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
>
> Two of those product/code names are lies for compatibility purposes.  We
> (OpenStack) should not be promoting that sort of nonsense on our users
> just to save us a little bit of inconvenience in the development process.

I'm not clear how that's a good analogy.  Is it?

> To add something positive to the discussion, we should remember how much
> of OpenStack consists of plugin-capable architecture, specifically so
> that out-of-tree components can be accommodated for whatever reason.
> The projects play the role of arbitrator of namespaces in the case of
> many back-end drivers.

Perhaps my response here is overly detailed, but it appears that you're 
making a quite detailed technical point.  So:

1. Actually, at least for Neutron ML2 drivers, Neutron does not provide 
namespace arbitration.  There is a setup.cfg entry point space with the 
name 'neutron.ml2.mechanism_drivers', and each 3rd party driver adds its 
name to that space.  But there is no explicit protocol here (i.e. where 
networking-calico would say 'Can I use the name calico?' and Neutron 
might answer 'Yes').  De facto we just hope that there will never be 
clashing names in a given deployment.

2. Note that the names used here are project or code names.  For example 
'calico', not 'OpenStack L3-only Networking'.

>  Having someone do this for OpenStack as a whole
> is a necessary part of having a community-wide namespace such as service
> types.

Yes, but that doesn't necessarily mean 'OpenStack Networking' rather 
than 'Neutron', I think.

Neil



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

Re: [openstack-dev] [Docs] Changes for OpenStack API guides

[Anne Gentle]

On Fri, Feb 5, 2016 at 9:50 AM, Smigiel, Dariusz 
wrote:

> Hello Anne,
>
> I’m working on “moving to Keystone v3 API” spec for Neutron [1].
>
> HenryG mentioned, that in next release or so, there will be change how to
> describe changes connected to API [2].
>
> In spec I’m mentioning, that some changes are required to Networking API
> v2 [3], so would like to know, how it supposed to be handled.
>
>
>
> If you could point me to some place where I can find extra info about
> changes, It would be very helpful.
>

Also, for small feature changes happening now, it's fine to simply update
the WADL file as the migrations will be ongoing. You can find neutron API
reference information here:
https://github.com/openstack/api-site/tree/master/api-ref/src/wadls/networking-api/src/wadl

which is published to
http://developer.openstack.org/api-ref-networking-v2.html and will continue
to be while we work on changes away from WADL.
Thanks,
Anne


>
>
> Thanks,
>
> Dariusz (dasm) Smigiel
>
>
>
> [1] https://review.openstack.org/#/c/257362/
>
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083670.html
>
> [3] http://developer.openstack.org/api-ref-networking-v2.html
>
>
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Dolph Mathews]

+1 this is a totally logical move, especially given that the current
implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg 
wrote:

> Looking over the state [and relatively untested nature] of the Keystone
> EC2 API and S3Token APIs, I want to propose deprecating these mechanisms of
> auth within Keystone at this time.
>
> These systems have been historically poorly tested and supported and have
> remained broken / incompatible for long periods at a time. With the move
> that the EC2-API team is taking the code from nova out-of-tree, I would
> like to propose that the auth mechanisms are also moved out of tree and
> into the purview of the team focused on providing a solid EC2 compatibility
> layer for OpenStack.
>
> This will allow the EC2-API team to better ensure the long term viability
> and compatibility of the required auth systems and can free this all from
> the requirement to propose code to keystone to handle forward momentum as
> required to support future/new signature versions and movement within the
> libraries that rely on clear AWS compatibility.
>
> This should ideally be moved to something standalone that can handle the
> translation of EC2 or S3Token Auth to native Keystone api calls.
>
> Thanks for reading,
> --Morgan
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] gate issues

[Hongbin Lu]

Corey,

Thanks for investigating the gate issues and summarizing it. It looks there are 
multiple problems to solve, and tickets were created for each one.


1.   https://bugs.launchpad.net/magnum/+bug/1542384

2.   https://bugs.launchpad.net/magnum/+bug/1541964

3.   https://bugs.launchpad.net/magnum/+bug/1542386

4.   https://bugs.launchpad.net/magnum/+bug/1536739

I gave #3 the highest priority because, without this issue being resolved, the 
gate takes several hours to run a single job. It would be tedious for testing 
patches and trouble-shooting other issues in such environment. Any kind of help 
for this issue is greatly appreciated.

Egor, thanks for the advice. A ticket was created to track the logs missing 
issue you mentioned: https://bugs.launchpad.net/magnum/+bug/1542390

Best regards,
Hongbin

From: Guz Egor [mailto:guz_e...@yahoo.com]
Sent: February-05-16 2:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] gate issues

Corey,

I think we should do more investigation before applying any "hot" patches. E.g. 
I look at several failures today and honestly there is no way to find out 
reasons.
I believe we are not copying logs 
(https://github.com/openstack/magnum/blob/master/magnum/tests/functional/python_client_base.py#L163)
 during test failure,
we register handler at setUp 
(https://github.com/openstack/magnum/blob/master/magnum/tests/functional/python_client_base.py#L244),
 but Swarm tests, create
bay in setUpClass 
(https://github.com/openstack/magnum/blob/master/magnum/tests/functional/swarm/test_swarm_python_client.py#L48)
 which called before setUp.
So there is no way to see any logs from vm.

sorry, I cannot submit patch/debug by myself because I will get my laptop back 
only on Tue ):

---
 Egor


From: Corey O'Brien >
To: OpenStack Development Mailing List (not for usage questions) 
>
Sent: Thursday, February 4, 2016 9:03 PM
Subject: [openstack-dev] [Magnum] gate issues

So as we're all aware, the gate is a mess right now. I wanted to sum up some of 
the issues so we can figure out solutions.

1. The functional-api job sometimes fails because bays timeout building after 1 
hour. The logs look something like this:
magnum.tests.functional.api.v1.test_bay.BayTest.test_create_list_and_delete_bays
 [3733.626171s] ... FAILED
I can reproduce this hang on my devstack with etcdctl 2.0.10 as described in 
this bug (https://bugs.launchpad.net/magnum/+bug/1541105), but apparently 
either my fix with using 2.2.5 (https://review.openstack.org/#/c/275994/) is 
incomplete or there is another intermittent problem because it happened again 
even with that fix: 
(http://logs.openstack.org/94/275994/1/check/gate-functional-dsvm-magnum-api/32aacb1/console.html)

2. The k8s job has some sort of intermittent hang as well that causes a similar 
symptom as with swarm. https://bugs.launchpad.net/magnum/+bug/1541964

3. When the functional-api job runs, it frequently destroys the VM causing the 
jenkins slave agent to die. Example: 
http://logs.openstack.org/03/275003/6/check/gate-functional-dsvm-magnum-api/a9a0eb9//console.html
When this happens, zuul re-queues a new build from the start on a new VM. This 
can happen many times in a row before the job completes.
I chatted with openstack-infra about this and after taking a look at one of the 
VMs, it looks like memory over consumption leading to thrashing was a possible 
culprit. The sshd daemon was also dead but the console showed things like 
"INFO: task kswapd0:77 blocked for more than 120 seconds". A cursory glance and 
following some of the jobs seems to indicate that this doesn't happen on RAX 
VMs which have swap devices unlike the OVH VMs as well.

4. In general, even when things work, the gate is really slow. The sequential 
master-then-node build process in combination with underpowered VMs makes bay 
builds take 25-30 minutes when they do succeed. Since we're already close to 
tipping over a VM, we run functional tests with concurrency=1, so 2 bay builds 
means almost the entire allotted devstack testing time (generally 75 minutes of 
actual test time available it seems).

Corey

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

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

[openstack-dev] [kolla] Make "central logging" optional

[Eric LEMOINE]

Hi Kolla devs

The other day inc0 said that we would like "central logging" to be
optional in Mitaka, and still use Rsyslog and keep the current
behavior if "central logging" is disabled.

I would like to propose an alternative, where we do remove Rsyslog as
planned in the spec.

I like the idea of an enable_central_logging switch, because it makes
sense to me that an operator have the possibility to NOT centralize
his logs in Elasticsearch (or anywhere else).

When enable_central_logging is false I suggest to just not deploy
Heka, Elasticsearch and Kibana. (Rsyslog would not be deployed
either.)

So when enable_central_logging is false the OpenStack services will
still write their logs in the "log" named volume
(/var/lib/docker/volumes/log/_data), but no one will read/process
these logs.  They will just sit there at the disposal of the operator.

For services that log to Syslog (HAProxy and Keepalived) we won't
collect their logs if enable_central_logging is false, but these
services' logs are not collected today, so no regression there.

I think this would make a simple alternative.

Thoughts?

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Thierry Carrez]

Dean Troyer wrote:

On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez > wrote:


My personal take on that is that we can draw a line in the sand for
what is acceptable as an official project in the upstream OpenStack
open source effort. It should have a fully-functional,
production-grade open source implementation. If you need proprietary
software or a commercial entity to fully use the functionality of a
project or getting serious about it, then it should not be accepted
in OpenStack as an official project. It can still live as a
non-official project and even be hosted under OpenStack
infrastructure, but it should not be part of "OpenStack". That is
how I would interpret "no open core" in OpenStack 2016.


Should we host projects that have no hope of becoming official projects
due to this sort of criteria?  Would we host GPL-only projects under
openstack/?


The answer to that lives at:
http://governance.openstack.org/reference/licensing.html

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Gareth]

I think that will become a clear definition but not a strict one :) In
Huawei, each release of product will be evaluated by availability,
security, usability, maintainability and something else. Those design
ideas looks difficult but could drive projects stronger.

On Sat, Feb 6, 2016 at 12:49 AM, Russell Bryant  wrote:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Even before OpenStack had a name, our "Four Opens" principles were
>> created to define how we would operate as a community. The first open,
>> "Open Source", added the following precision: "We do not produce 'open
>> core' software". What does this mean in 2016 ?
>>
>> Back in 2010 when OpenStack was started, this was a key difference with
>> the other open source cloud platform (Eucalyptus) which was following an
>> Open Core strategy with a crippled community edition and an "enterprise
>> version". OpenStack was then the property of a single entity
>> (Rackspace), so giving strong signals that we would never follow such a
>> strategy was essential to form a real community.
>>
>> Fast-forward today, the open source project is driven by a non-profit
>> independent Foundation, which could not even do an "enterprise edition"
>> if it wanted to. However, member companies build "enterprise products"
>> on top of the Apache-licensed upstream project. And we have drivers that
>> expose functionality in proprietary components. So what does it mean to
>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>> time for us to refresh this.
>
> Nice summary.  I agree that some clarification would be helpful given to
> match our current reality.
>
>> My personal take on that is that we can draw a line in the sand for what
>> is acceptable as an official project in the upstream OpenStack open
>> source effort. It should have a fully-functional, production-grade open
>> source implementation. If you need proprietary software or a commercial
>> entity to fully use the functionality of a project or getting serious
>> about it, then it should not be accepted in OpenStack as an official
>> project. It can still live as a non-official project and even be hosted
>> under OpenStack infrastructure, but it should not be part of
>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>> 2016.
>>
>> Of course, the devil is in the details, especially around what I mean by
>> "fully-functional" and "production-grade". Is it just an API/stability
>> thing, or does performance/scalability come into account ? There will
>> always be some subjectivity there, but I think it's a good place to start.
>>
>> Comments ?
>>
>
> I agree with your take.  I'm not too worried about coming up with a
> strict definition for what a reasonable open source backend is.  We can
> throw in some desirable traits like you have done, and then leave it to
> the TC to evaluate.  I think that's a reasonable part of the TC's job.
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Gareth (Kun Huang)

Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball
OpenStack contributor, kun_huang@freenode
My promise: if you find any spelling or grammar mistakes in my email
from Mar 1 2013, notify me
and I'll donate $1 or ￥1 to an open organization you specify.

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

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

>
> Is it certain that there is no need for the functions with the new EC2-API 
> functions ?
>
> The S3 functions are somewhat separated from the EC2 API. How does SWIFT 
> implement the S3 compatibility layer ?
>
> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make 
> sure we’re not using it somewhere else.
>

This would be just a deprecation warning. Removal would be determined at a 
later time with sufficient lead time.

Do you know how S3 with SWIFT works ? Would they need to do something like 
EC2-API ?

Tim



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

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Timur Sufiev]

Okay, with https://review.openstack.org/#/c/276123/ finally merged tests
should pass more predictably now. Please, recheck and reverify your patches
now. I hope that recheck/reverify alone is enough to consume merged test
fix, if I'm wrong please correct me.

On Thu, Feb 4, 2016 at 5:46 PM Timur Sufiev  wrote:

> That has been a hard week for integration tests, as soon as API-breaking
> change in xvfbwrapper had been worked around, we have been hit by a new
> Selenium release, see https://bugs.launchpad.net/horizon/+bug/1541876
>
> Investigation of a root cause is still in progress.
>
> On Mon, Feb 1, 2016 at 11:31 PM Richard Jones 
> wrote:
>
>> Ugh, dependencies with breaking API changes in minor point releases :/
>>
>> On 2 February 2016 at 04:53, Timur Sufiev  wrote:
>>
>>> Maintainers of outside dependencies continue to break our stuff :(. New
>>> issue is https://bugs.launchpad.net/horizon/+bug/1540495 patch is
>>> currently being checked by Jenkins
>>>
>>> On Sat, Jan 30, 2016 at 2:28 PM Timur Sufiev 
>>> wrote:
>>>
 Problematic Selenium versions have been successfully excluded from
 Horizon test-requirements, if you still experiencing the error described
 above, rebase your patch onto the latest master.
 On Fri, 29 Jan 2016 at 12:36, Itxaka Serrano Garcia 
 wrote:

> Can confirm, had the same issue locally, was fixed after a downgrade to
> selenium 2.48.
>
>
> Good catch!
>
> Itxaka
>
> On 01/28/2016 10:08 PM, Timur Sufiev wrote:
> > According to the results at
> > https://review.openstack.org/#/c/273697/1 capping Selenium to be not
> > greater than 2.49 fixes broken tests. Patch to global-requirements is
> > here: https://review.openstack.org/#/c/273750/
> >
> > On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev  > > wrote:
> >
> > Hello, Horizoneers
> >
> > You may have noticed recent integration tests failures seemingly
> > unrelated to you patches, with a stacktrace like:
> > http://paste2.org/2Hk9138U I've already filed a bug for that,
> > https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
> > Selenium issue, currently investigating it.
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/05/2016 12:16 PM, Ryan Brown wrote:
> On 02/05/2016 09:08 AM, michael mccune wrote:
>> On 02/04/2016 12:57 PM, Hayes, Graham wrote:
>>> On 04/02/2016 15:40, Ryan Brown wrote:
> [snipped lots]
 This isn't a perfect solution, but maybe instead of projects.yml there
 could be a `registry.yml` project that would (of course) have all the
 project.yml "in-tent" projects, but also merge in external project
 requests for namespaces?
>>>
>>> Where ever it is stored, could this be a solid place for the api-wg to
>>> codify the string that should be shown in the catalog / headers /
>>> other places by services?
>>>
>>
>> this seems like a reasonable approach, the big downside might be
>> grooming the "dibs" list. we could have projects that expect to go
>> somewhere, register their name, then never achieve "lift-off". in these
>> cases we would need to release those names back into the free pool.
> 
> There could be some kind of reaping process, say every January send an
> email to every project with outstanding "dibs" to check that they still
> exist and want that name.
> 
> I think a 1 year TTL would be a good starting spot, does that help?
> 
> [snipped more]

Personally, I don't feel like reservations should exist for non
OpenStack projects. That's just squatting and locks away resources from
actual openstack projects.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> > Hi everyone,
> >
> > Even before OpenStack had a name, our "Four Opens" principles were
> > created to define how we would operate as a community. The first open,
> > "Open Source", added the following precision: "We do not produce 'open
> > core' software". What does this mean in 2016 ?
> >
> > Back in 2010 when OpenStack was started, this was a key difference with
> > the other open source cloud platform (Eucalyptus) which was following an
> > Open Core strategy with a crippled community edition and an "enterprise
> > version". OpenStack was then the property of a single entity
> > (Rackspace), so giving strong signals that we would never follow such a
> > strategy was essential to form a real community.
> >
> > Fast-forward today, the open source project is driven by a non-profit
> > independent Foundation, which could not even do an "enterprise edition"
> > if it wanted to. However, member companies build "enterprise products"
> > on top of the Apache-licensed upstream project. And we have drivers that
> > expose functionality in proprietary components. So what does it mean to
> > "not do open core" in 2016 ? What is acceptable and what's not ? It is
> > time for us to refresh this.
> >
> > My personal take on that is that we can draw a line in the sand for what
> > is acceptable as an official project in the upstream OpenStack open
> > source effort. It should have a fully-functional, production-grade open
> > source implementation. If you need proprietary software or a commercial
> > entity to fully use the functionality of a project or getting serious
> > about it, then it should not be accepted in OpenStack as an official
> > project. It can still live as a non-official project and even be hosted
> > under OpenStack infrastructure, but it should not be part of
> > "OpenStack". That is how I would interpret "no open core" in OpenStack
> > 2016.
> >
> > Of course, the devil is in the details, especially around what I mean by
> > "fully-functional" and "production-grade". Is it just an API/stability
> > thing, or does performance/scalability come into account ? There will
> > always be some subjectivity there, but I think it's a good place to start.
> >
> > Comments ?
> 
> If a project isn't fully functional* then why would we accept it at all? 
> Imagine this scenario:
> 
> 1) Heat didn't exist
> 2) A project exactly like heat applies for OpenStack, that lets you use 
> templates to create resources to a specification
> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
> templates longer than 200 characters.

There's a more concrete case being considered right now that is less
clear to some [1].

The Poppy project provides an open source service to wrap content
delivery network APIs. They follow all of our other best-practices,
but there is apparently no practical open source CDN solution.
OpenCDN was mentioned, but it seems dead.

In the absence of any open source solution, the Poppy service is
only useful when connected to commercial services. The Poppy team
has provided drivers for several of these (I see akamai, cloudfront,
fastly, and maxcdn in their "providers" package). Stackalytics shows
the contributors on the team are mostly from Rackspace[2].  I'm not
aware of Rackspace owning any of those services, though I'm sure
they have relationships with one more more.

My understanding of the "no open core" requirement is about the
intent of the contributor.  We don't want separate community and
"enterprise" editions of components (services or drivers).  The
Poppy situation doesn't seem to be a case of open washing anything,
or holding back features in order to sell a more advanced version.
It happens that for Poppy to be useful, you have to buy another
service for it to talk to (and to serve your data), but all of the
Poppy code is actually open and there are several services to choose
from.  There is no "better" version of Poppy available for sale,
if you buy a PoppyCDN subscription.

So, is Poppy "open core"?

Doug

[1] https://review.openstack.org/#/c/273756/
[2] 
http://stackalytics.com/?project_type=all=all=poppy=commits

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

Re: [openstack-dev] [all] the trouble with names

[Ryan Brown]

On 02/05/2016 01:00 PM, Sean Dague wrote:

On 02/05/2016 12:16 PM, Ryan Brown wrote:

On 02/05/2016 09:08 AM, michael mccune wrote:

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

[snipped lots]

This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have all the
project.yml "in-tent" projects, but also merge in external project
requests for namespaces?


Where ever it is stored, could this be a solid place for the api-wg to
codify the string that should be shown in the catalog / headers /
other places by services?



this seems like a reasonable approach, the big downside might be
grooming the "dibs" list. we could have projects that expect to go
somewhere, register their name, then never achieve "lift-off". in these
cases we would need to release those names back into the free pool.


There could be some kind of reaping process, say every January send an
email to every project with outstanding "dibs" to check that they still
exist and want that name.

I think a 1 year TTL would be a good starting spot, does that help?

[snipped more]


Personally, I don't feel like reservations should exist for non
OpenStack projects. That's just squatting and locks away resources from
actual openstack projects.


Yeah, but I feel like there would be a lot of benefit to some kind of 
system where not-openstack-yet projects could say "we want to use X as a 
generic name" so it's not a surprise when two projects show up and want 
in the tent, but then one of them has to go change its service.


For example, I think "containers" will be one of those words that 
everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for 
projects to say "hm, someone else wants this" would be nice.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [all] the trouble with names

[Nick Yeates]

I have the benefit here of being a beginner to openstack and having experienced 
AWS as a user. I think that the current "nova", "cinder" etc naming was 
confusing to me at first, but that it's a needed stumbling block for devs and 
deployers/ops to be precise. 

However, for end-users, probably mostly in a GUI, you need to be smart about 
labels/names. Amazon currently uses a hybrid approach. They call 'compute' 
"ec2", but in the UI, the top dashboard explain all user-accessible services 
with both of the names and a short description. 

Basically, I think you keep the naming as is, and focus on clarification in the 
UI.

- Nick Yeates

> On Feb 5, 2016, at 7:56 AM, Chris Dent  wrote:
> 
>> On Thu, 4 Feb 2016, Sean Dague wrote:
>> 
>> 2) Have a registry of "common" names.
>> 
>> Upside, we can safely use common names everywhere and not fear collision
>> down the road.
> 
> This is the only option presented thus far which meets the needs of
> end users and also some of our stated goals about creating
> interoperable OpenStack-based clouds.
> 
> It does, however, require some integration and orchestration between
> TC, Service Catalog work, and API-WG guidelines.
> 
>> Downside, yet another contention point.
> 
> What's the issue with contention? Contention is one of several tools
> that humans use to resolve disagreement and reached a shared
> understanding of the problem space. Without shared understanding
> in a community there's zero chance a community will create and work
> towards shared goals. Because even if everyone is using the same
> words for the goals, if they aren't using the same meanings, it's
> all bunk.
> 
> When we, as a group, start to contend over terms and identifiers
> that's just a signal that we don't really know what we're trying to
> do and need to work at it. A lot of people, frustrated with all this
> talk, will call it bikeshedding and then go off and do their own
> thing, potentially not in concert with other people's goals. Making
> all that talk is sometimes necessary if we want to be headed in the
> same direction[1].
> 
> The economics of our situation often make that kind of cross-project
> noodling challenging. As a group of open source devs we likely need
> to keep our patrons clearly aware of the value and amount of what
> some would call overhead.
> 
> It is not overhead. It's a major part of the work.
> 
> The big tent, in some sense, has been an invitation to allow people
> to work on a more diverse set of goals. At the edge this is
> beneficial as it means more useful stuff, but it has diffused
> understanding of what "OpenStack" is. For consumers of OpenStack (and
> for devs who are primarily concerned with making a thing called
> OpenStack that is useful for those consumers) there needs to be a
> thing which is OpenStack and that thing needs to be consistent and
> coherent. And limited[2].
> 
> A tool we have at our disposal for creating that consistency is the
> service catalog and specifically the service catalog types.
> 
> Some will argue that this will lead to people contending over who
> should occupy a type, as if that were a bad thing. It is not. Having
> that discussion will help identify the flaws in the proposed
> occupiers and keep the discussion of "what are we" alive and
> healthy[3].
> 
>> A registry would clearly be under TC administration, though all the
>> heavy lifting might be handed over to the API working group. I still
>> imagine collision around some areas might be contentious.
> 
> I'm happy for the API-wg to handle some of this if mike and Everett
> are as well. Making it work well will require everybody plays well
> with the service catalog too[4]
> 
> The biggest challenge I predict is when we need to change things, as
> we inevitably will. Many currently hold dear that we cannot impose
> change upon the existing user base. Sometimes you do and really it's
> not that much of a big deal compared to the pain of running
> OpenStack in the first place.
> 
> [1] It's perfectly okay for tools to not head in the same
> direction, especially if they can be consumed as independent
> libraries or services and are not embedded in the world of
> OpenStack. This is a good thing. There's far too much stuff _in_
> OpenStack that should just be _used by_ OpenStack (or used by
> OpenStack users).
> 
> [2] Yes, this means we need to have an opinion about what OpenStack
> is and build that opinion into the system. That's good. OpenStack is
> insufficiently generic to be unopinionated. Let's just get over
> that.
> 
> [3] At the moment it appears that much of the time the goal of
> OpenStack is to keep the gate running. This is classic statism at
> its worst. Straight out of the movie Brazil.
> 
> [4] 
> http://specs.openstack.org/openstack/openstack-specs/specs/service-catalog.html
> 
> -- 
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: 

Re: [openstack-dev] [all] the trouble with names

[Jay Pipes]

On 02/05/2016 08:38 AM, Dean Troyer wrote:

On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > wrote:

I think this discussion is dancing around the edges of a referendum on
the "duplication" aspect of the big tent.

It is also dancing around the separation of 'API' from
'implementation'.  There is a long-standing disagreement on whether
OpenStack APIs can/should stand on their own, or simply be defined as
'whatever project Foo implements'.


I think you know my opinion on this matter :)

My belief is that we should have a single curated, consistent, and 
governed OpenStack API, a reference implementation of that API, and the 
ability to have competing implementations of that API to encourage 
innovation.


> We already have seen independent

implementations of OpenStack APIs, although not (yet?) as OpenStack
projects.  Duplication is already happening in the wild.


I'm aware of multiple competing APIs for the same general problem space 
(Ceilometer and Monasca are the canonical example of this), but I'm not 
aware of competing implementations of identical APIs. Could you point us 
to where this has happened?


-jay

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jim Meyer]

On "production-grade":

> On Feb 5, 2016, at 6:23 AM, Tim Bell  wrote:
> 
> From: Dean Troyer
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Friday 5 February 2016 at 14:57
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
>> [...]
>> Of course, the devil is in the details, especially around what I mean by 
>> "fully-functional" and "production-grade". Is it just an API/stability 
>> thing, or does performance/scalability come into account ? There will always 
>> be some subjectivity there, but I think it's a good place to start.
> 
> I think defining 'fully-functional' is easy enough until you allow 'vendor 
> extensions' into the API.  But there is still an amount of objective criteria 
> to look at to make it something that a group of, say 13 judges, might arrive 
> at a reasonable answer.
> 
> 'Production-grade' is more subjective, especially with the size of deployment 
> differences in 'production' for a bunch of other things.  But again, it is 
> one of those things that reasonably technical people will generally arrive at 
> a useful conclusion .  Existing components (DB, message queues, etc) can 
> point at known production deployments as evidence; new components have a 
> harder sell.

I'm in complete support of requiring any device in OpenStack to have a 
"production-grade" free-software-based configuration; I'd also say that this 
should be the default configuration for "pure upstream" OpenStack. I don't see 
this as conflicting at all with vendor distros or deployments, which may change 
underlying components and configuration freely as long as the result meets the 
standards for "production-grade."

I'd be (strongly) in favor of defining a target deployment configuration and 
size which we find representative of the minimum bar for "production-grade." 
Anything less concrete and specific becomes more nuisance than help. I'd hope 
that specs might look like the following:

- tests must be run against an OpenStack-certified cloud containing at minimum 
20 compute nodes, 1 TB block storage, 1 TB object storage
- tests must demonstrate service responsiveness, stability, and reliability 
while VMs, compute volumes, object store objects, and networks are 
created/destroyed at a rate of 50/second in any combination while maintaining 
99.9%+ service availability, <1% error rate, and response latency of <100ms  
- tests must demonstrate service resiliency when faced with common component 
failures such as: compute node failure, storage failure, network failure, etc.

(all numbers here are to show the level of specificity needed, are completely 
made up, and should be chosen more appropriately than that)

I also think these are things that we should be regularly testing for core 
OpenStack services, and that I'd be happy to see as part of DefCore someday.

--j

> 
> For a time many projects used SQLite as a reference implementation for 
> testing DB functionality, and have moved away from that (completely? I'm not 
> sure) as we all agree it really is not a production-grade implementation.  
> That is an easy example, but as a community we have crossed this bridge 
> multiple times already and will be able to do it again.
> 
> This could also be covered by needing scaleable as well as fully-functional 
> and production grade. Again, it would be subjective but it would avoid 
> reference implementations that only work at devstack scale.
> 
> Tim
> 
> 
> dt
> 
> -- 
> 
> Dean Troyer
> dtro...@gmail.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Morgan Fainberg]

On Feb 5, 2016 09:43, "Tim Bell"  wrote:
>
>
> Is it certain that there is no need for the functions with the new
EC2-API functions ?
>
> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
implement the S3 compatibility layer ?
>
> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
make sure we’re not using it somewhere else.
>

This would be just a deprecation warning. Removal would be determined at a
later time with sufficient lead time.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - L3 flavors and issues with use cases for multiple L3 backends

[Neil Jerram]

On 01/02/16 14:11, Kevin Benton wrote:
> Hi all,
>
> I've been working on an implementation of the multiple L3 backends
> RFE[1] using the flavor framework and I've run into some snags with the
> use-cases.[2]

Is there any good documentation for flavors yet?  I recall looking 
unsuccessfully, a few months ago.

Neil


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

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

Is it certain that there is no need for the functions with the new EC2-API 
functions ?

The S3 functions are somewhat separated from the EC2 API. How does SWIFT 
implement the S3 compatibility layer ?

Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make sure 
we’re not using it somewhere else.

Tim

From:  Dolph Mathews
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"
Date:  Friday 5 February 2016 at 17:07
To:  "OpenStack Development Mailing List (not for usage questions)"
Subject:  Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token 
to Externally supported

+1 this is a totally logical move, especially given that the current 
implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg  wrote:
Looking over the state [and relatively untested nature] of the Keystone EC2 API 
and S3Token APIs, I want to propose deprecating these mechanisms of auth within 
Keystone at this time.

These systems have been historically poorly tested and supported and have 
remained broken / incompatible for long periods at a time. With the move that 
the EC2-API team is taking the code from nova out-of-tree, I would like to 
propose that the auth mechanisms are also moved out of tree and into the 
purview of the team focused on providing a solid EC2 compatibility layer for 
OpenStack.

This will allow the EC2-API team to better ensure the long term viability and 
compatibility of the required auth systems and can free this all from the 
requirement to propose code to keystone to handle forward momentum as required 
to support future/new signature versions and movement within the libraries that 
rely on clear AWS compatibility.

This should ideally be moved to something standalone that can handle the 
translation of EC2 or S3Token Auth to native Keystone api calls.

Thanks for reading,
--Morgan



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

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Stephen Balukoff]

Thanks guys! I appreciate the support and vote of confidence!

On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson  wrote:

> That is quorum from the Octavia cores.
>
> Congratulations Stephen!
>
> Michael
>
> On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German
>  wrote:
> > +1
> >
> > From: Bertrand LALLAU >
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >
> > Date: Friday, February 5, 2016 at 12:26 AM
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org >>
> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen
> Balukoff as Octavia Core
> >
> > +1
> >
> > On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
> > +1
> >
> > Doug
> >
> >
> >> On Feb 4, 2016, at 7:06 PM, Brandon Logan  > wrote:
> >>
> >> +1
> >>
> >>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
> >>> +1 from me!
> >>> 
> >>> From: Michael Johnson  >>
> >>> Sent: Thursday, February 4, 2016 7:03 PM
> >>> To: OpenStack Development Mailing List (not for usage questions)
> >>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff
> as Octavia Core
> >>>
> >>> Octavia Team,
> >>>
> >>> I would like to nominate Stephen Balukoff as a core reviewer for the
> >>> OpenStack Octavia project.  His contributions[1] are in line with
> >>> other cores and he has been an active member of our community.
> >>>
> >>> Octavia cores please vote by replying to this e-mail.
> >>>
> >>> Michael
> >>>
> >>> [1] http://stackalytics.com/report/contribution/octavia/90
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Principal Technologist
Blue Box, An IBM Company
www.blueboxcloud.com
sbaluk...@blueboxcloud.com
206-607-0660 x807
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Andrey Pavlov]

swift3(s3) works like ec2-api.

1. swift3/ec2-api recieves AWS request
2. it parses signature and access_key (and other headers)
3. it sends these values (and token that calculated from request) to keystone
4. keystone gets secret_key from DB, then calculates signature by
recieved access_key and token
5. keystone compares recived signature and claculated signature and
then return 'error' or auth_token
6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
or continues execution
7. in case of continue swift3/ec2-api uses recieved auth_token for
calls other services: nova, cinder, neutron, swift...

So I don't understand how implement this functionality outside of keystone...

On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>
>>
>> Is it certain that there is no need for the functions with the new EC2-API
>> functions ?
>>
>> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
>> implement the S3 compatibility layer ?
>>
>> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make
>> sure we’re not using it somewhere else.
>>
>
> This would be just a deprecation warning. Removal would be determined at a
> later time with sufficient lead time.
>
> Do you know how S3 with SWIFT works ? Would they need to do something like
> EC2-API ?
>
> Tim
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 14:23 Feb 05, Tim Bell wrote:
> I think defining 'fully-functional' is easy enough until you allow 'vendor
> extensions' into the API.  But there is still an amount of objective criteria
> to look at to make it something that a group of, say 13 judges, might arrive
> at a reasonable answer.

I think those extensions shouldn't exist to begin with. That's another
discussion though, and a direction I think some projects are making already.

If a vendor wants to introduce anything into a project's API, there should be
some equivalent open source thing to back it up that people can try it out on.

I think more importantly the reference implementation a project chooses should
be able to use said feature, which is going to be an open source solution.

Projects like Cinder suffer from this today, and our only way of knowing if the
feature works is vendor third party CI's that use the optional tempest tests
for having the feature available in their driver.

-- 
Mike Perez

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Brandon Logan]

What have we done?

On Fri, 2016-02-05 at 10:30 -0800, Stephen Balukoff wrote:
> Thanks guys! I appreciate the support and vote of confidence!
> 
> On Fri, Feb 5, 2016 at 9:16 AM, Michael Johnson 
> wrote:
> That is quorum from the Octavia cores.
> 
> Congratulations Stephen!
> 
> Michael
> 
> On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German
>  wrote:
> > +1
> >
> > From: Bertrand LALLAU
> >
> > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
> 
> >
> > Date: Friday, February 5, 2016 at 12:26 AM
> > To: "OpenStack Development Mailing List (not for usage
> questions)"
> 
> >
> > Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing
> Stephen Balukoff as Octavia Core
> >
> > +1
> >
> > On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley
> > 
> wrote:
> > +1
> >
> > Doug
> >
> >
> >> On Feb 4, 2016, at 7:06 PM, Brandon Logan
> > 
> wrote:
> >>
> >> +1
> >>
> >>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
> >>> +1 from me!
> >>> 
> >>> From: Michael Johnson
> >
> >>> Sent: Thursday, February 4, 2016 7:03 PM
> >>> To: OpenStack Development Mailing List (not for usage
> questions)
> >>> Subject: [openstack-dev] [lbaas] [octavia] Proposing
> Stephen Balukoff as Octavia Core
> >>>
> >>> Octavia Team,
> >>>
> >>> I would like to nominate Stephen Balukoff as a core
> reviewer for the
> >>> OpenStack Octavia project.  His contributions[1] are in
> line with
> >>> other cores and he has been an active member of our
> community.
> >>>
> >>> Octavia cores please vote by replying to this e-mail.
> >>>
> >>> Michael
> >>>
> >>> [1] http://stackalytics.com/report/contribution/octavia/90
> >>>
> >>>
> 
> __
> >>> OpenStack Development Mailing List (not for usage
> questions)
> >>> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> 
> __
> >>> OpenStack Development Mailing List (not for usage
> questions)
> >>> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> 
> __
> >> OpenStack Development Mailing List (not for usage
> questions)
> >> Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
>

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Dolph Mathews]

On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:

> swift3(s3) works like ec2-api.
>
> 1. swift3/ec2-api recieves AWS request
> 2. it parses signature and access_key (and other headers)
> 3. it sends these values (and token that calculated from request) to
> keystone
> 4. keystone gets secret_key from DB, then calculates signature by
> recieved access_key and token
> 5. keystone compares recived signature and claculated signature and
> then return 'error' or auth_token
> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
> or continues execution
> 7. in case of continue swift3/ec2-api uses recieved auth_token for
> calls other services: nova, cinder, neutron, swift...
>
> So I don't understand how implement this functionality outside of
> keystone...
>

EC2 support is implemented in middleware on top of keystone, and that
middleware happens to live in the openstack/keystone repository. This
change is just proposing to move that middleware code into a dedicated new
repository and change the community support & maintenance model - it would
not affect how the code actually operates. The only affect on operators is
that it would require an extra step to deploy it. End users would not be
affected.

https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27

https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31


>
> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
> >
> >>
> >> Is it certain that there is no need for the functions with the new
> EC2-API
> >> functions ?
> >>
> >> The S3 functions are somewhat separated from the EC2 API. How does SWIFT
> >> implement the S3 compatibility layer ?
> >>
> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
> make
> >> sure we’re not using it somewhere else.
> >>
> >
> > This would be just a deprecation warning. Removal would be determined at
> a
> > later time with sufficient lead time.
> >
> > Do you know how S3 with SWIFT works ? Would they need to do something
> like
> > EC2-API ?
> >
> > Tim
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Magnum] Bug 1541105 options

[Steve Gordon]

- Original Message -
> From: "Steven Dake (stdake)" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> Steve,
> 
> Comments inline
> 
> On 2/3/16, 3:08 PM, "Steve Gordon"  wrote:
> 
> >- Original Message -
> >> From: "Hongbin Lu" 
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >>
> >> 
> >> I would vote for a quick fix + a blueprint.
> >> 
> >> BTW, I think it is a general consensus that we should move away from
> >>Atomic
> >> for various reasons (painful image building, lack of document, hard to
> >>use,
> >> etc.). We are working on fixing the CoreOS templates which could replace
> >> Atomic in the future.
> >> 
> >> Best regards,
> >> Hongbin
> >
> >Hi Hongbin,
> >
> >I had heard this previously in Tokyo and again when I was asking around
> >about the image support on IRC last week, is there a list of the exact
> >issues with image building etc. with regards to Atomic? When I was
> >following up on this it seemed like the main issue is that the docs in
> >the magnum repo are quite out of date (versus the upstream fedora atomic
> >docs) both with regards to the content of the image and the process used
> >to (re)build it - there didn't seem to be anything quantifiable that's
> >wrong with the current Atomic images but perhaps I was asking the wrong
> >folks. I was able to rebuild fairly trivially using the Fedora built
> >artefacts [1][2].
> 
> Steve,
> 
> I hope you can forgive my directness and lack of diplomacy in this
> message. :)
> 
> At least when I was heavily involved with Magnum, building atomic images
> resulted in a situation in which the binaries built did not work properly.
>  I begged on the irc channels for help and begged on the mailing list for
> help for _ months _ on end and nobody listened.  It is almost as if nobody
> is actually working on Atomic.  If there are people, they do not maintain
> any kind of support footprint upstream to make Atomic a viable platform
> for Magnum.

Hi Steve,

No worries about directness, it's actually what I am trying to elicit so I can 
understand and hopefully help address the issues. I did come across a couple of 
mailing list posts from you mainly asking about newer k8s/etcd/flannel versions 
and also etcdctl inclusion (there was a workaround posted at the time but I 
note it's now in the image) [1][2]. These threads are actually what prompted me 
to ask "what else?" to try and determine if Magnum had other needs here, e.g. 
the rpm-ostree issue you refer to below is the type of hint I'm after to try 
and ensure everything is tracked somewhere.

> I taught Tango how to build the images, who wrote the instructions down in
> the Magnum documentation.  That documentation ends up producing images
> that randomly don't always work. The binaries return some weird system
> call error, ebadlink I think but not sure.  Tango may remember.

I was playing around with this earlier in the week and had some more success 
via a slightly different path, I'm in the process of attempting to re-produce 
on a clean system to ensure that (a) I didn't skip anything in the notes I took 
and (b) weed out any other setup that was peculiar to my system before I 
propose something against the docs.

> Perhaps the rpm-ostree defect has been resolved now.  I have to be clear
> that I was told "please wait 6 months for us to fix the build system and
> bugs" while Atomic was our only distro implemented.  It was very
> maddening.  I was so frustrated with Atomic, at the start of Mitaka I was
> going to propose deprecating Atomic because of a complete lack of upstream
> responsiveness.  I decided to let other folks make the call about what
> they wanted to do with Atomic since I was myself unresponsive with the
> Magnum upstream because of my full-time Kolla commitment.
>
> I am pretty sure a bug was filed about this issue in the Red Hat bugzilla,
> but I can't find it.

Thanks, the hint that it regarded rpm-ostree was enough for me to find this:

https://bugzilla.redhat.com/show_bug.cgi?id=1177989

Does that seem like the right issue? That in turn led me to this bug which 
appears fixed in F21, but I need to follow up to work out what if anything 
happened w.r.t. the second half of Colin's comment in the above bug (or whether 
it is still relevant):

https://bugzilla.redhat.com/show_bug.cgi?id=1178208

Somewhat tangentially I was also wondering if there are specific version 
combinations of components (be they images, or the versions of specific 
components they contain) that are currently recommended/preferred for a given 
release. Obviously there is the custom image that is currently provided but I 
am thinking more for folks trying to roll their own etc. I didn't spot anything 
while poking around in the docs as yet but I may be looking in the wrong 
places. What I am 

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Andrey Pavlov]

Can it be implemented as keystone plugin?
Is it possible to 'get' AUTH_TOKEN outside of keystone?
Will this code use keystone DB or it should create own?

So we will need one 'auth' module for swift3/ec2-api.
Sounds good but we need to understand some details before implementation.

On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  wrote:
>
> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>>
>> swift3(s3) works like ec2-api.
>>
>> 1. swift3/ec2-api recieves AWS request
>> 2. it parses signature and access_key (and other headers)
>> 3. it sends these values (and token that calculated from request) to
>> keystone
>> 4. keystone gets secret_key from DB, then calculates signature by
>> recieved access_key and token
>> 5. keystone compares recived signature and claculated signature and
>> then return 'error' or auth_token
>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>> or continues execution
>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>> calls other services: nova, cinder, neutron, swift...
>>
>> So I don't understand how implement this functionality outside of
>> keystone...
>
>
> EC2 support is implemented in middleware on top of keystone, and that
> middleware happens to live in the openstack/keystone repository. This change
> is just proposing to move that middleware code into a dedicated new
> repository and change the community support & maintenance model - it would
> not affect how the code actually operates. The only affect on operators is
> that it would require an extra step to deploy it. End users would not be
> affected.
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>>
>>
>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>> >
>> >>
>> >> Is it certain that there is no need for the functions with the new
>> >> EC2-API
>> >> functions ?
>> >>
>> >> The S3 functions are somewhat separated from the EC2 API. How does
>> >> SWIFT
>> >> implement the S3 compatibility layer ?
>> >>
>> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
>> >> make
>> >> sure we’re not using it somewhere else.
>> >>
>> >
>> > This would be just a deprecation warning. Removal would be determined at
>> > a
>> > later time with sufficient lead time.
>> >
>> > Do you know how S3 with SWIFT works ? Would they need to do something
>> > like
>> > EC2-API ?
>> >
>> > Tim
>> >
>> >
>> > __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Kind regards,
>> Andrey Pavlov.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kind regards,
Andrey Pavlov.

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

Re: [openstack-dev] [all] the trouble with names

[Ryan Brown]

On 02/05/2016 09:08 AM, michael mccune wrote:

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

[snipped lots]

This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have all the
project.yml "in-tent" projects, but also merge in external project
requests for namespaces?


Where ever it is stored, could this be a solid place for the api-wg to
codify the string that should be shown in the catalog / headers /
other places by services?



this seems like a reasonable approach, the big downside might be
grooming the "dibs" list. we could have projects that expect to go
somewhere, register their name, then never achieve "lift-off". in these
cases we would need to release those names back into the free pool.


There could be some kind of reaping process, say every January send an 
email to every project with outstanding "dibs" to check that they still 
exist and want that name.


I think a 1 year TTL would be a good starting spot, does that help?

[snipped more]

--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Michael Johnson]

That is quorum from the Octavia cores.

Congratulations Stephen!

Michael

On Fri, Feb 5, 2016 at 9:10 AM, Eichberger, German
 wrote:
> +1
>
> From: Bertrand LALLAU 
> >
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Date: Friday, February 5, 2016 at 12:26 AM
> To: "OpenStack Development Mailing List (not for usage questions)" 
> >
> Subject: Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
> Octavia Core
>
> +1
>
> On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley 
> > wrote:
> +1
>
> Doug
>
>
>> On Feb 4, 2016, at 7:06 PM, Brandon Logan 
>> > wrote:
>>
>> +1
>>
>>> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
>>> +1 from me!
>>> 
>>> From: Michael Johnson >
>>> Sent: Thursday, February 4, 2016 7:03 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as 
>>> Octavia Core
>>>
>>> Octavia Team,
>>>
>>> I would like to nominate Stephen Balukoff as a core reviewer for the
>>> OpenStack Octavia project.  His contributions[1] are in line with
>>> other cores and he has been an active member of our community.
>>>
>>> Octavia cores please vote by replying to this e-mail.
>>>
>>> Michael
>>>
>>> [1] http://stackalytics.com/report/contribution/octavia/90
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
wrote:

> So, is Poppy "open core"?
>

It doesn't follow the 'spirit' of open core, but it does have some of the
characteristics, in that the open code is not all that useful, or maybe
even testable, without the commercial component(s) (at this time).

So while Poppy may not fully qualify for the open core label, it still
fails some of the tests that we want to see, such as a usable open source
implementation.

dt

-- 

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ryan Brown]

On 02/05/2016 05:57 AM, Thierry Carrez wrote:

Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were
created to define how we would operate as a community. The first open,
"Open Source", added the following precision: "We do not produce 'open
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with
the other open source cloud platform (Eucalyptus) which was following an
Open Core strategy with a crippled community edition and an "enterprise
version". OpenStack was then the property of a single entity
(Rackspace), so giving strong signals that we would never follow such a
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit
independent Foundation, which could not even do an "enterprise edition"
if it wanted to. However, member companies build "enterprise products"
on top of the Apache-licensed upstream project. And we have drivers that
expose functionality in proprietary components. So what does it mean to
"not do open core" in 2016 ? What is acceptable and what's not ? It is
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what
is acceptable as an official project in the upstream OpenStack open
source effort. It should have a fully-functional, production-grade open
source implementation. If you need proprietary software or a commercial
entity to fully use the functionality of a project or getting serious
about it, then it should not be accepted in OpenStack as an official
project. It can still live as a non-official project and even be hosted
under OpenStack infrastructure, but it should not be part of
"OpenStack". That is how I would interpret "no open core" in OpenStack
2016.

Of course, the devil is in the details, especially around what I mean by
"fully-functional" and "production-grade". Is it just an API/stability
thing, or does performance/scalability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.

Comments ?


If a project isn't fully functional* then why would we accept it at all? 
Imagine this scenario:


1) Heat didn't exist
2) A project exactly like heat applies for OpenStack, that lets you use 
templates to create resources to a specification
3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
templates longer than 200 characters.


Would *any* TC count that as a project that could join under our current 
system? I don't think so. The TC (and community) would say something 
along the lines of "WTF are you thinking? Go read the 4 opens and try again"


I don't think adding "no open core" would change a decision the 
future-community and future-tc might make, because they will be elected 
by aforementioned community. Adding buzz-requirements like "must be 
fully-functional, production grade, webscale open-cloud softwidgets" 
isn't going to help future-us.


Footnotes:

* in my view, an openstack product that requires you to pay a vendor is 
as functional as an openstack product chock-full of syntax errors


** Shed Cat Enterprise Leopard is strictly fictional, and not based on 
any company that currently or ever has existed.


--
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.

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

[openstack-dev] [fuel] Fuel 8.0 Hard Code Freeze

[Dmitry Borodaenko]

Fuel 8.0 (based on Liberty) is now in Hard Code Freeze [0].

[0] https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze

While we're in HCF, only Critical bugfixes may be merged into stable/8.0
branch. Please be conscientious about bug severity and do not upgrade
bugs just to get them in, use our bug severity critieria [1]. Core
reviewers, please make sure that the bugfix backporting rules [2] are
followed, and help committers to backport the fixes for Critical bugs.

[1] 
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Confirm_and_triage_bugs
[2] 
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series

As of this writing, Fuel 8.0 contains 1930 bugfixes [3] (compared to
1552 in Fuel 7.0). Nice work everyone! It's time to move on to the
development of the next release and focus on getting Mitaka support
stabilized in the Fuel master branch, but please watch out for Critical
bugs, we're not yet completely done with 8.0.

[3] https://launchpad.net/fuel/+milestone/8.0

Thanks,

-- 
Dmitry Borodaenko

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

Re: [openstack-dev] [keystone][ec2-api][heat] Moving EC2 Auth and S3Token to Externally supported

[Fox, Kevin M]

Might double check with the heat folks. I think they use some of it with wait 
conditions still?

Thanks,
Kevin

From: Tim Bell [tim.b...@cern.ch]
Sent: Friday, February 05, 2016 9:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to 
Externally supported


Is it certain that there is no need for the functions with the new EC2-API 
functions ?

The S3 functions are somewhat separated from the EC2 API. How does SWIFT 
implement the S3 compatibility layer ?

Getting a ‘to be deprecated’ log entry into Mitaka would be useful to make sure 
we’re not using it somewhere else.

Tim

From: Dolph Mathews
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Friday 5 February 2016 at 17:07
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to 
Externally supported

+1 this is a totally logical move, especially given that the current 
implementation back to the /v3/credentials API anyway.

On Friday, February 5, 2016, Morgan Fainberg 
> wrote:
Looking over the state [and relatively untested nature] of the Keystone EC2 API 
and S3Token APIs, I want to propose deprecating these mechanisms of auth within 
Keystone at this time.

These systems have been historically poorly tested and supported and have 
remained broken / incompatible for long periods at a time. With the move that 
the EC2-API team is taking the code from nova out-of-tree, I would like to 
propose that the auth mechanisms are also moved out of tree and into the 
purview of the team focused on providing a solid EC2 compatibility layer for 
OpenStack.

This will allow the EC2-API team to better ensure the long term viability and 
compatibility of the required auth systems and can free this all from the 
requirement to propose code to keystone to handle forward momentum as required 
to support future/new signature versions and movement within the libraries that 
rely on clear AWS compatibility.

This should ideally be moved to something standalone that can handle the 
translation of EC2 or S3Token Auth to native Keystone api calls.

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Ryan Brown]

On 02/05/2016 01:17 PM, Doug Hellmann wrote:

Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:

On 02/05/2016 05:57 AM, Thierry Carrez wrote:

Hi everyone,

Even before OpenStack had a name, our "Four Opens" principles were
created to define how we would operate as a community. The first open,
"Open Source", added the following precision: "We do not produce 'open
core' software". What does this mean in 2016 ?

Back in 2010 when OpenStack was started, this was a key difference with
the other open source cloud platform (Eucalyptus) which was following an
Open Core strategy with a crippled community edition and an "enterprise
version". OpenStack was then the property of a single entity
(Rackspace), so giving strong signals that we would never follow such a
strategy was essential to form a real community.

Fast-forward today, the open source project is driven by a non-profit
independent Foundation, which could not even do an "enterprise edition"
if it wanted to. However, member companies build "enterprise products"
on top of the Apache-licensed upstream project. And we have drivers that
expose functionality in proprietary components. So what does it mean to
"not do open core" in 2016 ? What is acceptable and what's not ? It is
time for us to refresh this.

My personal take on that is that we can draw a line in the sand for what
is acceptable as an official project in the upstream OpenStack open
source effort. It should have a fully-functional, production-grade open
source implementation. If you need proprietary software or a commercial
entity to fully use the functionality of a project or getting serious
about it, then it should not be accepted in OpenStack as an official
project. It can still live as a non-official project and even be hosted
under OpenStack infrastructure, but it should not be part of
"OpenStack". That is how I would interpret "no open core" in OpenStack
2016.

Of course, the devil is in the details, especially around what I mean by
"fully-functional" and "production-grade". Is it just an API/stability
thing, or does performance/scalability come into account ? There will
always be some subjectivity there, but I think it's a good place to start.

Comments ?


If a project isn't fully functional* then why would we accept it at all?
Imagine this scenario:

1) Heat didn't exist
2) A project exactly like heat applies for OpenStack, that lets you use
templates to create resources to a specification
3) BUT, if you don't buy Proprietary Enterprise Template Parsing
Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse
templates longer than 200 characters.


There's a more concrete case being considered right now that is less
clear to some [1].

>

The Poppy project provides an open source service to wrap content
delivery network APIs. They follow all of our other best-practices,
but there is apparently no practical open source CDN solution.
OpenCDN was mentioned, but it seems dead.


This doesn't surprise me, since most of the "value-add" from a CDN is in 
the "we have points of presence and peering agreements" and less about 
"we use software XYZ". Take, for instance, a typical CDN pricing 
structure. You pay tiered on some combination bandwidth used and the 
number of points-of-presence you want your content served from.


Open source projects aren't usually set up around making big capital 
expenditures and buying lots of bandwidth, so the lack of a FOSS CDN 
isn't exactly Poppy's fault.



In the absence of any open source solution, the Poppy service is
only useful when connected to commercial services. The Poppy team
has provided drivers for several of these (I see akamai, cloudfront,
fastly, and maxcdn in their "providers" package). Stackalytics shows
the contributors on the team are mostly from Rackspace[2].  I'm not
aware of Rackspace owning any of those services, though I'm sure
they have relationships with one more more.


Even in the absence of an open source CDN, I struggle to call poppy 
"open core" in the spirit of "you must buy our enterprise plan" because 
it still doesn't require paying any single vendor. I can still choose 
the commodity (bandwidth, datacenter locations, etc) provider.


This actually proves my point about the community/TC being intelligent 
and being able to make decisions about this sort of thing. A written 
rule about open core might mean we couldn't allow Poppy into the tent, 
but because we have the broader 4-Opens we can look at it and say "yeah, 
it requires you pay for a service, but it's clearly enabling many 
vendors and making it EASIER to switch, which is great."



My understanding of the "no open core" requirement is about the
intent of the contributor.  We don't want separate community and
"enterprise" editions of components (services or drivers).  The
Poppy situation doesn't seem to be a case of open washing anything,
or holding back features in order to sell a more advanced version.
It happens that for Poppy to be 

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

[Jay Pipes]

On 02/05/2016 11:38 AM, Sam Yaple wrote:

On Fri, Feb 5, 2016 at 3:31 PM, Jay Pipes > wrote:

On 02/05/2016 09:58 AM, Sam Yaple wrote:

Since Nova has no backup mechanism this is clearly a gap and
that was the issue
Ekko wants to solve.


Nova has had backups for a long time:

http://developer.openstack.org/api-ref-compute-v2.1.html#createBackup

I always forget to qualify that statement don't I?


No worries :)

> Nova does not have a

mechanism for _incremental_ backups. Nor does Nova have compression or
encryption because AFAIK that api only creates a snapshot. I would also
point out again that snapshots != backups, at least not for those who
care about backups.


Understood.

-jay

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

Re: [openstack-dev] [neutron][ipam][networking-infoblox][release] release:independent branching strategies

[Akihiro Motoki]

I don't think you need to bump the major version per OpenStack release.
If the functionalities is backward-compatible, from the context of the
semantic versioning
you don't need to bump the major version, i.e. 1.x.y to 2.x.y.
According to your description, Mitaka version can be 1.1.0.
I am not sure we need to bump the major version in every OpenStack
release in neutron sub-projects.

As Kyle said, it is important to follow the stable backport policy of course :-)

Akihiro

2016-02-06 2:05 GMT+09:00 Kyle Mestery :
> On Fri, Feb 5, 2016 at 10:50 AM, John Belamaric  
> wrote:
>> Hi all,
>>
>> Back in November, there was a discussion [1] on the mailing list around 
>> release:independent projects, which was wrapped up by Thierry in [2]. 
>> However, I have a couple lingering questions that have come up.
>>
>> In networking-infoblox, we have a 1.0.0 version of our driver that we 
>> released a few months ago, and it is maintained in a the stable/liberty 
>> branch. We just released 2.0.0 out of master, but 2.0.0 is compatible with 
>> Liberty and Mitaka. So, from a branching perspective, is it permissible to 
>> push all the 2.0.0 changes into stable/liberty? Those would be largely 
>> functional changes, not simple bug fixes. If not, should we even *have* a 
>> stable/liberty branch?
>>
> If you're in the Neutron Stadium, and thus following OpenStack stable
> backport rules, you cannot backport functional features like you want.
> If you remove yourself from the stadium, you don't have that issue and
> can backport whatever you want to whatever branch you want. This is
> why for some vendor networking sub-projects it may make more sense to
> be outside the stadium, because it would align with how you want to do
> your own releases.
>
>> The primary reason this is important is to ensure that users and 
>> distributors pull the correct version of the driver. The 1.0.0 version is 
>> pretty limited and we definitely want the 2.0.0 to be the one packaged with 
>> Liberty distributions. So, ideally we would be able to push all the 2.0.0 
>> code into stable/liberty since it is completely compatible - that would make 
>> it simple for distributors to get the right driver.
>>
>> John
>>
>>
>> [1] 
>> http://lists.openstack.org/pipermail/openstack-dev/2015-November/thread.html#78676
>> [2] 
>> http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 07:57 Feb 05, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez 
> wrote:
> 
> > My personal take on that is that we can draw a line in the sand for what
> > is acceptable as an official project in the upstream OpenStack open source
> > effort. It should have a fully-functional, production-grade open source
> > implementation. If you need proprietary software or a commercial entity to
> > fully use the functionality of a project or getting serious about it, then
> > it should not be accepted in OpenStack as an official project. It can still
> > live as a non-official project and even be hosted under OpenStack
> > infrastructure, but it should not be part of "OpenStack". That is how I
> > would interpret "no open core" in OpenStack 2016.
> >
> 
> Should we host projects that have no hope of becoming official projects due
> to this sort of criteria?  Would we host GPL-only projects under openstack/?

With previous threads complaining about low on infra resources to help with
stable releases, I'd actually say no we shouldn't host them. We're already low
with the sunsetting of a big public cloud.

-- 
Mike Perez

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

Re: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff as Octavia Core

[Bertrand LALLAU]

+1

On Fri, Feb 5, 2016 at 3:10 AM, Doug Wiegley 
wrote:

> +1
>
> Doug
>
>
> > On Feb 4, 2016, at 7:06 PM, Brandon Logan 
> wrote:
> >
> > +1
> >
> >> On Fri, 2016-02-05 at 01:07 +, Adam Harwell wrote:
> >> +1 from me!
> >> 
> >> From: Michael Johnson 
> >> Sent: Thursday, February 4, 2016 7:03 PM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: [openstack-dev] [lbaas] [octavia] Proposing Stephen Balukoff
> as Octavia Core
> >>
> >> Octavia Team,
> >>
> >> I would like to nominate Stephen Balukoff as a core reviewer for the
> >> OpenStack Octavia project.  His contributions[1] are in line with
> >> other cores and he has been an active member of our community.
> >>
> >> Octavia cores please vote by replying to this e-mail.
> >>
> >> Michael
> >>
> >> [1] http://stackalytics.com/report/contribution/octavia/90
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla] Location of Heka Lua plugins

[Eric LEMOINE]

On Thu, Feb 4, 2016 at 5:13 PM, Jeff Peeler  wrote:
> On Thu, Feb 4, 2016 at 9:22 AM, Michał Jastrzębski  wrote:
>> TLDR; +1 to have lua in tree of kolla, not sure if we want to switch later
>>
>> So I'm not so sure about switching. If these git repos are in
>> /openstack/ namespace, then sure, otherwise I'd be -1 to this, we
>> don't want to add dependency here. Also we're looking at pretty simple
>> set of files that won't change anytime soon probably. Also we might
>> introduce new service that fuel does not have, and while I'm sure we
>> can push new file to this repo, it's bigger issue than just coding it
>> in tree.
>
> I wouldn't think there'd be any opposition to having additional
> contributed Lua scripts for additional services that Fuel doesn't yet
> have. It's always easier to commit to one tree, but distinct
> components like this separated out encourages code sharing (done
> properly). I did assume that the new repo would be in the OpenStack
> namespace, but even if it weren't I'd still think a separate repo is
> best. Sure the files are small, but given the purpose of these files
> small changes could potentially have a huge impact on the logs.
>
> In summary, +1 to temporarily having the Lua scripts in tree until
> they can be properly migrated to a new repository.


I totally agree with you Jeff.

It is to be noted that we (my team at Mirantis) want to avoid
duplicating our Lua plugins, as we obviously don't want to maintain
two sets of identical plugins.  So there are mulitple reasons for
creating separate packages for these plugins: a) make it easy the
share the plugins across different projects, b) avoid maintaining
multiple sets of identical plugins, and c) avoid clobbering Kolla with
code not directly related to Kolla – for example, would you really
like to see Lua tests in Kolla and run Lua tests in the Kolla gates?
It would indeed be best to have these plugins in the OpenStack Git
namespace (as Steve Dake said), but we will have to see if that's
possible in practice.

Thank you all for your responses.

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

Re: [openstack-dev] Announcing Ekko -- Scalable block-based backup for OpenStack

[Sam Yaple]

On Thu, Feb 4, 2016 at 2:23 PM, gordon chung  wrote:

>
>
> On 03/02/2016 10:38 AM, Sam Yaple wrote:
>
> On Wed, Feb 3, 2016 at 2:52 PM, Jeremy Stanley < 
> fu...@yuggoth.org> wrote:
>
>> On 2016-02-03 14:32:36 + (+), Sam Yaple wrote:
>> [...]
>> > Luckily, digging into it it appears cinder already has all the
>> > infrastructure in place to handle what we had talked about in a
>> > separate email thread Duncan. It is very possible Ekko can
>> > leverage the existing features to do it's backup with no change
>> > from Cinder.
>> [...]
>>
>> If Cinder's backup facilities already do most of
>> what you want from it and there's only a little bit of development
>> work required to add the missing feature, why jump to implementing
>> this feature in a completely separate project instead rather than
>> improving Cinder's existing solution so that people who have been
>> using that can benefit directly?
>>
>
> Backing up Cinder was never the initial goal, just a potential feature on
> the roadmap. Nova is the main goal.
>
> i'll extend fungi's question, are the backup framework/mechanisms common
> whether it be Nova or Cinder or anything else? or are they unique but only
> grouped together as a service because they backup something. it seems the
> problem is we've imagined the service as tackling a horizontal issue when
> really it is just a vertical story that appears across many silos.
>
>
The framework would not be common even between Ekko and Cinder, and there
is no Nova "backup". The main featureset that will be utilized is CBT
(changed-block-tracking) which is needed for efficient incremental backups.
Otherwise the entire block device must be read each time a backup is
performed. The design of Ekko solves the horizontal issue of scaling
backups, there is also this vertical integration that _can_ be done to make
the whole experience more pleasant and reliable. Since Nova has no backup
mechanism this is clearly a gap and that was the issue Ekko wants to solve.
Also backuping up Cinder volumes is on the roadmap, but has not been a
stated priority.

Sam Yaple


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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Neil Jerram]

On 04/02/16 22:39, Assaf Muller wrote:
> On Thu, Feb 4, 2016 at 5:55 PM, Sean M. Collins  wrote:
>> On Thu, Feb 04, 2016 at 04:20:50AM EST, Assaf Muller wrote:
>>
>>> Currently I don't understand why
>>> being a part of the stadium is good or bad for a networking project,
>>> or why does it matter.
>>
>> I think the issue is of public perception.

I agree.  Being 'out' can matter, in some sense, if you are competing -
whether for money, mindshare or whatever - with another project or
approach that is 'in'.  Because it can appear to casual observers that
your project is less 'official', 'blessed', likely to be long term
supported, etc. etc.

But all of that can be mitigated if the criteria are clearly specified
and understand, and uniformly applied.

> That's what I was trying to point out. But it must be something other
> than perception, otherwise we could remove the inclusion list
> altogether. A project would not be in or out.

I'm afraid I don't understand here.

>
>> As others have stated, the
>> issue is the "in" vs. "out" problem. We had a similar situation
>> with 3rd party CI, where we had a list of drivers that were "nice" and
>> had CI running vs drivers that were "naughty" and didn't. Prior to the
>> vendor decomposition effort, We had a multitude of drivers that were
>> in-tree, with the public perception that drivers that were in Neutron's
>> tree were "sanctioned" by the Neutron project.
>>
>> That may not have been the intention, but that's what I think happened.

Precisely.

As some others have said, I see the current discussion as being about
the chain of accountability, from a stadium project, through Neutron, up
to the OpenStack TC and board.  IIUC, Armando and other cores feel that
there is a gap there - because they can't reasonably understand and
vouch for all the stadium projects to the same standard they can for
core Neutron.  Plus it seems (from the current
https://review.openstack.org/#/c/275888/9 text) that there is a desire
for strong core team overlap between openstack/neutron and all Neutron
stadium projects.

As the lead of networking-calico, I think it's a reasonable call to say
that networking-calico (and similar projects) should therefore be
OpenStack big tent projects, rather than Neutron stadium, and hence the
reviews I've just left.

Regards,
Neil


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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Neil Jerram]

On 05/02/16 10:59, Thierry Carrez wrote:
> Hi everyone,
>
> Even before OpenStack had a name, our "Four Opens" principles were 
> created to define how we would operate as a community. The first open, 
> "Open Source", added the following precision: "We do not produce 'open 
> core' software". What does this mean in 2016 ?
>
> Back in 2010 when OpenStack was started, this was a key difference with 
> the other open source cloud platform (Eucalyptus) which was following an 
> Open Core strategy with a crippled community edition and an "enterprise 
> version". OpenStack was then the property of a single entity 
> (Rackspace), so giving strong signals that we would never follow such a 
> strategy was essential to form a real community.
>
> Fast-forward today, the open source project is driven by a non-profit 
> independent Foundation, which could not even do an "enterprise edition" 
> if it wanted to. However, member companies build "enterprise products" 
> on top of the Apache-licensed upstream project. And we have drivers that 
> expose functionality in proprietary components. So what does it mean to 
> "not do open core" in 2016 ? What is acceptable and what's not ? It is 
> time for us to refresh this.
>
> My personal take on that is that we can draw a line in the sand for what 
> is acceptable as an official project in the upstream OpenStack open 
> source effort. It should have a fully-functional, production-grade open 
> source implementation. If you need proprietary software or a commercial 
> entity to fully use the functionality of a project or getting serious 
> about it, then it should not be accepted in OpenStack as an official 
> project. It can still live as a non-official project and even be hosted 
> under OpenStack infrastructure, but it should not be part of 
> "OpenStack". That is how I would interpret "no open core" in OpenStack 2016.
>
> Of course, the devil is in the details, especially around what I mean by 
> "fully-functional" and "production-grade". Is it just an API/stability 
> thing, or does performance/scalability come into account ? There will 
> always be some subjectivity there, but I think it's a good place to start.
>
> Comments ?
>

This sounds right to me.

It looks like there may soon be a group of projects wanting to move from
Neutron stadium governance to OpenStack big tent governance, and I
presume this criterion should apply to those too.

Neil


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

Re: [openstack-dev] [grenade][keystone] Keystone multinode grenade

[Morgan Fainberg]

On Fri, Feb 5, 2016 at 6:06 AM, Sean Dague  wrote:

> On 02/05/2016 04:44 AM, Grasza, Grzegorz wrote:
> >
> >
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >>
> >> On 02/04/2016 10:25 AM, Grasza, Grzegorz wrote:
> >>>
> >>> Keystone is just one service, but we want to run a test, in which it
> >>> is setup in HA – two services running at different versions, using the
> same
> >> DB.
> >>
> >> Let me understand the scenario correctly.
> >>
> >> There would be Keystone Liberty and Keystone Mitaka, both talking to a
> >> Liberty DB?
> >>
> >
> > The DB would be upgraded to Mitaka. From Mitaka onwards, we are making
> only additive schema changes, so that both versions can work simultaneously.
> >
> > Here are the specifics:
> >
> http://docs.openstack.org/developer/keystone/developing.html#online-migration
>
> Breaking this down, it seems like there is a simpler test setup here.
>
> Master keystone is already tested with master db, all over the place. In
> unit tests all the dsvm jobs. So we can assume pretty hard that that works.
>
> Keystone doesn't cross talk to itself (as there are no workers), so I
> don't think there is anything to test there.
>
> Keystone stable working with master db seems like an interesting bit,
> are there already tests for that?
>
>
There are currently no working tests for this and due to a lot of
discussion on the difficulty around this (extensively discussed at the
keystone midcycle), moves towards this type of support have been deferred
to Newton.


> Also, is there any time where you'd get data from Keystone new use it in
> a server, and then send it back to Keystone old, and have a validation
> issue? That seems easier to trigger edge cases at a lower level. Like an
> extra attribute is in a payload in Keystone new, and Keystone old
> faceplants with it.
>
>
The general consensus was that this is a *very* hard problem. And we may
need something like microversions before we can support mixed versions of
keystone behind a single LB. We're likely to say "you can upgrade all
running keystone code, then migrate the db, but running mixed versions wont
be supported" as a starting point.


> The reality is that standing up an HA Proxy Keystone multinode
> environment is going to be pretty extensive amount of work. And when
> things fail, digging out why, is kind of hard. However it feels like
> most of the interesting edges can be tested well at a lower level. And
> is at least worth getting those sorted before biting off the bigger thing.
>

++ We do need this for some other multi-node tesitng (keystone-to-keystone
auth for example). So this benefits more than the SQL-schema specifics.

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> wrote:
> 
> > So, is Poppy "open core"?
> >
> 
> It doesn't follow the 'spirit' of open core, but it does have some of the
> characteristics, in that the open code is not all that useful, or maybe
> even testable, without the commercial component(s) (at this time).
> 
> So while Poppy may not fully qualify for the open core label, it still
> fails some of the tests that we want to see, such as a usable open source
> implementation.
> 
> dt
> 

Testability is certainly an issue. There are ways to deal with the
limitations, though. Is it any different from the other third-party
CI we support for hardware drivers? Maybe it means no project wants
to rely on Poppy because there's no way to set up integration tests.
That's OK. We have other projects that don't have dependencies.

I'm not comfortable separating the intent aspect of the definition
of "open core" from the effect. We set rules for the community to
codify the culture and to discourage bad behavior. Nothing the Poppy
team has done qualifies as bad behavior. What is the point of
penalizing them with a strict interpretation of a rule meant to
address a different problem?

Doug

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

Re: [openstack-dev] [all] the trouble with names

[Tim Bell]

On 05/02/16 20:09, "Jay Pipes"  wrote:

>On 02/05/2016 08:38 AM, Dean Troyer wrote:
>> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote:
>>
>> I think this discussion is dancing around the edges of a referendum on
>> the "duplication" aspect of the big tent.
>>
>> It is also dancing around the separation of 'API' from
>> 'implementation'.  There is a long-standing disagreement on whether
>> OpenStack APIs can/should stand on their own, or simply be defined as
>> 'whatever project Foo implements'.
>
>I think you know my opinion on this matter :)
>
>My belief is that we should have a single curated, consistent, and 
>governed OpenStack API, a reference implementation of that API, and the 
>ability to have competing implementations of that API to encourage 
>innovation.
>
> > We already have seen independent
>> implementations of OpenStack APIs, although not (yet?) as OpenStack
>> projects.  Duplication is already happening in the wild.
>
>I'm aware of multiple competing APIs for the same general problem space 
>(Ceilometer and Monasca are the canonical example of this), but I'm not 
>aware of competing implementations of identical APIs. Could you point us 
>to where this has happened?

SWIFT and Ceph object stores ? There is pretty good compatibility between the 
two solutions such that you can advertise a Ceph object store as SWIFT and not 
have too many problems.

This was one of the areas of concern around the mandatory code for OpenStack 
trademarks. Could a cloud offer a ceph backed object store yet still obtain the 
OpenStack trademark ?

The decision in the management board was that a minimum set of common code was 
required although a future trademark of OpenStack compatible was accepted as a 
possibility.

Tim

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

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

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

[Jeremy Stanley]

On 2016-02-05 03:42:21 + (+), Wang, Shane wrote:
> After discussing with TC members and other community guys, we
> thought March 2-4 might not be a good timing for bug smash. So we
> decided to change the dates to be March 7 - 9 (Monday - Wednesday)
> in R4. Please join our efforts to fix bugs for OpenStack.

It's worth pointing out that this puts the event well after Mitaka
feature freeze, which is traditionally when we stop sending Summit
registration discount codes to new contributors to the release.
Presumably that's not anyone's reason for participating in such an
event, but just wanted to clarify it's my understanding that our
conference organizers aren't prepared for the logistical challenges
of generating extra codes for Bug Smash participants who haven't
otherwise contributed to the release so close to the Summit dates.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Jeremy Stanley]

On 2016-02-05 13:17:40 -0500 (-0500), Doug Hellmann wrote:
[...]
> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
[...]

Considering the openness of software based on the openness of its
prerequisites is complex and fraught with snakepits. There is
unfortunately almost always some level of non-freeness:

To run it, do you need to purchase a computer or similar
infrastructure? Electricity? Cooling?

Will it run on a system which is not littered with non-free
microcode, either uploaded as blobs by the operating system or
perpetually resident as system firmware in (((e)e)p)rom?

Are there systems with board schematics and full parts manifests
published under an open license on which you can run it?

This discussion comes up a lot in other free software communities,
and if we push back on completely freely-licensed and
openly-developed client software which people can use with a
proprietary service and for which there is no alternative open
equivalent service on the market (yet), we need to be prepared to
answer these other questions about where we draw the line on "open
enough."
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all] the trouble with names

[Fox, Kevin M]

Sorry. SWIFT beat you to it. ;)

Kevin

From: gordon chung [g...@live.ca]
Sent: Friday, February 05, 2016 1:00 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] the trouble with names

On 05/02/2016 1:22 PM, Ryan Brown wrote:
> For example, I think "containers" will be one of those words that
> everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for
> projects to say "hm, someone else wants this" would be nice.

too late, magnum[1] beat you to it. i'm not sure what the other docker
projects are using. plenty of alternatives though[2]?

#2 is the lesser of the evils but not by much. if we do choose it, we
need a formalised taxonomy, CADF is one example (see line 2656[3]), and
we need to be specific. it doesn't really solve the issue of projects
that do the same thing but i believe that issue is not part of the
discussion.

regarding some collisions so far, to a certain extent i believe it's
because the projects are really features masquerading as discrete
services. [disclaimer: following might be ignorant, apologies] for
something like backups, i'm not sure why it isn't a part of an existing
services api (compute|blockstorage/.../backup) and why it needs to be
it's own endpoint.

[1] https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L111
[2] http://www.thesaurus.com/browse/container?s=t
[3]
https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

cheers,

--
gord

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

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

Re: [openstack-dev] [Neutron] Evolving the stadium concept

[Armando M.]

On 5 February 2016 at 05:41, Gal Sagie  wrote:

> Armando,
>
> I think that contributing and innovating in Dragonflow to implement
> Neutron in an open way and serve as an  alternative and as an example
> for distributed networking patterns IS driving Neutron forward, i am very
> sad that you fail to see this and try to pick to
> my review/patches count.
>

> Beside the big over head i devote to Dragonflow, due to the fact that it
> really runs as an open source project, i also help and contribute
> as much as i can to OVN and of course my efforts in Kuryr, which to me
> solves a critical and important thing for Neutron and for OpenStack
> in mixed containers environments.
> (And the rest of the time that i try to devote to Neutron and other
> sub-projects, currently still under Neutron big-stadium)
>
> Of course that all of this in addition to my efforts and success to
> convince and assist in bringing more people
> and more companies to contribute in an open way with the community in many
> areas in Neutron (some you are familiar with like the border gateway and
> l2gateway others that you are not..),
> both internally and externally, writing blogs/arranging meetups to promote
> and extend some
> of the above projects visibility and Neutron as such.
>
> Believe me that i truly am passionate about Neutron, OpenStack and open
> source and try my best to help and
> contribute when ever i can and many times not due to my "Job requirement",
> i apologise that this is
> not enough for you, there is only a limited amount of hours in a day :)
>
> However, i truly believe that Dragonflow, and ANY other true open source
> implementation of Neutron helps move
> Neutron forward and i hope to continue do so either as Neutron
> big-stadium, as a big-tent project or as something else.
>

I don't recall pointing at any stats. I appreciate your sales pitch, but
that doesn't change the fact that when looking at features like port
forwarding and tags (stuff that you indeed proposed and that can be
beneficial for the project as a whole), you didn't seem to give them enough
priority, meaning that Neutron core is not a priority for you...but don't
get me wrong...everyone has his/her own priorities.

My point being contributing to Dragonflow/OVN/etc alone is great because it
drives adoption and provide choice, but it is not enough to provide benefit
and value to the rest of projects and initiatives that exist within the
Neutron ecosystem, and use Neutron as a backbone to deliver network
services.

There's a wealth of more or less glamorous activities that the core team is
responsible for and are the true blood of this project. If the heart
doesn't pump out this blood to the limbs, the limbs might as well die.


>
> As i have talked with Russell and explained, to me the Big Stadium was/is
> a way to keep Networking related projects "near"
> the group of people that has the best context to review / help and
> comment, its obviously not working and thats fine, lets
> try something different...
>
>
> On Thu, Feb 4, 2016 at 8:18 PM, Armando M.  wrote:
>
>>
>>
>> On 4 February 2016 at 04:05, Gal Sagie  wrote:
>>
>>> Hi Assaf,
>>>
>>> I think that if we define a certain criteria we need to make sure that
>>> it applies to everyone equally.
>>> and it is well understood.
>>>
>>
>> I must admit I am still waking up and going through the entire logs etc.
>> However I cannot help but point out that one criteria that Russell and
>> other TC people are behind (me included) is the significant 'team overlap'
>> (and I would add it to be for a prolonged amount of time). This doesn't
>> mean just drop the accidental bug fix or enhancement to enable the
>> subproject to work with Neutron or address the odd regression that sneaks
>> in from time to time, but it means driving Neutron forward so that it is
>> beneficial for the project as a whole.
>>
>> If you look at yourself, can you candidly say that you are making an
>> impact to the core of Neutron? You seem you have dropped off the radar in
>> the Mitaka timeframe, and haven't made a lasting impact in the Liberty
>> timeframe. I applaud your Kuryr initiative and your specs proposals, but
>> both are not enough to warrant Dragonflow for inclusion.
>>
>> If the team overlap changes, then great, we'll reassess.
>>
>> That said, I'll continue my discussion on the patch...
>>
>>
>>> I have contributed and still am to both OVN and Dragonflow and hope to
>>> continue do so in the future,
>>> i want to see both of these solutions become a great production grade
>>> open source alternatives.
>>>
>>> I have less experience in open source and in this community from most of
>>> you, but from what i saw users
>>> do take these things into consideration, its hard for a new user and
>>> even not so new to understand the possibilities correctly
>>> specially if we cant even define them ourselves
>>>
>>> Instead of spending time on technology and 

Re: [openstack-dev] [Installation] RHEL-7 devstack installation failed in bootstrap_keystone

[Shinobu Kinjo]

It's better to send this kind of topic to:

 openst...@lists.openstack.org

not *dev* from the next.

Rgds,
Shinobu

- Original Message -
From: "Pradip Mukhopadhyay" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Friday, February 5, 2016 8:17:03 PM
Subject: [openstack-dev] [Installation] RHEL-7 devstack installation failed 
in bootstrap_keystone

Hello, 

In a RHEL-7, getting this error: 

2016-02-05 11:08:00.385 | Discovering versions from the identity service failed 
when creating the password plugin. Attempting to determine version from URL. 
2016-02-05 11:08:00.385 | Could not determine a suitable URL for the plugin 
2016-02-05 11:08:00.403 | + 
/opt/stack/devstack/lib/keystone:bootstrap_keystone:L617: token_id= 
2016-02-05 11:08:00.403 | + 
/opt/stack/devstack/lib/keystone:bootstrap_keystone:L1: exit_trap 
2016-02-05 11:08:00.403 | + ./stack.sh:exit_trap:L474: local r=1 
2016-02-05 11:08:00.404 | ++ ./stack.sh:exit_trap:L475: jobs -p 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L475: jobs= 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L478: [[ -n '' ]] 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L484: kill_spinner 
2016-02-05 11:08:00.404 | + ./stack.sh:kill_spinner:L370: '[' '!' -z '' ']' 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L486: [[ 1 -ne 0 ]] 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L487: echo 'Error on exit' 
2016-02-05 11:08:00.404 | Error on exit 
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L488: generate-subunit 
1454670313 167 fail 
2016-02-05 11:08:00.670 | + ./stack.sh:exit_trap:L489: [[ -z /opt/stack/logs ]] 
2016-02-05 11:08:00.670 | + ./stack.sh:exit_trap:L492: 
/opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs 
2016-02-05 11:08:00.955 | + ./stack.sh:exit_trap:L498: exit 1 


[stack@scson0001301001 devstack]$ uname -a 
Linux scson0001301001.nb.openenglab.netapp.com 3.10.0-229.el7.x86_64 #1 SMP Thu 
Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux 



Any idea how to overcome it? 


Thanks, 
Pradip 



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

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

Re: [openstack-dev] [Openstack] [Installation] RHEL-7 devstack installation failed in bootstrap_keystone

[Steve Martinelli]

I'm assuming this isn't being run on a new machine.

1) Ensure you don't have a clouds.yaml file in ~/.config/openstack
2) Check you don't have any OS_ environment variables when
running ./stack.sh
3) Running ./clean.sh should clean up those two above issues and a bunch
more potential causes

the bootstrap_keystone function doesn't have any OS specific code

stevemar



From:   Shinobu Kinjo 
To: pradip.inte...@gmail.com, openst...@lists.openstack.org
Cc: "OpenStack Development Mailing List \(not for usage questions
\)" 
Date:   2016/02/05 05:05 PM
Subject:Re: [Openstack] [openstack-dev] [Installation] RHEL-7 devstack
installation failed in bootstrap_keystone



It's better to send this kind of topic to:

 openst...@lists.openstack.org

not *dev* from the next.

Rgds,
Shinobu

- Original Message -
From: "Pradip Mukhopadhyay" 
To: "OpenStack Development Mailing List (not for usage questions)"

Sent: Friday, February 5, 2016 8:17:03 PM
Subject: [openstack-dev] [Installation] RHEL-7 devstack installation failed
 in bootstrap_keystone

Hello,

In a RHEL-7, getting this error:

2016-02-05 11:08:00.385 | Discovering versions from the identity service
failed when creating the password plugin. Attempting to determine version
from URL.
2016-02-05 11:08:00.385 | Could not determine a suitable URL for the plugin

2016-02-05 11:08:00.403 |
+ /opt/stack/devstack/lib/keystone:bootstrap_keystone:L617: token_id=
2016-02-05 11:08:00.403 |
+ /opt/stack/devstack/lib/keystone:bootstrap_keystone:L1: exit_trap
2016-02-05 11:08:00.403 | + ./stack.sh:exit_trap:L474: local r=1
2016-02-05 11:08:00.404 | ++ ./stack.sh:exit_trap:L475: jobs -p
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L475: jobs=
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L478: [[ -n '' ]]
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L484: kill_spinner
2016-02-05 11:08:00.404 | + ./stack.sh:kill_spinner:L370: '[' '!' -z '' ']'

2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L486: [[ 1 -ne 0 ]]
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L487: echo 'Error on exit'

2016-02-05 11:08:00.404 | Error on exit
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L488: generate-subunit
1454670313 167 fail
2016-02-05 11:08:00.670 | + ./stack.sh:exit_trap:L489:
[[ -z /opt/stack/logs ]]
2016-02-05 11:08:00.670 |
+ ./stack.sh:exit_trap:L492: /opt/stack/devstack/tools/worlddump.py
-d /opt/stack/logs
2016-02-05 11:08:00.955 | + ./stack.sh:exit_trap:L498: exit 1


[stack@scson0001301001 devstack]$ uname -a
Linux scson0001301001.nb.openenglab.netapp.com 3.10.0-229.el7.x86_64 #1 SMP
Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux



Any idea how to overcome it?


Thanks,
Pradip



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

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openst...@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Anita Kuno]

On 02/05/2016 12:14 PM, Ryan Brown wrote:
> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Even before OpenStack had a name, our "Four Opens" principles were
>> created to define how we would operate as a community. The first open,
>> "Open Source", added the following precision: "We do not produce 'open
>> core' software". What does this mean in 2016 ?
>>
>> Back in 2010 when OpenStack was started, this was a key difference with
>> the other open source cloud platform (Eucalyptus) which was following an
>> Open Core strategy with a crippled community edition and an "enterprise
>> version". OpenStack was then the property of a single entity
>> (Rackspace), so giving strong signals that we would never follow such a
>> strategy was essential to form a real community.
>>
>> Fast-forward today, the open source project is driven by a non-profit
>> independent Foundation, which could not even do an "enterprise edition"
>> if it wanted to. However, member companies build "enterprise products"
>> on top of the Apache-licensed upstream project. And we have drivers that
>> expose functionality in proprietary components. So what does it mean to
>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>> time for us to refresh this.
>>
>> My personal take on that is that we can draw a line in the sand for what
>> is acceptable as an official project in the upstream OpenStack open
>> source effort. It should have a fully-functional, production-grade open
>> source implementation. If you need proprietary software or a commercial
>> entity to fully use the functionality of a project or getting serious
>> about it, then it should not be accepted in OpenStack as an official
>> project. It can still live as a non-official project and even be hosted
>> under OpenStack infrastructure, but it should not be part of
>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>> 2016.
>>
>> Of course, the devil is in the details, especially around what I mean by
>> "fully-functional" and "production-grade". Is it just an API/stability
>> thing, or does performance/scalability come into account ? There will
>> always be some subjectivity there, but I think it's a good place to
>> start.
>>
>> Comments ?
> 
> If a project isn't fully functional* then why would we accept it at all?
> Imagine this scenario:
> 
> 1) Heat didn't exist
> 2) A project exactly like heat applies for OpenStack, that lets you use
> templates to create resources to a specification
> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing
> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse
> templates longer than 200 characters.
> 
> Would *any* TC count that as a project that could join under our current
> system? I don't think so. The TC (and community) would say something
> along the lines of "WTF are you thinking? Go read the 4 opens and try
> again"

I think it is a point of strength that so many in our community
including the TC both individually and collectively are able to
communicate perspectives and decisions without referencing profanity.

So I happen to disagree with your current characterization as worded.

Thank you,
Anita.

> 
> I don't think adding "no open core" would change a decision the
> future-community and future-tc might make, because they will be elected
> by aforementioned community. Adding buzz-requirements like "must be
> fully-functional, production grade, webscale open-cloud softwidgets"
> isn't going to help future-us.
> 
> Footnotes:
> 
> * in my view, an openstack product that requires you to pay a vendor is
> as functional as an openstack product chock-full of syntax errors
> 
> ** Shed Cat Enterprise Leopard is strictly fictional, and not based on
> any company that currently or ever has existed.
> 


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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Sean Dague]

On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
>> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> Even before OpenStack had a name, our "Four Opens" principles were
>>> created to define how we would operate as a community. The first open,
>>> "Open Source", added the following precision: "We do not produce 'open
>>> core' software". What does this mean in 2016 ?
>>>
>>> Back in 2010 when OpenStack was started, this was a key difference with
>>> the other open source cloud platform (Eucalyptus) which was following an
>>> Open Core strategy with a crippled community edition and an "enterprise
>>> version". OpenStack was then the property of a single entity
>>> (Rackspace), so giving strong signals that we would never follow such a
>>> strategy was essential to form a real community.
>>>
>>> Fast-forward today, the open source project is driven by a non-profit
>>> independent Foundation, which could not even do an "enterprise edition"
>>> if it wanted to. However, member companies build "enterprise products"
>>> on top of the Apache-licensed upstream project. And we have drivers that
>>> expose functionality in proprietary components. So what does it mean to
>>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
>>> time for us to refresh this.
>>>
>>> My personal take on that is that we can draw a line in the sand for what
>>> is acceptable as an official project in the upstream OpenStack open
>>> source effort. It should have a fully-functional, production-grade open
>>> source implementation. If you need proprietary software or a commercial
>>> entity to fully use the functionality of a project or getting serious
>>> about it, then it should not be accepted in OpenStack as an official
>>> project. It can still live as a non-official project and even be hosted
>>> under OpenStack infrastructure, but it should not be part of
>>> "OpenStack". That is how I would interpret "no open core" in OpenStack
>>> 2016.
>>>
>>> Of course, the devil is in the details, especially around what I mean by
>>> "fully-functional" and "production-grade". Is it just an API/stability
>>> thing, or does performance/scalability come into account ? There will
>>> always be some subjectivity there, but I think it's a good place to start.
>>>
>>> Comments ?
>>
>> If a project isn't fully functional* then why would we accept it at all? 
>> Imagine this scenario:
>>
>> 1) Heat didn't exist
>> 2) A project exactly like heat applies for OpenStack, that lets you use 
>> templates to create resources to a specification
>> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
>> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
>> templates longer than 200 characters.
> 
> There's a more concrete case being considered right now that is less
> clear to some [1].
> 
> The Poppy project provides an open source service to wrap content
> delivery network APIs. They follow all of our other best-practices,
> but there is apparently no practical open source CDN solution.
> OpenCDN was mentioned, but it seems dead.
> 
> In the absence of any open source solution, the Poppy service is
> only useful when connected to commercial services. The Poppy team
> has provided drivers for several of these (I see akamai, cloudfront,
> fastly, and maxcdn in their "providers" package). Stackalytics shows
> the contributors on the team are mostly from Rackspace[2].  I'm not
> aware of Rackspace owning any of those services, though I'm sure
> they have relationships with one more more.
> 
> My understanding of the "no open core" requirement is about the
> intent of the contributor.  We don't want separate community and
> "enterprise" editions of components (services or drivers).  The
> Poppy situation doesn't seem to be a case of open washing anything,
> or holding back features in order to sell a more advanced version.
> It happens that for Poppy to be useful, you have to buy another
> service for it to talk to (and to serve your data), but all of the
> Poppy code is actually open and there are several services to choose
> from.  There is no "better" version of Poppy available for sale,
> if you buy a PoppyCDN subscription.
> 
> So, is Poppy "open core"?

Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
Source Cloud Platform. Because it only enables the use of commerical
services.

It's fine that it's open source software. I just don't think it's OpenStack.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 12:27 Feb 05, Dean Troyer wrote:
> On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> wrote:
> 
> > So, is Poppy "open core"?
> >
> 
> It doesn't follow the 'spirit' of open core, but it does have some of the
> characteristics, in that the open code is not all that useful, or maybe
> even testable, without the commercial component(s) (at this time).
> 
> So while Poppy may not fully qualify for the open core label, it still
> fails some of the tests that we want to see, such as a usable open source
> implementation.

>From a QA perspective in gate, if we have to rely on a commercial solution
(even if donated) to test it, then that's bad.

-- 
Mike Perez

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

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

[Andrey Pavlov]

As I know 'swift3' project implements S3 for OpenStack over swift. Or
your mention something other?
(but it doesn't support some features - signature v4 for instance)

Andrey.

On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
>
>
>
>
>
> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
>
>>Can it be implemented as keystone plugin?
>>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>>Will this code use keystone DB or it should create own?
>>
>>So we will need one 'auth' module for swift3/ec2-api.
>>Sounds good but we need to understand some details before implementation.
>>
>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  
>>wrote:
>>>
>>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:

 swift3(s3) works like ec2-api.

 1. swift3/ec2-api recieves AWS request
 2. it parses signature and access_key (and other headers)
 3. it sends these values (and token that calculated from request) to
 keystone
 4. keystone gets secret_key from DB, then calculates signature by
 recieved access_key and token
 5. keystone compares recived signature and claculated signature and
 then return 'error' or auth_token
 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
 or continues execution
 7. in case of continue swift3/ec2-api uses recieved auth_token for
 calls other services: nova, cinder, neutron, swift...

 So I don't understand how implement this functionality outside of
 keystone...
>>>
>>>
>>> EC2 support is implemented in middleware on top of keystone, and that
>>> middleware happens to live in the openstack/keystone repository. This change
>>> is just proposing to move that middleware code into a dedicated new
>>> repository and change the community support & maintenance model - it would
>>> not affect how the code actually operates. The only affect on operators is
>>> that it would require an extra step to deploy it. End users would not be
>>> affected.
>>>
>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>>>
>>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>
> However, looking at the current state of deployments, the EC2-API is close to 
> production ready, CERN has been working with the community to get an RPM 
> package and a Puppet module for configuring it at scale.
>
> In comparison, the equivalent S3 support would need some further effort to 
> develop an S3-API project, package and configure it. Given the CERN EC2 
> experience, this is several months of work.
>
> Thus, I have no problem with a message saying this function is on the way out 
> but there is currently no equivalent function for S3 support (or project 
> ownership to implement it). I would advise to address these questions before 
> we start on the road to deprecation on the same time scales as the EC2 
> functions.
>
> Removing function without a migration/alternative would be unpopular with the 
> user community. According to 
> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
>  around 29% of production sites use S3. Personally, that feels a bit high but 
> it does give an indication of the deployment level.
>
> How about we split the EC2 deprecation from the S3 one ?
>
> Tim
>
>
>>>


 On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
 >
 >>
 >> Is it certain that there is no need for the functions with the new
 >> EC2-API
 >> functions ?
 >>
 >> The S3 functions are somewhat separated from the EC2 API. How does
 >> SWIFT
 >> implement the S3 compatibility layer ?
 >>
 >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
 >> make
 >> sure we’re not using it somewhere else.
 >>
 >
 > This would be just a deprecation warning. Removal would be determined at
 > a
 > later time with sufficient lead time.
 >
 > Do you know how S3 with SWIFT works ? Would they need to do something
 > like
 > EC2-API ?
 >
 > Tim
 >
 >
 > __
 > OpenStack Development Mailing List (not for usage questions)
 > Unsubscribe:
 > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >



 --
 Kind regards,
 Andrey Pavlov.

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

[openstack-dev] [cinder] v2 image upload from url

[Fox, Kevin M]

We've been using the upload image from http url for a long time and when we 
upgraded to liberty we noticed it broke because the client's defaulting to v2 
now. How do you do image upload via http with v2? Is there a different 
command/method?

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

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

Does Swift3 (for S3 on SWIFT) need Keystone or is it independent ?

Tim



On 05/02/16 20:57, "Andrey Pavlov"  wrote:

>As I know 'swift3' project implements S3 for OpenStack over swift. Or
>your mention something other?
>(but it doesn't support some features - signature v4 for instance)
>
>Andrey.
>
>On Fri, Feb 5, 2016 at 10:46 PM, Tim Bell  wrote:
>>
>>
>>
>>
>>
>> On 05/02/16 20:15, "Andrey Pavlov"  wrote:
>>
>>>Can it be implemented as keystone plugin?
>>>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>>>Will this code use keystone DB or it should create own?
>>>
>>>So we will need one 'auth' module for swift3/ec2-api.
>>>Sounds good but we need to understand some details before implementation.
>>>
>>>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  
>>>wrote:

 On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>
> swift3(s3) works like ec2-api.
>
> 1. swift3/ec2-api recieves AWS request
> 2. it parses signature and access_key (and other headers)
> 3. it sends these values (and token that calculated from request) to
> keystone
> 4. keystone gets secret_key from DB, then calculates signature by
> recieved access_key and token
> 5. keystone compares recived signature and claculated signature and
> then return 'error' or auth_token
> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
> or continues execution
> 7. in case of continue swift3/ec2-api uses recieved auth_token for
> calls other services: nova, cinder, neutron, swift...
>
> So I don't understand how implement this functionality outside of
> keystone...


 EC2 support is implemented in middleware on top of keystone, and that
 middleware happens to live in the openstack/keystone repository. This 
 change
 is just proposing to move that middleware code into a dedicated new
 repository and change the community support & maintenance model - it would
 not affect how the code actually operates. The only affect on operators is
 that it would require an extra step to deploy it. End users would not be
 affected.

 https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27

 https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>>
>>
>> However, looking at the current state of deployments, the EC2-API is close 
>> to production ready, CERN has been working with the community to get an RPM 
>> package and a Puppet module for configuring it at scale.
>>
>> In comparison, the equivalent S3 support would need some further effort to 
>> develop an S3-API project, package and configure it. Given the CERN EC2 
>> experience, this is several months of work.
>>
>> Thus, I have no problem with a message saying this function is on the way 
>> out but there is currently no equivalent function for S3 support (or project 
>> ownership to implement it). I would advise to address these questions before 
>> we start on the road to deprecation on the same time scales as the EC2 
>> functions.
>>
>> Removing function without a migration/alternative would be unpopular with 
>> the user community. According to 
>> http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
>>  around 29% of production sites use S3. Personally, that feels a bit high 
>> but it does give an indication of the deployment level.
>>
>> How about we split the EC2 deprecation from the S3 one ?
>>
>> Tim
>>
>>

>
>
> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
> >
> >>
> >> Is it certain that there is no need for the functions with the new
> >> EC2-API
> >> functions ?
> >>
> >> The S3 functions are somewhat separated from the EC2 API. How does
> >> SWIFT
> >> implement the S3 compatibility layer ?
> >>
> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
> >> make
> >> sure we’re not using it somewhere else.
> >>
> >
> > This would be just a deprecation warning. Removal would be determined at
> > a
> > later time with sufficient lead time.
> >
> > Do you know how S3 with SWIFT works ? Would they need to do something
> > like
> > EC2-API ?
> >
> > Tim
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Kind regards,
> Andrey Pavlov.
>
> 

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Doug Hellmann]

Excerpts from Sean Dague's message of 2016-02-05 14:16:12 -0500:
> On 02/05/2016 01:17 PM, Doug Hellmann wrote:
> > Excerpts from Ryan Brown's message of 2016-02-05 12:14:34 -0500:
> >> On 02/05/2016 05:57 AM, Thierry Carrez wrote:
> >>> Hi everyone,
> >>>
> >>> Even before OpenStack had a name, our "Four Opens" principles were
> >>> created to define how we would operate as a community. The first open,
> >>> "Open Source", added the following precision: "We do not produce 'open
> >>> core' software". What does this mean in 2016 ?
> >>>
> >>> Back in 2010 when OpenStack was started, this was a key difference with
> >>> the other open source cloud platform (Eucalyptus) which was following an
> >>> Open Core strategy with a crippled community edition and an "enterprise
> >>> version". OpenStack was then the property of a single entity
> >>> (Rackspace), so giving strong signals that we would never follow such a
> >>> strategy was essential to form a real community.
> >>>
> >>> Fast-forward today, the open source project is driven by a non-profit
> >>> independent Foundation, which could not even do an "enterprise edition"
> >>> if it wanted to. However, member companies build "enterprise products"
> >>> on top of the Apache-licensed upstream project. And we have drivers that
> >>> expose functionality in proprietary components. So what does it mean to
> >>> "not do open core" in 2016 ? What is acceptable and what's not ? It is
> >>> time for us to refresh this.
> >>>
> >>> My personal take on that is that we can draw a line in the sand for what
> >>> is acceptable as an official project in the upstream OpenStack open
> >>> source effort. It should have a fully-functional, production-grade open
> >>> source implementation. If you need proprietary software or a commercial
> >>> entity to fully use the functionality of a project or getting serious
> >>> about it, then it should not be accepted in OpenStack as an official
> >>> project. It can still live as a non-official project and even be hosted
> >>> under OpenStack infrastructure, but it should not be part of
> >>> "OpenStack". That is how I would interpret "no open core" in OpenStack
> >>> 2016.
> >>>
> >>> Of course, the devil is in the details, especially around what I mean by
> >>> "fully-functional" and "production-grade". Is it just an API/stability
> >>> thing, or does performance/scalability come into account ? There will
> >>> always be some subjectivity there, but I think it's a good place to start.
> >>>
> >>> Comments ?
> >>
> >> If a project isn't fully functional* then why would we accept it at all? 
> >> Imagine this scenario:
> >>
> >> 1) Heat didn't exist
> >> 2) A project exactly like heat applies for OpenStack, that lets you use 
> >> templates to create resources to a specification
> >> 3) BUT, if you don't buy Proprietary Enterprise Template Parsing 
> >> Platform 9, a product of Shed Cat Enterpise Leopards**, you can't parse 
> >> templates longer than 200 characters.
> > 
> > There's a more concrete case being considered right now that is less
> > clear to some [1].
> > 
> > The Poppy project provides an open source service to wrap content
> > delivery network APIs. They follow all of our other best-practices,
> > but there is apparently no practical open source CDN solution.
> > OpenCDN was mentioned, but it seems dead.
> > 
> > In the absence of any open source solution, the Poppy service is
> > only useful when connected to commercial services. The Poppy team
> > has provided drivers for several of these (I see akamai, cloudfront,
> > fastly, and maxcdn in their "providers" package). Stackalytics shows
> > the contributors on the team are mostly from Rackspace[2].  I'm not
> > aware of Rackspace owning any of those services, though I'm sure
> > they have relationships with one more more.
> > 
> > My understanding of the "no open core" requirement is about the
> > intent of the contributor.  We don't want separate community and
> > "enterprise" editions of components (services or drivers).  The
> > Poppy situation doesn't seem to be a case of open washing anything,
> > or holding back features in order to sell a more advanced version.
> > It happens that for Poppy to be useful, you have to buy another
> > service for it to talk to (and to serve your data), but all of the
> > Poppy code is actually open and there are several services to choose
> > from.  There is no "better" version of Poppy available for sale,
> > if you buy a PoppyCDN subscription.
> > 
> > So, is Poppy "open core"?
> 
> Whether or not it is, I'm not sure how it is part of a Ubiquitous Open
> Source Cloud Platform. Because it only enables the use of commerical
> services.
> 
> It's fine that it's open source software. I just don't think it's OpenStack.
> 
> -Sean

I don't understand the connection you're making.

Doug

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [keystone][ec2-api][swift] Moving EC2 Auth and S3Token to Externally supported

[Tim Bell]

On 05/02/16 20:15, "Andrey Pavlov"  wrote:

>Can it be implemented as keystone plugin?
>Is it possible to 'get' AUTH_TOKEN outside of keystone?
>Will this code use keystone DB or it should create own?
>
>So we will need one 'auth' module for swift3/ec2-api.
>Sounds good but we need to understand some details before implementation.
>
>On Fri, Feb 5, 2016 at 10:03 PM, Dolph Mathews  wrote:
>>
>> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov  wrote:
>>>
>>> swift3(s3) works like ec2-api.
>>>
>>> 1. swift3/ec2-api recieves AWS request
>>> 2. it parses signature and access_key (and other headers)
>>> 3. it sends these values (and token that calculated from request) to
>>> keystone
>>> 4. keystone gets secret_key from DB, then calculates signature by
>>> recieved access_key and token
>>> 5. keystone compares recived signature and claculated signature and
>>> then return 'error' or auth_token
>>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>>> or continues execution
>>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>>> calls other services: nova, cinder, neutron, swift...
>>>
>>> So I don't understand how implement this functionality outside of
>>> keystone...
>>
>>
>> EC2 support is implemented in middleware on top of keystone, and that
>> middleware happens to live in the openstack/keystone repository. This change
>> is just proposing to move that middleware code into a dedicated new
>> repository and change the community support & maintenance model - it would
>> not affect how the code actually operates. The only affect on operators is
>> that it would require an extra step to deploy it. End users would not be
>> affected.
>>
>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>>
>> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31


However, looking at the current state of deployments, the EC2-API is close to 
production ready, CERN has been working with the community to get an RPM 
package and a Puppet module for configuring it at scale.

In comparison, the equivalent S3 support would need some further effort to 
develop an S3-API project, package and configure it. Given the CERN EC2 
experience, this is several months of work.

Thus, I have no problem with a message saying this function is on the way out 
but there is currently no equivalent function for S3 support (or project 
ownership to implement it). I would advise to address these questions before we 
start on the road to deprecation on the same time scales as the EC2 functions. 

Removing function without a migration/alternative would be unpopular with the 
user community. According to 
http://superuser.openstack.org/articles/openstack-users-share-how-their-deployments-stack-up,
 around 29% of production sites use S3. Personally, that feels a bit high but 
it does give an indication of the deployment level.

How about we split the EC2 deprecation from the S3 one ?

Tim


>>
>>>
>>>
>>> On Fri, Feb 5, 2016 at 8:55 PM, Tim Bell  wrote:
>>> >
>>> >>
>>> >> Is it certain that there is no need for the functions with the new
>>> >> EC2-API
>>> >> functions ?
>>> >>
>>> >> The S3 functions are somewhat separated from the EC2 API. How does
>>> >> SWIFT
>>> >> implement the S3 compatibility layer ?
>>> >>
>>> >> Getting a ‘to be deprecated’ log entry into Mitaka would be useful to
>>> >> make
>>> >> sure we’re not using it somewhere else.
>>> >>
>>> >
>>> > This would be just a deprecation warning. Removal would be determined at
>>> > a
>>> > later time with sufficient lead time.
>>> >
>>> > Do you know how S3 with SWIFT works ? Would they need to do something
>>> > like
>>> > EC2-API ?
>>> >
>>> > Tim
>>> >
>>> >
>>> > __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Kind regards,
>>> Andrey Pavlov.
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>-- 
>Kind regards,
>Andrey Pavlov.
>
>__

[openstack-dev] RFC 2616 was *so* 2010

[Clay Gerrard]

... really more like 1999, but when OpenStack started back in '10 - RFC
2616 was the boss.

Since then (circa '14) we've got 7230 et. al. - a helpful attempt to
disambiguate things!  Hooray progress!

But when someone recently opened this bug I got confused:

https://bugs.launchpad.net/swift/+bug/1537811

The wording is 7230 *is* in fact pretty clear - MUST NOT [send a
content-length header, zero or otherwise, with a 204 response] - but I
really can't find nearly as strong a prescription in 2616.

Swift is burdened with a long lived, stable API - which has lead to wide
adoption from a large ecosystem of clients that have for better or worse
often adopted the practice of expecting the API to behave the way it does
even when we might otherwise agree it has a wart here or there.

But I'm less worried about the client part - we've handled that plenty of
times in the past - ultimately it's a value/risk trade off.  Can we fix it
without breaking anything - if we do break someone what's the risk of that
fallout vs. the value of cleaning it up now (in this particular example RFC
7230 is equally strongly prescriptive of clients, in that we should be able
to say "content-length: booberries" in a 204 response and a well behaved
client is expected to ignore the header and know that the 204 response is
terminated with the first blank line following the headers).  Again, we've
handled this before and I'm sure we'll make the right choice for our
project and broad client base.

But I *am* worried about RFC 7230!?  Is it reasonable that a HTTP 1.1
compliant server according to 2616 could possibly NOT be a HTTP 1.1
compliant server after 7230?  Should the wording of this particular
prescription be SHOULD NOT (is that even possible?!  I think I read
somewhere that RFC's can have revisions; but I always just pretend they're
like some sort of divine law which must be followed or face eternal scorn
from your fellow engineers)  Maybe sending a "content-length: 0" header
with a 204 response was *never* tolerable (despite being descriptive and
innocuous), but you just couldn't tell you weren't conforming because of
all the reasons 7230 got drafted in the first place!?  Does anyone know how
to get ahold of Mark Nottingham so he can explain to me how all this works?

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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Salvatore Orlando]

On 5 February 2016 at 17:58, Neil Jerram  wrote:

> On 05/02/16 16:31, Pavel Bondar wrote:
> > On 05.02.2016 12:28, Salvatore Orlando wrote:
> >>
> >>
> >> On 5 February 2016 at 04:12, Armando M.  >> > wrote:
> >>
> >>
> >>
> >> On 4 February 2016 at 08:22, John Belamaric
> >> <jbelama...@infoblox.com> wrote:
> >>
> >>
> >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin  > wrote:
> >> >
> >> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar <
> pbon...@infoblox.com > wrote:
> >> >> I am trying to bring more attention to [1] to make final
> decision on
> >> >> approach to use.
> >> >> There are a few point that are not 100% clear for me at this
> point.
> >> >>
> >> >> 1) Do we plan to switch all current clouds to pluggable ipam
> >> >> implementation in Mitaka?
>
> I possibly shouldn't comment at all, as I don't know the history, and
> wasn't around when the fundamental design decisions here were being made.
>
> However, it seems a shame to me that this was done in a way that needs a
> DB migration at all.  (And I would have thought it possible for the
> default pluggable IPAM driver to use the same DB state as the
> non-pluggable IPAM backend, given that it is delivering the same
> semantics.)  Without that, I believe it should be a no-brainer to switch
> unconditionally to the pluggable IPAM backend.
>

This was indeed the first implementation attempt that we made, but it
failed spectacularly as we wrestled with different foreign key
relationships in the original and new model.
Pavel has all the details, but after careful considerations we decided to
adopt a specular model with different db tables.


>
> Sorry if that's unhelpful...
>
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] the trouble with names

[gordon chung]

On 05/02/2016 1:22 PM, Ryan Brown wrote:
> For example, I think "containers" will be one of those words that
> everyone wants to use (buzzbuzzbuzzbuzz). Having at least a way for
> projects to say "hm, someone else wants this" would be nice.

too late, magnum[1] beat you to it. i'm not sure what the other docker 
projects are using. plenty of alternatives though[2]?

#2 is the lesser of the evils but not by much. if we do choose it, we 
need a formalised taxonomy, CADF is one example (see line 2656[3]), and 
we need to be specific. it doesn't really solve the issue of projects 
that do the same thing but i believe that issue is not part of the 
discussion.

regarding some collisions so far, to a certain extent i believe it's 
because the projects are really features masquerading as discrete 
services. [disclaimer: following might be ignorant, apologies] for 
something like backups, i'm not sure why it isn't a part of an existing 
services api (compute|blockstorage/.../backup) and why it needs to be 
it's own endpoint.

[1] https://github.com/openstack/magnum/blob/master/devstack/lib/magnum#L111
[2] http://www.thesaurus.com/browse/container?s=t
[3] 
https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf

cheers,

-- 
gord

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

Re: [openstack-dev] [all] the trouble with names

[Sean Dague]

On 02/05/2016 02:09 PM, Jay Pipes wrote:
> On 02/05/2016 08:38 AM, Dean Troyer wrote:
>> On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > > wrote:
>>
>> I think this discussion is dancing around the edges of a
>> referendum on
>> the "duplication" aspect of the big tent.
>>
>> It is also dancing around the separation of 'API' from
>> 'implementation'.  There is a long-standing disagreement on whether
>> OpenStack APIs can/should stand on their own, or simply be defined as
>> 'whatever project Foo implements'.
> 
> I think you know my opinion on this matter :)
> 
> My belief is that we should have a single curated, consistent, and
> governed OpenStack API, a reference implementation of that API, and the
> ability to have competing implementations of that API to encourage
> innovation.

I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.

>From that we can move towards any implementation needed for that.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [api] microversion spec

[michael mccune]

On 02/03/2016 10:23 AM, Morgan Fainberg wrote:



On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague > wrote:

I've been looking through the reviews on and where it's gotten to -

https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst


A couple of questions / concerns.

There was major push back from API-WG on 'API' itself being in the
headers. What is the data on what services are already doing? My
understanding is this is convention for all every service so far, mostly
because that's how we did it in Nova. Forcing a header change for that
seems massively bike shed. There is zero value gained in such a change
by anyone, and just confusion.



i don't see a conflict with the guideline proposing removing API from 
the header. if nova moves to support both headers in the future that 
would be awesome, but not strictly necessary.


i think what we wanted was to make sure that new projects will be on the 
same page about this. (although, i can understand that they will cry 
"but nova doesn't do that")



On moving from code names to service types, I'm completely onboard with
that providing value. However there is a bigger issue about the fact
that service types don't really have a central registry. That's why Nova
didn't do this up front because that's a whole other thing to figure out
which has some really big implications on our community.

Code names are self namespaced because they are based on git repo -
openstack/nova, openstack/ironic. We get a registry for free that won't
have conflicts.

I actually agree these should be service types, however, that requires
understanding how service types are going to be handed out. Having a
project just start using 'monitoring' or 'policy' as a service type is
going to go poorly in the long term when they get told they have to
change that, and now all their clients are broken.


As part of the new catalog (x-project) spec we will also need the
central registry for deconflicting. If you're talking to "compute" via
the catalog, it needs to always be nova. I would like to see this be the
service types. For the projects that have used the code-names for now
they can support either/or favouring the new service type one in the
long term.

Since we already need to solve this one way, we should use the same data
that is going to be in the catalog for this header.


agreed about the need for a registry, or something, to help coordinate 
the service type names. as stated in the other thread about naming[1], 
i'm ok with starting to work on some sort of plan for the api-wg to 
assist in the registration efforts, but that will take some time.


in the short term, i think we should forge ahead with standardizing on 
service type, and when the registry, or w/e, exists we can start to 
bring things into congruence with each other.


regards,
mike

[1]: 
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085748.html



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

Re: [openstack-dev] [api] microversion spec

[Sean Dague]

On 02/05/2016 03:00 PM, michael mccune wrote:
> On 02/03/2016 10:23 AM, Morgan Fainberg wrote:
>>
>>
>> On Wed, Feb 3, 2016 at 3:49 AM, Sean Dague > > wrote:
>>
>> I've been looking through the reviews on and where it's gotten to -
>>
>> https://review.openstack.org/#/c/243429/4/guidelines/microversion_specification.rst
>>
>>
>>
>> A couple of questions / concerns.
>>
>> There was major push back from API-WG on 'API' itself being in the
>> headers. What is the data on what services are already doing? My
>> understanding is this is convention for all every service so far,
>> mostly
>> because that's how we did it in Nova. Forcing a header change for
>> that
>> seems massively bike shed. There is zero value gained in such a
>> change
>> by anyone, and just confusion.
>>
> 
> i don't see a conflict with the guideline proposing removing API from
> the header. if nova moves to support both headers in the future that
> would be awesome, but not strictly necessary.
> 
> i think what we wanted was to make sure that new projects will be on the
> same page about this. (although, i can understand that they will cry
> "but nova doesn't do that")

I feel like if we are going for consistency, then we need to think about
what's out there as well.

Consistency trumps purity. An extra 4 letters which are strictly not
needed, but are at least consistent across projects, is much less of an
issue to consumers than it being different between old / new headers or
different services. And becomes something everyone has to look up every
time they write an implementation, vs. knowing how they all work, and
just iterating on name.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] [keystone][ec2-api] Moving EC2 Auth and S3Token to Externally supported

[Brant Knudson]

On Fri, Feb 5, 2016 at 1:03 PM, Dolph Mathews 
wrote:

>
> On Fri, Feb 5, 2016 at 12:37 PM, Andrey Pavlov 
> wrote:
>
>> swift3(s3) works like ec2-api.
>>
>> 1. swift3/ec2-api recieves AWS request
>> 2. it parses signature and access_key (and other headers)
>> 3. it sends these values (and token that calculated from request) to
>> keystone
>> 4. keystone gets secret_key from DB, then calculates signature by
>> recieved access_key and token
>> 5. keystone compares recived signature and claculated signature and
>> then return 'error' or auth_token
>> 6. swift3/ec2-api recieves answer from keystone and return 'forbidden'
>> or continues execution
>> 7. in case of continue swift3/ec2-api uses recieved auth_token for
>> calls other services: nova, cinder, neutron, swift...
>>
>> So I don't understand how implement this functionality outside of
>> keystone...
>>
>
> EC2 support is implemented in middleware on top of keystone, and that
> middleware happens to live in the openstack/keystone repository. This
> change is just proposing to move that middleware code into a dedicated new
> repository and change the community support & maintenance model - it would
> not affect how the code actually operates. The only affect on operators is
> that it would require an extra step to deploy it. End users would not be
> affected.
>
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/keystone/contrib/ec2/routers.py#L27
>
>
> https://github.com/openstack/keystone/blob/5f51912b54dff0a71f00987e9f5c1d6015ad08bd/etc/keystone-paste.ini#L27-L31
>
>

One of the things that prompted this discussion is a proposal to make EC2
and S3 required, and not removable by editing the paste config:
https://review.openstack.org/#/c/274973/

Some of us were taking advantage of this ability, but others think that all
APIs should be supported.

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

Re: [openstack-dev] [all] the trouble with names

[Jay Pipes]

#2

On 02/05/2016 02:24 PM, Sean Dague wrote:

On 02/05/2016 02:09 PM, Jay Pipes wrote:

On 02/05/2016 08:38 AM, Dean Troyer wrote:

On Fri, Feb 5, 2016 at 7:00 AM, Chris Dent > wrote:

 I think this discussion is dancing around the edges of a
referendum on
 the "duplication" aspect of the big tent.

It is also dancing around the separation of 'API' from
'implementation'.  There is a long-standing disagreement on whether
OpenStack APIs can/should stand on their own, or simply be defined as
'whatever project Foo implements'.


I think you know my opinion on this matter :)

My belief is that we should have a single curated, consistent, and
governed OpenStack API, a reference implementation of that API, and the
ability to have competing implementations of that API to encourage
innovation.


I feel like this is gone a bit "dead horse" of track from the question
at hand. Which brings us in danger of ending up on solution #3 (do
nothing, we're all burned out from having to discuss things anyway, lets
farm goats).

I'd ask for folks to try to stay on the original question:

What possible naming standards could we adopt, and what are the preferences.

 From that we can move towards any implementation needed for that.

-Sean



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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Mike Perez]

On 14:41 Feb 05, Doug Hellmann wrote:
> Excerpts from Dean Troyer's message of 2016-02-05 12:27:44 -0600:
> > On Fri, Feb 5, 2016 at 12:17 PM, Doug Hellmann 
> > wrote:
> > 
> > > So, is Poppy "open core"?
> > >
> > 
> > It doesn't follow the 'spirit' of open core, but it does have some of the
> > characteristics, in that the open code is not all that useful, or maybe
> > even testable, without the commercial component(s) (at this time).
> > 
> > So while Poppy may not fully qualify for the open core label, it still
> > fails some of the tests that we want to see, such as a usable open source
> > implementation.
> > 
> > dt
> > 
> 
> Testability is certainly an issue. There are ways to deal with the
> limitations, though. Is it any different from the other third-party
> CI we support for hardware drivers? Maybe it means no project wants
> to rely on Poppy because there's no way to set up integration tests.
> That's OK. We have other projects that don't have dependencies.

Yes it is different. Because the other examples like Cinder is there is an open
source solution that is available that could potentionally do the feature
proposed by a commercial solution, and therefore can be tested by anyone who
wants to install the free solution, in addition to see the results by third
party ci logs. (I say it this way because we haven't been good about making
sure certain features are available by ceph. Some are just impossible in the
reference implementation LVM)

> I'm not comfortable separating the intent aspect of the definition
> of "open core" from the effect. We set rules for the community to
> codify the culture and to discourage bad behavior. Nothing the Poppy
> team has done qualifies as bad behavior. What is the point of
> penalizing them with a strict interpretation of a rule meant to
> address a different problem?

As I've mentioned in previous replies of this thread it's about how the
community can test a project. If we have to depend on a commercial entity to do
tests on the main features of a project, I see that as a problem.

I'm with Sean where I see this as not fitting with what the community is trying
to bring in based on what the TC has set in the governance, and what has
already been raised in this discussion.

-- 
Mike Perez

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

Re: [openstack-dev] [neutron][db]Why can't I see ports which belongs router's gateway?

[Anna Kamyshnikova]

Hi!

How do you try to get details about it? I don't have any problems with
that, see http://paste.openstack.org/show/486069/

On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang  wrote:

> hi, all.
> Neutron will create a port when setting router gateway to a router.
> This port's device_owner is "network:router_gateway". And, I can see this
> port in db.
>
> But, why cmd says "Unable to find port with name xxx" when I want to
> get the detail info about this port?
>
> Does there some special reasons?
>
> Thanks
> Zhi Chang
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Evgeniy L]

Simon,

>> Any plan to have a nicer experience in future Fuel releases?

I haven't heard about any plans on improvements for that, but management
team should know better whether it's on roadmap or not.

Thanks,

On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier 
wrote:

> Thanks Evgeniy.
>
> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L  wrote:
>
>> Hi Simon,
>>
>> As far as I know it's expected behaviour (at least for the current
>> release), and it's expected that user reruns deployment on required nodes
>> using fuel cli, in order to install plugin on a live environment.
>>
>
> Ok. For the record, this means running this command for every node that is
> already deployed:
> $ fuel node --node-id  --deploy
>
> Any plan to have a nicer experience in future Fuel releases?
>
>
>> It depends on specific role, but "update_required" field may help you, it
>> can be added to role description, Fuel reruns deployment on nodes with
>> roles, which are specified in the list, if new node with the role is added
>> to the environment.
>>
>
> Nope, it doesn't work for me since it should run for *all* the nodes,
> irrespective of their roles. AFAIK update_required doesn't support '*'.
>
>
>>
>> Thanks,
>>
>> [1]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18
>>
>> On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
>> wrote:
>>
>>> Hi,
>>> I'm testing the ability to install Fuel plugins in a an environment that
>>> is already deployed.
>>> My starting environment is quite simple: 1 controller + 1 compute. After
>>> the initial deployment, I've installed the 4 LMA plugins:
>>> - LMA collector
>>> - Elasticsearch-Kibana [*]
>>> - InfluxDB-Grafana [*]
>>> - Infrastructure Alerting [*]
>>> [*] adds a new role
>>> Of course, all plugins have "is_hotpluggable: true" in their metadata
>>> definition.
>>> My expectation is that I can add a new node with the new roles and that
>>> the LMA collector tasks are executed for all 3 nodes. So I've added the new
>>> node and click the "Deploy changes" button. My re-deployment runs fine but
>>> I notice that the plugins aren't installed on the existing nodes (eg
>>> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
>>> executed on already deployed nodes... Is this a known limitation? Am I
>>> missing something?
>>> Best regards,
>>> Simon
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Simon Pasquier]

Hi,
I'm testing the ability to install Fuel plugins in a an environment that is
already deployed.
My starting environment is quite simple: 1 controller + 1 compute. After
the initial deployment, I've installed the 4 LMA plugins:
- LMA collector
- Elasticsearch-Kibana [*]
- InfluxDB-Grafana [*]
- Infrastructure Alerting [*]
[*] adds a new role
Of course, all plugins have "is_hotpluggable: true" in their metadata
definition.
My expectation is that I can add a new node with the new roles and that the
LMA collector tasks are executed for all 3 nodes. So I've added the new
node and click the "Deploy changes" button. My re-deployment runs fine but
I notice that the plugins aren't installed on the existing nodes (eg
/etc/fuel/plugins/...) so there is no way that the plugins tasks can be
executed on already deployed nodes... Is this a known limitation? Am I
missing something?
Best regards,
Simon
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

[Zhi Chang]

Hi, thanks for your reply. 


In my db, data is right. But when I run cmd, data is empty. see: 
http://paste.openstack.org/show/486072/
 
Thanks 
Zhi Chang
-- Original --
From:  "Anna Kamyshnikova";
Date:  Fri, Feb 5, 2016 06:29 PM
To:  "OpenStack Development Mailing List (not for usage 
questions)"; 

Subject:  Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs 
router's gateway?

 
Hi!

How do you try to get details about it? I don't have any problems with that, 
see http://paste.openstack.org/show/486069/


On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang  wrote:
hi, all.
Neutron will create a port when setting router gateway to a router. This 
port's device_owner is "network:router_gateway". And, I can see this port in 
db. 


But, why cmd says "Unable to find port with name xxx" when I want to get 
the detail info about this port?


Does there some special reasons?


Thanks
Zhi Chang


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





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

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

[Robert Simai]

All,

I like to announce that SUSE joins these efforts, we're going to provide rooms 
in Nuremberg/Germany and have developers from our side available to contribute 
to the Mitaka bug smash.

The etherpad page [1] is updated, the etherpad page for the location [2] is 
under construction. Hope to see some of you in Nuremberg!

[1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
[2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Nuremberg

-- 
Thanks,
   Robert

On Friday 05 February 2016, 03:42:21 Wang, Shane  wrote:
> Hi all,
> 
> After discussing with TC members and other community guys, we thought March
> 2-4 might not be a good timing for bug smash. So we decided to change the
> dates to be March 7 - 9 (Monday - Wednesday) in R4. Please join our efforts
> to fix bugs for OpenStack.
> 
> Thanks.
> --
> Shane
> From: Wang, Shane [mailto:shane.w...@intel.com]
> Sent: Thursday, January 28, 2016 5:12 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
> 
> Save the Date:
> Global OpenStack Bug Smash
> Wednesday-Friday, March 7-9, 2016
> RSVP by Friday, February 24
> 
> How can you help make the OpenStack Mitaka release stable and bug-free while
> having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP,
> Huawei, CESI and others in a global bug smash across four continents as we
> work together. Then, join us later in April in Austin, Texas, U.S.A. at the
> OpenStack Summit to get re-acquainted & celebrate our accomplishments!
> 
> OUR GOAL
> Our key goal is to collaborate round-the-clock and around the world to fix
> as many bugs as possible across the wide range of OpenStack projects. In
> the process, we'll also help onboard and grow the number of OpenStack
> developers, and increase our collective knowledge of OpenStack tools and
> processes. To ease collaboration among all of the participants and ensure
> that core reviews can be conducted promptly, we will use the IRC channel,
> the mailing list, and Gerrit and enlist core reviewers in the event.
> 
> GET INVOLVED
> Simply choose a place near you-and register by Friday, February 24.
> Registration is free, and we encourage you to invite others who may be
> interested.
> 
> * Australia
> * China
> * India
> 
> * Russia
> * United Kingdom
> * United States
> 
> 
> Visit the link below for additional details:
> https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka
> 
> Come make the Mitaka release a grand success through your contributions, and
> ease the journey for newcomers!
> 
> Regards.
> --
> OpenStack Bug Smash team


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

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

[Salvatore Orlando]

On 5 February 2016 at 04:12, Armando M.  wrote:

>
>
> On 4 February 2016 at 08:22, John Belamaric 
> wrote:
>
>>
>> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin  wrote:
>> >
>> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar 
>> wrote:
>> >> I am trying to bring more attention to [1] to make final decision on
>> >> approach to use.
>> >> There are a few point that are not 100% clear for me at this point.
>> >>
>> >> 1) Do we plan to switch all current clouds to pluggable ipam
>> >> implementation in Mitaka?
>> >
>> > I think our plan originally was only to deprecate the non-pluggable
>> > implementation in Mitaka and remove it in Newton.  However, this is
>> > worth some more consideration.  The pluggable version of the reference
>> > implementation should, in theory, be at parity with the current
>> > non-pluggable implementation.  We've tested it before and shown
>> > parity.  What we're missing is regular testing in the gate to ensure
>> > it continues this way.
>> >
>>
>> Yes, it certainly should be at parity, and gate testing to ensure it
>> would be best.
>>
>> >> yes -->
>> >> Then data migration can be done as alembic_migration and it is what
>> >> currently implemented in [2] PS54.
>> >> In this case during upgrade from Liberty to Mitaka all users are
>> >> unconditionally switched to reference ipam driver
>> >> from built-in ipam implementation.
>> >> If operator wants to continue using build-in ipam implementation it can
>> >> manually turn off ipam_driver in neutron.conf
>> >> immediately after upgrade (data is not deleted from old tables).
>> >
>> > This has a certain appeal to it.  I think the migration will be
>> > straight-forward since the table structure doesn't really change much.
>> > Doing this as an alembic migration would be the easiest from an
>> > upgrade point of view because it fits seamlessly in to our current
>> > upgrade strategy.
>> >
>> > If we go this way, we should get this in soon so that we can get the
>> > gate and others running with this code for the remainder of the cycle.
>> >
>>
>> If we do this, and the operator reverts back to the non-pluggable version,
>> then we will leave stale records in the new IPAM tables. At the very
>> least,
>> we would need a way to clean those up and to migrate at a later time.
>>
>> >> no -->
>> >> Operator is free to choose whether it will switch to pluggable ipam
>> >> implementation
>> >> and when. And it leads to no automatic data migration.
>> >> In this case operator is supplied with script for migration to
>> pluggable
>> >> ipam (and probably from pluggable ipam),
>> >> which can be executed by operator during upgrade or at any point after
>> >> upgrade is done.
>> >> I was testing this approach in [2] PS53 (have unresolved issues in it
>> >> for now).
>> >
>> > If there is some risk in changing over then this should still be
>> > considered.  But, the more I think about it, the more I think that we
>> > should just make the switch seamlessly for the operator and be done
>> > with it.  This approach puts a certain burden on the operator to
>> > choose when to do the migration and go through the steps manually to
>> > do it.  And, since our intention is to deprecate and remove the
>> > non-pluggable implementation, it is inevitable that they will have to
>> > eventually switch anyway.
>> >
>> > This also makes testing much more difficult.  If we go this route, we
>> > really should be testing both equally.  Does this mean that we need to
>> > set up a whole new job to run the pluggable implementation along side
>> > the old implementation?  This kind of feels like a nightmare to me.
>> > What do you think?
>> >
>>
>> Originally (as I mentioned in the meeting), I was thinking that we should
>> not automatically migrate. However, I see the appeal of your arguments.
>> Seamless is best, of course. But if we offer going back to non-pluggable,
>> (which I think we need to at this point in the Mitaka cycle), we probably
>> need to provide a script as mentioned above. Seems feasible, though.
>>
>>
>>
>>
> We're tackling more than one issue in this thread and I am having a hard
> time wrapping my head around it. Let me try to sum it all up.
>
> a) switching from non-pluggable to pluggable it's a matter of running a
> data migration + a config change
> b) We can either switch automatically on restart (option b1) or manually
> on operator command (b2)
> c) Do we make pluggable ipam default and when
> d) Testing the migration
> e) Deprecating the non-pluggable one.
>
> I hope we are all in agreement on bullet point a), because knowing the
> complexity of your problem is halfway to our solution.
>
> as for b) I think that manual migration is best for two reasons: 1) In HA
> scenarios, seamless upgrade (ie. on server restart) can be a challenge; 2)
> the operator must 'manually' change the driver, so he/she is very conscious
> of what he/she is doing and 

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Evgeniy L]

Hi Simon,

As far as I know it's expected behaviour (at least for the current
release), and it's expected that user reruns deployment on required nodes
using fuel cli, in order to install plugin on a live environment.
It depends on specific role, but "update_required" field may help you, it
can be added to role description, Fuel reruns deployment on nodes with
roles, which are specified in the list, if new node with the role is added
to the environment.

Thanks,

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18

On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
wrote:

> Hi,
> I'm testing the ability to install Fuel plugins in a an environment that
> is already deployed.
> My starting environment is quite simple: 1 controller + 1 compute. After
> the initial deployment, I've installed the 4 LMA plugins:
> - LMA collector
> - Elasticsearch-Kibana [*]
> - InfluxDB-Grafana [*]
> - Infrastructure Alerting [*]
> [*] adds a new role
> Of course, all plugins have "is_hotpluggable: true" in their metadata
> definition.
> My expectation is that I can add a new node with the new roles and that
> the LMA collector tasks are executed for all 3 nodes. So I've added the new
> node and click the "Deploy changes" button. My re-deployment runs fine but
> I notice that the plugins aren't installed on the existing nodes (eg
> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
> executed on already deployed nodes... Is this a known limitation? Am I
> missing something?
> Best regards,
> Simon
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Simon Pasquier]

Thanks Evgeniy.

On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L  wrote:

> Hi Simon,
>
> As far as I know it's expected behaviour (at least for the current
> release), and it's expected that user reruns deployment on required nodes
> using fuel cli, in order to install plugin on a live environment.
>

Ok. For the record, this means running this command for every node that is
already deployed:
$ fuel node --node-id  --deploy

Any plan to have a nicer experience in future Fuel releases?


> It depends on specific role, but "update_required" field may help you, it
> can be added to role description, Fuel reruns deployment on nodes with
> roles, which are specified in the list, if new node with the role is added
> to the environment.
>

Nope, it doesn't work for me since it should run for *all* the nodes,
irrespective of their roles. AFAIK update_required doesn't support '*'.


>
> Thanks,
>
> [1]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18
>
> On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
> wrote:
>
>> Hi,
>> I'm testing the ability to install Fuel plugins in a an environment that
>> is already deployed.
>> My starting environment is quite simple: 1 controller + 1 compute. After
>> the initial deployment, I've installed the 4 LMA plugins:
>> - LMA collector
>> - Elasticsearch-Kibana [*]
>> - InfluxDB-Grafana [*]
>> - Infrastructure Alerting [*]
>> [*] adds a new role
>> Of course, all plugins have "is_hotpluggable: true" in their metadata
>> definition.
>> My expectation is that I can add a new node with the new roles and that
>> the LMA collector tasks are executed for all 3 nodes. So I've added the new
>> node and click the "Deploy changes" button. My re-deployment runs fine but
>> I notice that the plugins aren't installed on the existing nodes (eg
>> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
>> executed on already deployed nodes... Is this a known limitation? Am I
>> missing something?
>> Best regards,
>> Simon
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack][Magnum] ways to get CA certificate in make-cert.sh from Magnum

[Corey O'Brien]

I'm not sure I understand the use case. Can you explain the use case you
are trying to solve?

Corey

On Fri, Feb 5, 2016, 02:07 王华  wrote:

> Hi Corey,
>
> The user is root on those nodes and can get any credentials on those
> nodes. We can not avoid that, but by this way we can disallow those users
> who can not login into nodes to access some limited APIs.
>
> Regards,
> Wanghua
>
> On Fri, Feb 5, 2016 at 12:24 PM, Corey O'Brien 
> wrote:
>
>> There currently isn't a way to distinguish between user who creates the
>> bay and the nodes in the bay because the user is root on those nodes. Any
>> credential that the node uses to communicate with Magnum is going to be
>> accessible to the user.
>>
>> Since we already have the trust, that seems like the best way to proceed
>> for now just to get something working.
>>
>> Corey
>>
>> On Thu, Feb 4, 2016 at 10:53 PM 王华  wrote:
>>
>>> Hi all,
>>>
>>> Magnum now use a token to get CA certificate in make-cert.sh. Token has
>>> a expiration time. So we should change this method. Here are two proposals.
>>>
>>> 1. Use trust which I have introduced in [1]. The way has a disadvantage.
>>> We can't limit the access to some APIs. For example, if we want to add a
>>> limitation that some APIs can only be accessed from Bay and can't be
>>> accessed by users outside. We need a way to distinguish these users, from
>>> Bay or from outside.
>>>
>>> 2. We create a user with the role to access Magnum. The way is used in
>>> Heat. Heat creates a user for each stack to communicate with Heat. We can
>>> add a role to the user which is already introduced in [1]. The user can
>>> directly access Magnum for some limited APIs. With trust id, the user can
>>> access other services.
>>>
>>> [1] https://review.openstack.org/#/c/268852/
>>>
>>> Regards,
>>> Wanghua
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Installation] RHEL-7 devstack installation failed in bootstrap_keystone

[Pradip Mukhopadhyay]

Hello,

In a RHEL-7, getting this error:

2016-02-05 11:08:00.385 | Discovering versions from the identity service
failed when creating the password plugin. Attempting to determine version
from URL.
2016-02-05 11:08:00.385 | Could not determine a suitable URL for the plugin
2016-02-05 11:08:00.403 | +
/opt/stack/devstack/lib/keystone:bootstrap_keystone:L617:   token_id=
2016-02-05 11:08:00.403 | +
/opt/stack/devstack/lib/keystone:bootstrap_keystone:L1:   exit_trap
2016-02-05 11:08:00.403 | + ./stack.sh:exit_trap:L474:   local r=1
2016-02-05 11:08:00.404 | ++ ./stack.sh:exit_trap:L475:   jobs -p
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L475:   jobs=
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L478:   [[ -n '' ]]
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L484:   kill_spinner
2016-02-05 11:08:00.404 | + ./stack.sh:kill_spinner:L370:   '[' '!' -z ''
']'
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L486:   [[ 1 -ne 0 ]]
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L487:   echo 'Error on
exit'
2016-02-05 11:08:00.404 | Error on exit
2016-02-05 11:08:00.404 | + ./stack.sh:exit_trap:L488:   generate-subunit
1454670313 167 fail
2016-02-05 11:08:00.670 | + ./stack.sh:exit_trap:L489:   [[ -z
/opt/stack/logs ]]
2016-02-05 11:08:00.670 | + ./stack.sh:exit_trap:L492:
/opt/stack/devstack/tools/worlddump.py -d /opt/stack/logs
2016-02-05 11:08:00.955 | + ./stack.sh:exit_trap:L498:   exit 1


[stack@scson0001301001 devstack]$ uname -a
Linux scson0001301001.nb.openenglab.netapp.com 3.10.0-229.el7.x86_64 #1 SMP
Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux



Any idea how to overcome it?


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

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

[Anna Kamyshnikova]

This seems strange, do you use admin user to run the command?

On Fri, Feb 5, 2016 at 1:57 PM, Zhi Chang  wrote:

> Hi, thanks for your reply.
>
> In my db, data is right. But when I run cmd, data is empty. see:
> http://paste.openstack.org/show/486072/
>
> Thanks
> Zhi Chang
> -- Original --
> *From: * "Anna Kamyshnikova";
> *Date: * Fri, Feb 5, 2016 06:29 PM
> *To: * "OpenStack Development Mailing List (not for usage questions)"<
> openstack-dev@lists.openstack.org>;
> *Subject: * Re: [openstack-dev] [neutron][db]Why can't I see ports
> whichbelongs router's gateway?
>
> Hi!
>
> How do you try to get details about it? I don't have any problems with
> that, see http://paste.openstack.org/show/486069/
>
> On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang 
> wrote:
>
>> hi, all.
>> Neutron will create a port when setting router gateway to a router.
>> This port's device_owner is "network:router_gateway". And, I can see this
>> port in db.
>>
>> But, why cmd says "Unable to find port with name xxx" when I want to
>> get the detail info about this port?
>>
>> Does there some special reasons?
>>
>> Thanks
>> Zhi Chang
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongsrouter's gateway?

[Zhi Chang]

hmm... yes. I miss admin role in my user. sorry ;-)
 
 
-- Original --
From:  "Jerzy Mikolajczak";
Date:  Fri, Feb 5, 2016 07:59 PM
To:  "openstack-dev"; 

Subject:  Re: [openstack-dev] [neutron][db]Why can't I see ports 
whichbelongsrouter's gateway?

 
Missing admin role on Your user maybe?

http://paste.openstack.org/show/486081/

Jerzy

On 05.02.2016 11:57, Zhi Chang wrote:
> Hi, thanks for your reply.
>
> In my db, data is right. But when I run cmd, data is empty.
> see: http://paste.openstack.org/show/486072/
> Thanks
> Zhi Chang
> -- Original --
> *From: * "Anna Kamyshnikova";
> *Date: * Fri, Feb 5, 2016 06:29 PM
> *To: * "OpenStack Development Mailing List (not for usage
> questions)";
> *Subject: * Re: [openstack-dev] [neutron][db]Why can't I see ports
> whichbelongs router's gateway?
> Hi!
>
> How do you try to get details about it? I don't have any problems with
> that, see http://paste.openstack.org/show/486069/
>
> On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang  > wrote:
>
> hi, all.
>  Neutron will create a port when setting router gateway to a
> router. This port's device_owner is "network:router_gateway". And, I
> can see this port in db.
>
>  But, why cmd says "Unable to find port with name xxx" when I
> want to get the detail info about this port?
>
>  Does there some special reasons?
>
> Thanks
> Zhi Chang
> 
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Regards,
> Ann Kamyshnikova
> Mirantis, Inc
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

[Ptacek, MichalX]

Thanks Matt’s,  I was able to get system to vanilla state again ….
And also isolated initial problem,
my first puppet deployment failed on following error:

Debug: Executing '/usr/bin/openstack image list --quiet --format csv --long'
Debug: Executing '/usr/bin/openstack image create --format shell cirros 
--public --container-format=bare --disk-format=qcow2 
--copy-from=http://download.cirros-cloud
.net/0.3.4/cirros-0.3.4-x86_64-disk.img'
Error: Execution of '/usr/bin/openstack image create --format shell cirros 
--public --container-format=bare --disk-format=qcow2 
--copy-from=http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img'
 returned 1: 400 Bad Request: The HTTP URL is invalid. (HTTP 400)
Error: /Stage[main]/Main/Glance_image[cirros]/ensure: change from absent to 
present failed: Execution of '/usr/bin/openstack image create --format shell 
cirros --public --container-format=bare --disk-format=qcow2 
--copy-from=http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img'
 returned 1: 400 Bad Request: The HTTP URL is invalid. (HTTP 400)

which is caused by “glance not able to download image when behind proxy” (even 
when properly configured in .bashrc – http_proxy, https_proxy, no_proxy)
at least what I found about this so far is that in other deployment tools it’s 
handled by some additional config to skip that part:
like RDO
https://bugzilla.redhat.com/show_bug.cgi?id=1147716
or store images locally before “image create” is called like from devstack:

2016-02-01 09:45:59.709 | + for image_url in '${IMAGE_URLS//,/ }'
2016-02-01 09:45:59.709 | + upload_image 
http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-uec.tar.gz
…
2016-02-01 09:45:59.894 | + '[' -n 
/home2/openstack/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
 ']'
2016-02-01 09:45:59.894 | ++ openstack --os-cloud=devstack-admin image create 
cirros-0.3.4-x86_64-uec-kernel --public --container-format aki --disk-format aki

Is there any known way how to get puppet deployments working on systems behind 
proxy ?

Thanks a lot,
Michal



From: Matt Fischer [mailto:m...@mattfischer.com]
Sent: Thursday, February 04, 2016 7:12 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

If you can't isolate the exact thing you need to get cleaned up here it can be 
difficult to unwind. You'll either need to read the code to see what's 
triggering the db setup (which is probably the package installs) or start on a 
clean box. I'd recommend the latter.

On Thu, Feb 4, 2016 at 10:35 AM, Ptacek, MichalX 
> wrote:
Hi Emilien,

It seems that keystone database is not populated, because of something, which 
happened on previous runs (e.g. some packages installation),

Following rows are visible just in log from first attempt
Debug: Executing '/usr/bin/mysql -e CREATE USER 'keystone'@'127.0.0.1' 
IDENTIFIED BY PASSWORD '*936E8F7AB2E21B47F6C9A7E5D9FE14DBA2255E5A''
Debug: Executing '/usr/bin/mysql -e GRANT USAGE ON *.* TO 
'keystone'@'127.0.0.1' WITH MAX_USER_CONNECTIONS 0 MAX_CONNECTIONS_PER_HOUR 0 
MAX_QUERIES_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0'
….
….
I tried to clean databases & uninstall packages installed during deployment, 
but maybe I miss something as it simply doesn’t  work ☺

Is there any procedure, how can I restore system to “vanilla state” before 
puppet modules installation ?
It looks to me that when deployment failed, it’s very difficult to “unstack” it

Thanks in advance,
Michal

From: Ptacek, MichalX
Sent: Thursday, February 04, 2016 11:14 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: RE: [openstack-dev] [puppet] compatibility of puppet upstream modules






-Original Message-
From: Emilien Macchi [mailto:emil...@redhat.com]
Sent: Thursday, February 04, 2016 10:06 AM
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [puppet] compatibility of puppet upstream modules







On 02/03/2016 04:03 PM, Ptacek, MichalX wrote:

> Hi all,

>

>

>

> I have one general question,

>

> currently I am deploying liberty openstack as described in

> https://wiki.openstack.org/wiki/Puppet/Deploy

>

> Unfortunately puppet modules specified in

> puppet-openstack-integration/Puppetfile are not compatible



Did you take the file from stable/liberty branch?

https://github.com/openstack/puppet-openstack-integration/tree/stable/liberty



[Michal Ptacek]  I am deploying scenario003 with stable/liberty

>

> and some are also missing as visible from following output of “puppet

> module list”

>

>

>

> Warning: Setting templatedir is deprecated. See

> 

Re: [openstack-dev] [neutron][db]Why can't I see ports whichbelongs router's gateway?

[Jerzy Mikolajczak]

Missing admin role on Your user maybe?

http://paste.openstack.org/show/486081/

Jerzy

On 05.02.2016 11:57, Zhi Chang wrote:

Hi, thanks for your reply.

In my db, data is right. But when I run cmd, data is empty.
see: http://paste.openstack.org/show/486072/
Thanks
Zhi Chang
-- Original --
*From: * "Anna Kamyshnikova";
*Date: * Fri, Feb 5, 2016 06:29 PM
*To: * "OpenStack Development Mailing List (not for usage
questions)";
*Subject: * Re: [openstack-dev] [neutron][db]Why can't I see ports
whichbelongs router's gateway?
Hi!

How do you try to get details about it? I don't have any problems with
that, see http://paste.openstack.org/show/486069/

On Fri, Feb 5, 2016 at 12:49 PM, Zhi Chang > wrote:

hi, all.
 Neutron will create a port when setting router gateway to a
router. This port's device_owner is "network:router_gateway". And, I
can see this port in db.

 But, why cmd says "Unable to find port with name xxx" when I
want to get the detail info about this port?

 Does there some special reasons?

Thanks
Zhi Chang


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

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




--
Regards,
Ann Kamyshnikova
Mirantis, Inc


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



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

Re: [openstack-dev] [all] [tc] "No Open Core" in 2016

[Dean Troyer]

On Fri, Feb 5, 2016 at 4:57 AM, Thierry Carrez 
wrote:

> My personal take on that is that we can draw a line in the sand for what
> is acceptable as an official project in the upstream OpenStack open source
> effort. It should have a fully-functional, production-grade open source
> implementation. If you need proprietary software or a commercial entity to
> fully use the functionality of a project or getting serious about it, then
> it should not be accepted in OpenStack as an official project. It can still
> live as a non-official project and even be hosted under OpenStack
> infrastructure, but it should not be part of "OpenStack". That is how I
> would interpret "no open core" in OpenStack 2016.
>

Should we host projects that have no hope of becoming official projects due
to this sort of criteria?  Would we host GPL-only projects under openstack/?


> Of course, the devil is in the details, especially around what I mean by
> "fully-functional" and "production-grade". Is it just an API/stability
> thing, or does performance/scalability come into account ? There will
> always be some subjectivity there, but I think it's a good place to start.
>

I think defining 'fully-functional' is easy enough until you allow 'vendor
extensions' into the API.  But there is still an amount of objective
criteria to look at to make it something that a group of, say 13 judges,
might arrive at a reasonable answer.

'Production-grade' is more subjective, especially with the size of
deployment differences in 'production' for a bunch of other things.  But
again, it is one of those things that reasonably technical people will
generally arrive at a useful conclusion .  Existing components (DB, message
queues, etc) can point at known production deployments as evidence; new
components have a harder sell.

For a time many projects used SQLite as a reference implementation for
testing DB functionality, and have moved away from that (completely? I'm
not sure) as we all agree it really is not a production-grade
implementation.  That is an easy example, but as a community we have
crossed this bridge multiple times already and will be able to do it again.

dt

-- 

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

Re: [openstack-dev] [puppet] compatibility of puppet upstream modules

[Matt Fischer]

I'm not sure tbh, we don't have to deal with a proxy, but why not just
comment this part out for now?

Please file a bug on this against puppet-glance if there is a config option
we could add.
On Feb 5, 2016 4:59 AM, "Ptacek, MichalX"  wrote:

> Thanks Matt’s,  I was able to get system to vanilla state again ….
>
> And also isolated initial problem,
>
> my first puppet deployment failed on following error:
>
>
>
> Debug: Executing '/usr/bin/openstack image list --quiet --format csv
> --long'
>
> Debug: Executing '/usr/bin/openstack image create --format shell cirros
> --public --container-format=bare --disk-format=qcow2 --copy-from=
> http://download.cirros-cloud
>
> .net/0.3.4/cirros-0.3.4-x86_64-disk.img'
>
> Error: Execution of '/usr/bin/openstack image create --format shell cirros
> --public --container-format=bare --disk-format=qcow2 --copy-from=
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img'
> returned 1: 400 Bad Request: The HTTP URL is invalid. (HTTP 400)
>
> Error: /Stage[main]/Main/Glance_image[cirros]/ensure: change from absent
> to present failed: Execution of '/usr/bin/openstack image create --format
> shell cirros --public --container-format=bare --disk-format=qcow2
> --copy-from=
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img'
> returned 1: 400 Bad Request: The HTTP URL is invalid. (HTTP 400)
>
>
>
> *which is caused by “glance not able to download image when behind proxy”
> (even when properly configured in .bashrc – http_proxy, https_proxy,
> no_proxy)*
>
> at least what I found about this so far is that in other deployment tools
> it’s handled by some additional config to skip that part:
>
> like RDO
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1147716
>
> or store images locally before “image create” is called like from devstack:
>
>
>
> 2016-02-01 09:45:59.709 | + for image_url in '${IMAGE_URLS//,/ }'
>
> 2016-02-01 09:45:59.709 | + upload_image
> http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-uec.tar.gz
>
> …
>
> 2016-02-01 09:45:59.894 | + '[' -n
> /home2/openstack/devstack/files/images/cirros-0.3.4-x86_64-uec/cirros-0.3.4-x86_64-vmlinuz
> ']'
>
> 2016-02-01 09:45:59.894 | ++ openstack --os-cloud=devstack-admin image
> create cirros-0.3.4-x86_64-uec-kernel --public --container-format aki
> --disk-format aki
>
>
>
> Is there any known way how to get puppet deployments working on systems
> behind proxy ?
>
>
>
> Thanks a lot,
>
> Michal
>
>
>
>
>
>
>
> *From:* Matt Fischer [mailto:m...@mattfischer.com]
> *Sent:* Thursday, February 04, 2016 7:12 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [puppet] compatibility of puppet upstream
> modules
>
>
>
> If you can't isolate the exact thing you need to get cleaned up here it
> can be difficult to unwind. You'll either need to read the code to see
> what's triggering the db setup (which is probably the package installs) or
> start on a clean box. I'd recommend the latter.
>
>
>
> On Thu, Feb 4, 2016 at 10:35 AM, Ptacek, MichalX 
> wrote:
>
> Hi Emilien,
>
>
>
> It seems that keystone database is not populated, because of something,
> which happened on previous runs (e.g. some packages installation),
>
>
>
> Following rows are visible just in log from first attempt
>
> Debug: Executing '/usr/bin/mysql -e CREATE USER 'keystone'@'127.0.0.1'
> IDENTIFIED BY PASSWORD '*936E8F7AB2E21B47F6C9A7E5D9FE14DBA2255E5A''
>
> Debug: Executing '/usr/bin/mysql -e GRANT USAGE ON *.* TO 
> 'keystone'@'127.0.0.1'
> WITH MAX_USER_CONNECTIONS 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_QUERIES_PER_HOUR
> 0 MAX_UPDATES_PER_HOUR 0'
>
> ….
>
> ….
>
> I tried to clean databases & uninstall packages installed during
> deployment, but maybe I miss something as it simply doesn’t  work J
>
>
>
> Is there any procedure, how can I restore system to “vanilla state” before
> puppet modules installation ?
>
> It looks to me that when deployment failed, it’s very difficult to
> “unstack” it
>
>
>
> Thanks in advance,
>
> Michal
>
>
>
> *From:* Ptacek, MichalX
> *Sent:* Thursday, February 04, 2016 11:14 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* RE: [openstack-dev] [puppet] compatibility of puppet upstream
> modules
>
>
>
>
>
>
>
> -Original Message-
> From: Emilien Macchi [mailto:emil...@redhat.com ]
> Sent: Thursday, February 04, 2016 10:06 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [puppet] compatibility of puppet upstream
> modules
>
>
>
>
>
>
>
> On 02/03/2016 04:03 PM, Ptacek, MichalX wrote:
>
> > Hi all,
>
> >
>
> >
>
> >
>
> > I have one general question,
>
> >
>
> > currently I am deploying liberty openstack as described in
>
> > 

[openstack-dev] [Ironic] A strange transition in Ironic FSM

[Yuriy Zveryanskyy]

Hi.

We have a followed transition in common/states.py:

# An errored instance can be rebuilt
# ironic/conductor/manager.py:do_node_deploy()
machine.add_transition(ERROR, DEPLOYING, 'rebuild')

At first glance it looks correct. But ERROR state is
used only for error after deleting, see
http://docs.openstack.org/developer/ironic/_images/states.svg
So ERROR is delete error, at least now, and transition
error (delete error) -> deploying (on_rebuild)
is possible.
Looks strange if operator wants to remove an instance completely and then
does rebuild after error (non-error targets for deleting is cleaning -> 
available).

I think this transition should be removed. Without this strange transition
bug https://bugs.launchpad.net/ironic/+bug/1522008 can be fixed by 
simple way,
port's vif id can be removed via Ironic virt driver request before 
waiting of CLEANING

(it's no more needed).

Yuriy Zveryanskyy






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

Re: [openstack-dev] [all] the trouble with names

[michael mccune]

On 02/04/2016 12:57 PM, Hayes, Graham wrote:

On 04/02/2016 15:40, Ryan Brown wrote:

On 02/04/2016 09:32 AM, michael mccune wrote:

On 02/04/2016 08:33 AM, Thierry Carrez wrote:

Hayes, Graham wrote:

On 04/02/2016 13:24, Doug Hellmann wrote:

Excerpts from Hayes, Graham's message of 2016-02-04 12:54:56 +:

On 04/02/2016 11:40, Sean Dague wrote:

2) Have a registry of "common" names.

Upside, we can safely use common names everywhere and not fear
collision down the road.

Downside, yet another contention point.

A registry would clearly be under TC administration, though all the
heavy lifting might be handed over to the API working group. I still
imagine collision around some areas might be contentious.


++ to a central registry. It could easily be added to the
projects.yaml
file, and is a single source of truth.


Although I realized that the projects.yaml file only includes official
projects right now, which would mean new projects wouldn't have a place
to register terms. Maybe that's a feature?


That is a good point - should we be registering terms for non tent
projects? Or do projects get terms when they get accepted into the tent?


I don't see why we would register terms for non-official projects. I
don't see under what authority we would do that, or where it would end.
So yes, that's a feature.



i have a question about this, as new, non-official, projects start to
spin up there will be questions about the naming conventions they will
use within the project as to headers and the like. given that the
current guidance trend in the api-wg is towards using "service type" in
these cases, how would these projects proceed?

(i'm not suggesting these projects should be registered, just curious)


This isn't a perfect solution, but maybe instead of projects.yml there
could be a `registry.yml` project that would (of course) have all the
project.yml "in-tent" projects, but also merge in external project
requests for namespaces?


Where ever it is stored, could this be a solid place for the api-wg to
codify the string that should be shown in the catalog / headers /
other places by services?



this seems like a reasonable approach, the big downside might be 
grooming the "dibs" list. we could have projects that expect to go 
somewhere, register their name, then never achieve "lift-off". in these 
cases we would need to release those names back into the free pool.



Say there's an LDAP aaS project, it could ask to reserve "directory" or
whatever and have a reasonable hope that when they're tented they'll be
able to use it. This would help avoid having multiple projects expecting
to use the same name, while also not meaning we force anyone to use or
not use some name.

Effectively, it's a gerrit-backed version of "dibs".


I think solution 2 is the best. To avoid too much contention, that can
easily be delegated to the API WG, and escalated to the TC for
resolution only in case of conflict between projects (or between a
project and the API WG).



i'm +1 for solution 2 as well. as to the api-wg participation in the
name registration side of things , i don't have an objection but i am
very curious to hear Everett's and Chris' opinions.

regards,
mike

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





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




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