date:20150320

I did hear of one use case.[1] :-)

In all seriousness, it seems like our abstraction over executing processes
must be leaking quite a bit if we can't handle a no-namespace deployment.
It seems like running a command without "ip netns" in front of it shouldn't
be that much harder. Or am I misunderstanding where the special-casing
issues are?


1. http://lists.openstack.org/pipermail/openstack-dev/2015-March/059538.html

On Fri, Mar 20, 2015 at 3:26 PM, Assaf Muller  wrote:

>
>
> - Original Message -
> > Tempest tests fail when not using namespaces, so I'm not sure how well
> we're
> > even testing that codepath anymore.
>
> Hrmph, I meant to mention that the code path is basically untested but
> forgot
> to do that when I sent the email.
>
> >
> > doug
> >
> >
> > > On Mar 20, 2015, at 3:19 PM, Brian Haley  wrote:
> > >
> > > On 03/20/2015 02:57 PM, Assaf Muller wrote:
> > >> Hello everyone,
> > >>
> > >> The use_namespaces option in the L3 and DHCP Neutron agents controls
> if
> > >> you
> > >> can create multiple routers and DHCP networks managed by a single
> L3/DHCP
> > >> agent,
> > >> or if the agent manages only a single resource.
> > >>
> > >> Are the setups out there *not* using the use_namespaces option? I'm
> > >> curious as
> > >> to why, and if it would be difficult to migrate such a setup to use
> > >> namespaces.
> > >
> > > This is a recent Neutron bug where someone is not using namespaces, so
> they
> > > exist:
> > >
> > > https://bugs.launchpad.net/neutron/+bug/1428007
> > >
> > >> I'm asking because use_namespaces complicates Neutron code for what I
> > >> gather
> > >> is an option that has not been relevant for years. I'd like to
> deprecate
> > >> the option
> > >> for Kilo and remove it in Liberty.
> > >
> > > +1 from me for deprecation.
> > >
> > > -Brian
> > >
> > >
> > >
> __
> > > 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
>



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

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

On 21:53 Fri 20 Mar , Rochelle Grober wrote:
> Ditto for Huawei.  
> 
> While we are not *reliably* reporting, we are reporting and the necessary
> steps have already been taken (and more importantly, approved) to get this
> reliably working ASAP.
> 
> We respectfully request the same consideration for our cinder drivers.

The most important piece of a CI meeting the requirements is that the test
pass with your storage solution configured in Cinder, and to only report
failures when a patch really does break your integration. Otherwise, there is
no point. So far, the times Huawei-ci has reported have been false failures [1].

[1] - 
https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z

-- 
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] [Congress] [Delegation] Meeting scheduling

2015-03-20 Thread Tim Hinrichs

(Instead of having a copy of these emails in the gdoc, I resolved the comment 
in the gdoc and added a link to this email thread in the ML archives.)

Inline.

On Mar 20, 2015, at 8:34 AM, Yathiraj Udupi (yudupi) 
mailto:yud...@cisco.com>> wrote:

Hi Tim,

I think what you are saying is a reasonable goal in terms of high-level 
Congress policies not having to depend on the domain-specific solver / policy 
engines.  As long as there are Congress adapters to transform the user’s 
policies to something that domain-specific solver understands it will be fine.

With respect to delegation to solver scheduler, I agree that we need a 
combination of options (1) and (2).
For option (2), in order to leverage the pre-defined constraint classes in 
Solver Scheduler,  it is more like the Congress adapter notifying the Solver 
Scheduler to include that constraint as part of the current placement decision. 
  Also we have to take it to account that it is not just the user-defined 
Congress policies that define the placement choices,  the already existing 
infrastructure-specific constraints, in terms of Host capacities, or any other 
provider specific constraints will have to be included in the placement 
decision calculation by the solver.   The pre-configured scheduler/placement 
constraints will always have to be included.  But some additional policies from 
Congress can introduce additional constraints.

I’d love to hear more about this.  Where do these other 
policies/configurations/etc. live?  What do they look like?  One of the things 
we’ve always discussed is a model where we combine policies from different 
places to understand the *actual* policy that we need to act on.  If you could 
walk us through an example that shows different kinds of constraints and where 
they come from, that’d be a big help!


For option (1), new custom constraint class -  Solver Scheduler already has an 
interface BaseLinearConstraint - 
https://github.com/stackforge/nova-solver-scheduler/blob/master/nova/scheduler/solvers/linearconstraints/__init__.py
with methods -  get_coefficient_vectors, get_variable_vectors, and 
get_operations that will be invoked by the main solver class to feed in the 
variables, and the host metrics, along with some input parameters that used to 
get additional metadata that can be used to build matrices.  Eventually the 
main solver class builds the LP program by invoking all the classes.  So for 
the Congress delegation scenario, it will be along these lines, where the 
Congress adapter will have to populate these matrices based on the Datalog 
policy.   So as part of the solver scheduler’s workflow this special 
CongressConstraint class will have to call the Congress adapter with the 
variables already known, and get the necessary values.
For reference, an example implementation of this constraint class is here - 
https://github.com/stackforge/nova-solver-scheduler/blob/master/nova/scheduler/solvers/linearconstraints/max_disk_allocation_constraint.py


That sounds promising.  I’d like to do a compare/contrast of how it would look 
with and without the solver-scheduler interface.  I’ve never used an LP solver, 
so it’s hard for me to understand the benefits of the interface you have over 
using the raw LP solver interface.  Again, an example would help me.

Tim

Will need some more thoughts, but the approach seems reasonable.

Thanks,
Yathi.



On 3/18/15, 8:34 AM, "Tim Hinrichs" 
mailto:thinri...@vmware.com>> wrote:

I responded in the gdoc.  Here’s a copy.

One of my goals for delegation is to avoid asking people to write policy 
statements specific to any particular domain-specific solver.  People ought to 
encode policy however they like, and the system ought to figure out how best to 
enforce that policy  (delegation being one option).

Assuming that's a reasonable goal, I see two options for delegation to  
solverScheduler

(1) SolverScheduler exposes a custom constraint class.  Congress generates the 
LP program from the Datalog, similar to what is described in this doc, and 
gives that LP program as custom constraints to the  SolverScheduler.  
SolverScheduler is then responsible for enforcing that policy both during 
provisioning of new servers and

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Assaf Muller



- Original Message -
> Tempest tests fail when not using namespaces, so I'm not sure how well we're
> even testing that codepath anymore.

Hrmph, I meant to mention that the code path is basically untested but forgot
to do that when I sent the email.

> 
> doug
> 
> 
> > On Mar 20, 2015, at 3:19 PM, Brian Haley  wrote:
> > 
> > On 03/20/2015 02:57 PM, Assaf Muller wrote:
> >> Hello everyone,
> >> 
> >> The use_namespaces option in the L3 and DHCP Neutron agents controls if
> >> you
> >> can create multiple routers and DHCP networks managed by a single L3/DHCP
> >> agent,
> >> or if the agent manages only a single resource.
> >> 
> >> Are the setups out there *not* using the use_namespaces option? I'm
> >> curious as
> >> to why, and if it would be difficult to migrate such a setup to use
> >> namespaces.
> > 
> > This is a recent Neutron bug where someone is not using namespaces, so they
> > exist:
> > 
> > https://bugs.launchpad.net/neutron/+bug/1428007
> > 
> >> I'm asking because use_namespaces complicates Neutron code for what I
> >> gather
> >> is an option that has not been relevant for years. I'd like to deprecate
> >> the option
> >> for Kilo and remove it in Liberty.
> > 
> > +1 from me for deprecation.
> > 
> > -Brian
> > 
> > 
> > __
> > 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] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

They blow up because they assume you can have overlapping IPs, right?

On Fri, Mar 20, 2015 at 2:26 PM, Doug Wiegley 
wrote:

> Tempest tests fail when not using namespaces, so I'm not sure how well
> we're even testing that codepath anymore.
>
> doug
>
>
> > On Mar 20, 2015, at 3:19 PM, Brian Haley  wrote:
> >
> > On 03/20/2015 02:57 PM, Assaf Muller wrote:
> >> Hello everyone,
> >>
> >> The use_namespaces option in the L3 and DHCP Neutron agents controls if
> you
> >> can create multiple routers and DHCP networks managed by a single
> L3/DHCP agent,
> >> or if the agent manages only a single resource.
> >>
> >> Are the setups out there *not* using the use_namespaces option? I'm
> curious as
> >> to why, and if it would be difficult to migrate such a setup to use
> namespaces.
> >
> > This is a recent Neutron bug where someone is not using namespaces, so
> they exist:
> >
> > https://bugs.launchpad.net/neutron/+bug/1428007
> >
> >> I'm asking because use_namespaces complicates Neutron code for what I
> gather
> >> is an option that has not been relevant for years. I'd like to
> deprecate the option
> >> for Kilo and remove it in Liberty.
> >
> > +1 from me for deprecation.
> >
> > -Brian
> >
> >
> >
> __
> > 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
>



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

[openstack-dev] [oslo][cinder][nova][neutron] going forward to oslo-config-generator ...

2015-03-20 Thread Jay S. Bryant


All,

Let me start with the TLDR;

Cinder, Nova and Neutron have lots of configuration options that need to 
be processed by oslo-config-generator to create the 
.conf.sample file.  There are a couple of different ways this 
could be done.  I have one proposal out, which has raised concerns, 
there is a second approach that could be taken which I am proposing 
below.  Please read on if you have a strong opinion on the precedent we 
will try to set in Cinder.  :-)


We discussed in the oslo meeting a couple of weeks ago a plan for how 
Cinder was going to blaze a trail to the new oslo-config-generator.  The 
result of that discussion and work is here:  [1]  It needs some more 
work but has the bare bones pieces there to move to using 
oslo-config-generator.


With the change I have written extensive hacking checks that ensure that 
any lists that are registered with register_opts() are included in the 
base cinder/opts.py file that is then a single entry point that pulls 
all of the options together to generate the cinder.conf.sample file.  
This has raised concern, however, that whenever a developer adds a new 
list of configuration options, they are going to have to know to go back 
to cinder/opts.py and add their module and option list there.  The 
hacking check should catch this before code is submitted, but we are 
possibly setting ourselves up for cases where the patch will fail in the 
gate because updates are not made in all the correct places and because 
pep8 isn't run before the patch is pushed.


It is important to note, that this will not happen every time a 
configuration option is changed or added, as was the case with the old 
check-uptodate.sh script.  Only when a new list of configuration options 
is added which is a much less likely occurrence.  To avoid this 
happening at all it was proposed by the Cinder team that we use the code 
I wrote for the hacking checks to dynamically go through the files and 
create cinder/opts.py whenever 'tox -egenconfig' is run.  Doing this 
makes me uncomfortable as it is not consistent with anything else I am 
familiar with in OpenStack and is not consistent with what other 
projects are doing to handle this problem.  In discussion with Doug 
Hellman, the approach also seemed to cause him concern.  So, I don't 
believe that is the right solution.


An alternative that may be a better solution was proposed by Doug:

We could even further reduce the occurrence of such issues by moving the 
list_opts() function down into each driver and have an entry point for 
oslo.config.opts in setup.cfg for each of the drivers.  As with the 
currently proposed solution, the developer doesn't have to edit a top 
level file for a new configuration option.  This solution adds that the 
developer doesn't have to edit a top level file to add a new 
configuration item list to their driver.  With this approach the change 
would happen in the driver's list_opts() function, rather than in 
cinder/opts.py .  The only time that setup.cfg would needed to edited is 
when a new package is added or when a new driver is added.  This would 
reduce some of the already minimal burden on the developer.  We, 
however, would need to agree upon some method for aggregating together 
the options lists on a per package (i.e. cinder.scheduler, cinder.api) 
level.  This approach, however, also has the advantage of providing a 
better indication in the sample config file of where the options are 
coming from.  That is an improvement over what I have currently proposed.


Does Doug's proposal sound more agreeable to everyone?  It is important 
to note that the fact that some manual intervention is required to 
'plumb' in the new configuration options was done by design.  There is a 
little more work required to make options available to 
oslo-config-generator but the ability to use different namespaces, 
different sample configs, etc were added with the new generator.  These 
additional capabilities were requested by other projects.  So, moving to 
this design does have the potential for more long-term gain.


Thanks for taking the time to consider this!

Jay

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


__
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][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:48 PM, Jay Pipes  wrote:
> I actually don't think the API URI structure should acknowledge if there is
> or is not a window of time that is involved in some action. Instead, whether
> or not the API call returns a 202 Accepted or a 201 Created should be
> sufficient for communicating that information to the API user.

I actually wasn't even thinking of it in these terms.  By
acknowledged, I meant that the implementation must acknowledge the gap
and ensure that problems don't arise because of it.  But, your point
is good too.

>> Does IPAM hold a reservation or something on the subnet to lock out
>> others?  Or, does the client just retry on failure?  If there are
>> multiple clients requesting subnet allocations, it seems that IPAM
>> should keep some state (e.g. a reservation) to avoid giving out the
>> same one more than once to difference clients at least.

> Any API that returns 202 Accepted must return information in the HTTP
> headers (Location: ) about where the client can get an update on the
> status of the resource that should be created:
>
> https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#2xx-success-codes
>
> Whether or not this mechanism returns a reservation resource link (something
> like /reservations/{res_id}), or a link to the resource itself
> (/subnets/{subnet_id}) is entirely implementation-dependent.
>
> I personally prefer the latter, but could go either way.
>
>> I think that the first operation should result in full allocation of
>> the subnet to the tenant.  In this case, I think that the allocation
>> should have an id and be a first class object (it is not currently).
>> The tenant will need to manage these allocations like anything else.
>> The tenant will also be required to delete unused allocations.  This
>> might be the way to go long-term.
>
>
> In this case, you are suggesting to make the REST API operation synchronous,
> and should use 201 Created.

Yes, I think so.

> There's no reason you couldn't support both the top-level and the
> subcollection resource method of creating the subnet, though.
>
> For instance, these two API calls would essentially be the same:
>
> POST /subnets
> {
>   'pool_id': 'some_pool',
>   'network_id': 'some_network',
>   'cidr': '192.168.0.0./24'
> }
>
> POST /subnetpools/some_pool/subnets
>
> {
>   'network_id': 'some_network',
>   'cidr': '192.168.0.0./24'
> }

Ok, I see.  I'll keep that in mind.  The first one makes sense.  I'm
not sure that creating a subnet from the pools resource makes sense to
me though.  Let me think on it.

Carl

__
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] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

2015-03-20 Thread Rochelle Grober

Ditto for Huawei.  

While we are not *reliably* reporting, we are reporting and the necessary steps 
have already been taken (and more importantly, approved) to get this reliably 
working ASAP.

We respectfully request the same consideration for our cinder drivers.

--Rocky (as proxy for Liu Xinquo)

-Original Message-
From: ClaytonLuce, Timothy [mailto:timothy.claytonl...@netapp.com] 
Sent: Friday, March 20, 2015 14:27
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp 
FC drivers (no voting CI)

Mike,

I request the same consideration being given to the Oracle driver team:

> The tag for Kilo in Cinder has already happened, so it's too late to revert. 
> We
> may be able to revisit this in Kilo RC, but I want to see your CI reporting
> reliably now to then to Cinder reviews.

We are going to try by hook or crook to scrounge/borrow equipment to put a 
quick and dirty CI together and get it reliably reporting.

Tim

From: Mike Perez 
Sent: Friday, March 20, 2015 2:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp 
FC drivers (no voting CI)

On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote:
> I'd like to point out that for NetApp FC drivers NetApp has been in
> discussions and updating progress on these drivers since their submission.
>
> I will point out a discussion in the Nov Core meeting where I brought up the
> challenge around FC environments and the response I received:

> NetApp has in good faith been working toward implementing a CI for FC,
> I won't go into the challenges of spending $$ for lab equipment to build out
> a scalable quality CI system but suffice it to say the lab equipment is on
> order and scheduled for arrival the first part of April, at which point we
> can put in place the CI for FC.

1) We've been talking about CI's since Feburary 2014. That's really too bad
   this took so long. The deadline itself has been overly announced on the
   mailing list and Cinder IRC meetings. [1][2][3][4][5][6][7][8]

2) We have a number of FC drivers today that had no problem meeting this
   deadline that was expressed in November 2014.

3) I've barely received updates from Netapp folks on progress here. I'm the
   only point of contact, so if you weren't talking to me, then it's unknown.
   I've expressed this to a number of your engineers and in my announcements
   about the CI deadline [8]

I had to engage with Netapp to get updates, no one came to me with updates. The
last update I heard from one of your engineers was, we bought the hardware,
but it's just sitting there. That is not acceptable with us being past the
deadline, and shows a clear sign of this not being a priority.

> NetApp has been very forthcoming in our progress and have gotten all our
> other CI systems in place for 7-mode iSCSI/NFS, cDOT iSCSI/NFS and E-Series.
>
> I respectfully request that NetApp FC be removed from this list of drivers to
> be removed for Kilo and placed back in the releaes and we can negotiate an
> agreed upon time as to when the CI system for these drivers will be in place.

There will be no negotiating on what is an acceptable timeline for Netapp. What
we all agreed to as a *community* back at the summit and Cinder IRC meeting
was it.

[1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[2] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html
[4] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html
[5] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html
[6] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html
[8] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html

--
Mike Perez

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

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

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

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

What if we just call it 'address_index' and make it an integer representing
the offset from the network start address?

On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin  wrote:

> On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes  wrote:
> > How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK.
>
> It isn't a valid *IP* address without the network part.  However, it
> can be referred to as the "host address on the network" or the host
> part of the IP address.
>
> Carl
>
> __
> 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
>



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

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

2015-03-20 Thread ClaytonLuce, Timothy

Mike,

I request the same consideration being given to the Oracle driver team:

> The tag for Kilo in Cinder has already happened, so it's too late to revert. 
> We
> may be able to revisit this in Kilo RC, but I want to see your CI reporting
> reliably now to then to Cinder reviews.

We are going to try by hook or crook to scrounge/borrow equipment to put a 
quick and dirty CI together and get it reliably reporting.

Tim

From: Mike Perez 
Sent: Friday, March 20, 2015 2:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Request exemption for removal of NetApp 
FC drivers (no voting CI)

On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote:
> I'd like to point out that for NetApp FC drivers NetApp has been in
> discussions and updating progress on these drivers since their submission.
>
> I will point out a discussion in the Nov Core meeting where I brought up the
> challenge around FC environments and the response I received:

> NetApp has in good faith been working toward implementing a CI for FC,
> I won't go into the challenges of spending $$ for lab equipment to build out
> a scalable quality CI system but suffice it to say the lab equipment is on
> order and scheduled for arrival the first part of April, at which point we
> can put in place the CI for FC.

1) We've been talking about CI's since Feburary 2014. That's really too bad
   this took so long. The deadline itself has been overly announced on the
   mailing list and Cinder IRC meetings. [1][2][3][4][5][6][7][8]

2) We have a number of FC drivers today that had no problem meeting this
   deadline that was expressed in November 2014.

3) I've barely received updates from Netapp folks on progress here. I'm the
   only point of contact, so if you weren't talking to me, then it's unknown.
   I've expressed this to a number of your engineers and in my announcements
   about the CI deadline [8]

I had to engage with Netapp to get updates, no one came to me with updates. The
last update I heard from one of your engineers was, we bought the hardware,
but it's just sitting there. That is not acceptable with us being past the
deadline, and shows a clear sign of this not being a priority.

> NetApp has been very forthcoming in our progress and have gotten all our
> other CI systems in place for 7-mode iSCSI/NFS, cDOT iSCSI/NFS and E-Series.
>
> I respectfully request that NetApp FC be removed from this list of drivers to
> be removed for Kilo and placed back in the releaes and we can negotiate an
> agreed upon time as to when the CI system for these drivers will be in place.

There will be no negotiating on what is an acceptable timeline for Netapp. What
we all agreed to as a *community* back at the summit and Cinder IRC meeting
was it.

[1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[2] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html
[4] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html
[5] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html
[6] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html
[8] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html

--
Mike Perez

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

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

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Doug Wiegley

Tempest tests fail when not using namespaces, so I'm not sure how well we're 
even testing that codepath anymore.

doug


> On Mar 20, 2015, at 3:19 PM, Brian Haley  wrote:
> 
> On 03/20/2015 02:57 PM, Assaf Muller wrote:
>> Hello everyone,
>> 
>> The use_namespaces option in the L3 and DHCP Neutron agents controls if you
>> can create multiple routers and DHCP networks managed by a single L3/DHCP 
>> agent,
>> or if the agent manages only a single resource.
>> 
>> Are the setups out there *not* using the use_namespaces option? I'm curious 
>> as
>> to why, and if it would be difficult to migrate such a setup to use 
>> namespaces.
> 
> This is a recent Neutron bug where someone is not using namespaces, so they 
> exist:
> 
> https://bugs.launchpad.net/neutron/+bug/1428007
> 
>> I'm asking because use_namespaces complicates Neutron code for what I gather
>> is an option that has not been relevant for years. I'd like to deprecate the 
>> option
>> for Kilo and remove it in Liberty.
> 
> +1 from me for deprecation.
> 
> -Brian
> 
> 
> __
> 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] [MagnetoDB] Kilo-3 milestone release

2015-03-20 Thread Ilya Sviridov

Hello everybody,

MagnetoDB team is happy to announce Kilo-3 release [1]

Thank you to everyone who made this possible.

[1] https://launchpad.net/magnetodb/kilo/kilo-3

-- 
With best regards
Ilya  Sviridov
__
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] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Brian Haley

On 03/20/2015 02:57 PM, Assaf Muller wrote:
> Hello everyone,
> 
> The use_namespaces option in the L3 and DHCP Neutron agents controls if you
> can create multiple routers and DHCP networks managed by a single L3/DHCP 
> agent,
> or if the agent manages only a single resource.
> 
> Are the setups out there *not* using the use_namespaces option? I'm curious as
> to why, and if it would be difficult to migrate such a setup to use 
> namespaces.

This is a recent Neutron bug where someone is not using namespaces, so they 
exist:

https://bugs.launchpad.net/neutron/+bug/1428007

> I'm asking because use_namespaces complicates Neutron code for what I gather
> is an option that has not been relevant for years. I'd like to deprecate the 
> option
> for Kilo and remove it in Liberty.

+1 from me for deprecation.

-Brian


__
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] Uniqueness of subnets within a tenant

To clarify a bit, we obviously divide lots of things by tenant (quotas,
network listing, etc). The difference is that we have nothing right now
that has to be unique within a tenant. Are there objects that are uniquely
scoped to a tenant in Nova/Glance/etc?

On Fri, Mar 20, 2015 at 12:50 PM, Jay Pipes  wrote:

> On 03/20/2015 03:37 PM, Carl Baldwin wrote:
>
>> On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes  wrote:
>>
>>> This is a question purely out of curiousity. Why is Neutron averse to the
>>> concept of using tenants as natural ways of dividing up the cloud --
>>> which
>>> at its core means "multi-tenant", on-demand computing and networking?
>>>
>>
>>  From what I've heard others say both in this thread and privately to
>> me, there are already a lot of cases where a tenant will use the same
>> address range to stamp out identical topologies.  It occurred to me
>> that we might even being doing this with our own gate infrastructure
>> but I don't know for sure.
>>
>>  Is this just due to a lack of traditional use of the term in networking
>>> literature? Or is this something more deep-grained (architecturally) than
>>> that?
>>>
>>
>> We already have NAT serving as the natural divider between them and so
>> there is no reason to create another artificial way of dividing them
>> up which will force them to change their practices.  I've come to
>> terms with this since my earlier replies to this thread.
>>
>
> OK, thanks for the info, Carl, appreciated.
>
> 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
>



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

[openstack-dev] [Ironic] Announcing Bifrost

2015-03-20 Thread Julia Kreger

At present, the only configuration in which ironic is tested is as part of
a complete  OpenStack cloud. While this is also the most common usage,
there has  been significant interest in running Ironic outside of OpenStack
contexts as an independent service for provisioning hardware in trusted
environments. This work was done initially as a proof-of-concept to
determine the viability of that use case.

Bifrost is a set of Ansible playbooks that automates the task of deploying
a base image onto a set of known hardware using Ironic. It provides modular
utility for one-off operating system deployment with as few operational
requirements as reasonably possible. Our intention is to utilize this to
further develop tooling around and testing of Ironic in the context of a
standalone installation.

How it works:

Bifrost works by installing Ironic with no other OpenStack services on a
node, coupled with the minimum required infrastructure (DHCP, TFTP, HTTP)
to utilize the Ironic-Python-Agent method of deploying a node. We intend to
add support for additional deployment methods as time goes on.

After installation, a hardware inventory file is read, and all the hardware
is enrolled with Ironic. This is also used to generate node-specific
config-drives containing SSH keys and static network configuration, which
are written out during deployment.

Post-deployment, the deployed machines are configured to boot from their
local disks. The Bifrost node can be completely removed, and all machines
will remain operational.

If by chance, you don't have any hardware available to test Bifrost on, a
testing mode exists which can leverage virtual machines on a Linux system.
This will be used to provide CI for Bifrost, and, we hope, functional
testing of Ironic in the near future. Checkout the README for more
information.

The README can be found at
https://github.com/juliakreger/bifrost/blob/master/README.rst

Special thanks to:

David Shrewsbury
Monty Taylor
Devananda van der Veen
__
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] Uniqueness of subnets within a tenant

2015-03-20 Thread Jeremy Stanley

On 2015-03-20 13:37:49 -0600 (-0600), Carl Baldwin wrote:
> From what I've heard others say both in this thread and privately to
> me, there are already a lot of cases where a tenant will use the same
> address range to stamp out identical topologies.  It occurred to me
> that we might even being doing this with our own gate infrastructure
> but I don't know for sure.
[...]

We don't really. I mean we do reuse identical network configurations
for jobs running in parallel but these exist solely within the
nested OpenStack environments (either entirely local to a worker or
in some cases bridged through a GRE tunnel between workers).

Now that's for the test infrastructure specifically... if the
networks for a Tempest-created tenant in DevStack on one of those
workers duplicates a CIDR I wouldn't necessarily know, since I don't
pay particularly close attention to DevStack/Tempest configurations.
-- 
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] [Nova] Liberty specs are now open

Davanum Srinivas  writes:

> Neil,
>
> yes, see example - https://review.openstack.org/#/c/155116/ - you file
> against the /approved directory

Thanks!
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] [Nova] Liberty specs are now open

2015-03-20 Thread Davanum Srinivas

Neil,

yes, see example - https://review.openstack.org/#/c/155116/ - you file
against the /approved directory

-- dims

On Fri, Mar 20, 2015 at 2:41 PM, Neil Jerram  wrote:
> Neil Jerram  writes:
>
>> Hi Michael,
>>
>> Michael Still  writes:
>>
>>> For specs approved in Juno or Kilo, there is a fast track approval
>>> process for Liberty. The steps to get your spec re-approved are:
>>>
>>>  - Copy your spec from the specs//approved directory to
>>> the specs/liberty/approved directory. [...]
>>
>> Perhaps I'm misunderstanding, or have failed to pull the latest
>> nova-specs repo correctly, but I don't see a specs/liberty/approved
>> directory.  Do you mean just specs/liberty ?
>
> Ah, I guess the intention may be that a proposed spec patch would
> _create_ the specs/liberty/approved directory.  Is that right?
>
>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



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

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

[openstack-dev] [Murano] Feature Freeze Exceptions

2015-03-20 Thread Serg Melikyan

Hi, folks!

Today we released third milestone of Kilo release - 2015.1.0b3 [1], in
this milestone we completed 11 blueprints and fixed 13 bugs. We
finally completed a number of big features that we were working whole
cycle: Integration with Congress, Environment Templates and so on.

Release of kilo-3 means that our Feature Freeze kicks in, and we still
have some features that are not completed yet. Following features are
marked as Feature Freeze exceptions and will be completed during RC
cycle:

1. Support for configuration languages (puppet, chef) [2]
2. Migrate to YAQL 1.0 [3]
3. Murano Versioning [4]

We also need to finish working on our specifications, cause many
specifications are still on review, even as features are already
completed. In this cycle we introduced murano-specs [5] repository in
experimental mode, but starting from the next cycle we are completely
migrating to murano-specs model.

P.S. Feature Freeze also means that we are shifting focus from feature
development to testing Murano as much as possible.

References:
[1] https://launchpad.net/murano/+milestone/kilo-3
[2] https://blueprints.launchpad.net/murano/+spec/conf-language-support
[3] https://blueprints.launchpad.net/murano/+spec/migrate-to-yaql-vnext
[4] https://blueprints.launchpad.net/murano/+spec/murano-versioning
[5] http://git.openstack.org/cgit/stackforge/murano-specs/
-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.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][FFE] - Reseller Implementation

2015-03-20 Thread Raildo Mascena

Hi Geoff,

I'm very happy to know that companies like Cisco wants to use Reseller.

When we start the Hierarchical Multitenancy implementation we had some use
cases in mind, there is:

- Organize a divisional department of a company.
- Reseller
- Merge/Acquisition
- Contracting parties

The first use case are done with the implementation with HMT in Kilo-1,
here we are requesting the FFE for Reseller and we want to implement the
other use cases in a near future.

These use cases are more focused in the Keystone side, but I believe that
we can expand this feature for the other services, like we are trying to do
implementing Nested Quotas in Nova
https://github.com/openstack/nova-specs/blob/master/specs/kilo/approved/nested-quota-driver-api.rst
(and in other services that have quotas control in Liberty). We are working
to add the HMT support in Horizon.

I like your use cases and we need a Design Session in the next summit,
maybe a cross project session, to define the next steps for Reseller.

Any questions I'm available.

Cheers,

Raildo

On Fri, Mar 20, 2015 at 3:48 PM Geoff Arnold  wrote:

> Glad to see this FFE. The Cisco Cloud Services team is very interested in
> the Reseller use case, and in a couple of possible extensions of the work.
> http://specs.openstack.org/openstack/keystone-specs/
> specs/kilo/reseller.html covers the Keystone use cases, but there are
> several other developments required in other OpenStack projects to come up
> with a complete reseller “solution”. For my information, has anyone put
> together an overarching blueprint which captures the top level Reseller use
> cases and identifies all of the sub-projects and their dependencies? If so,
> wonderful. If not, we might try to work on this in the new Product
> Management WG.
>
> I mentioned “extensions” to http://specs.openstack.org/
> openstack/keystone-specs/specs/kilo/reseller.html . There are two that
> we’re thinking about:
> - the multi-provider reseller: adding the user story where Martha buys
> OpenStack services from two or more
>   providers and presents them to her customers through a single Horizon
> instance
> - stacked reseller: Martha buys OpenStack services from a provider, Alex,
> and also from a reseller, Chris, who
>   purchases OpenStack services from multiple providers
>
> In each case, the unit of resale is a “virtual region”: a provider region
> subsetted using HMT/domains, with IdP supplied by the reseller, and
> constrained by resource consumption policies (e.g. Nova AZ “foo” is not
> available to customers of reseller “bar”).
>
> I strongly doubt that any of this is particularly original, but I haven’t
> seen it written up anywhere.
>
> Cheers,
>
> Geoff Arnold
> Cisco Cloud Services
> geoar...@cisco.com
> ge...@geoffarnold.com
> @geoffarnold
>
> On Mar 19, 2015, at 11:22 AM, Raildo Mascena  wrote:
>
> In addition,
>
> In the last keystone meeting in March 17 in the IRC channel
> 
>  we
> decided that Henry Nash (keystone core) will sponsor this feature as a FFE.
>
> Cheers,
>
> Raildo
>
> On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena  wrote:
>
>> Hi Folks,
>>
>> We’ve discussed a lot in the last Summit about the Reseller use case.
>> OpenStack needs to grow support for hierarchical ownership of objects.This
>> enables the management of subsets of users and projects in a way that is
>> much more comfortable for private clouds, besides giving to public cloud
>> providers the option of reselling a piece of their cloud.
>>
>> More detailed information can be found in the spec for this change at:
>> https://review.openstack.org/#/c/139824
>>
>> The current code change for this is split into 8 patches (to make it
>> easier to review). We currently have 7 patches in code review and we are
>> finishing the last one.
>>
>> Here is the workflow of our patches:
>>
>> 1- Adding a field to enable the possibility to have a project with the
>> domain "feature": https://review.openstack.org/#/c/157427/
>>
>> 2- Change some constraints and create some options to list projects (for
>> is_domain flag, for parent_id):
>> https://review.openstack.org/#/c/159944/
>> https://review.openstack.org/#/c/158398/
>> https://review.openstack.org/#/c/161378/
>> https://review.openstack.org/#/c/158372/
>>
>> 3- Reflect domain operations to project table, mapping domains to
>> projects that have the is_domain attribute set to True. In addition, it
>> changes the read operations to use only the project table. Then, we will
>> drop the Domain Table.
>> https://review.openstack.org/#/c/143763/
>> https://review.openstack.org/#/c/161854/ (Only patch with work in
>> progress)
>>
>> 4- Finally, the inherited role will not be applied to a subdomain and its
>> sub hierarchy. https://review.openstack.org/#/c/164180/
>>
>> Since we have the implementation almost completed, waiting for code
>> review, I am requesting an FFE to enable the implementat

Re: [openstack-dev] [Heat] vnic_type in OS::Neutron::Port

2015-03-20 Thread Zane Bitter


On 20/03/15 14:33, Rob Pothier (rpothier) wrote:


Hi All,

It was brought to my attention that the recent changes with the vnic_type
possibly should not include the colon in the property value.
In the earlier versions of the review the colon was not in the property,
and was appended later.

https://review.openstack.org/#/c/129353/4..5/heat/engine/resources/neutron/port.py

let me know if this should go back to version 4, and I will open a bug
and fix it.


I did some testing and confirmed that the YAML parser handles it without 
issue, though it does look a bit weird. I guess we need a policy on 
extension APIs in general, but after consideration using a colon is 
probably not a terrible way to denote it.


cheers,
Zane.

__
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] [heat][congress] Stack lifecycle plugpoint as an enabler for cloud provider's services

2015-03-20 Thread Zane Bitter

On 19/03/15 06:17, VACHNIS, AVI (AVI) wrote:

Hi,

I'm looking at this interesting blueprint
https://blueprints.launchpad.net/heat/+spec/stack-lifecycle-plugpoint and I
hope you can easily clarify some things to me.
I see the following statements related to this BP:
* [in "problem description" section]: "There are at least two primary use cases. (1)
Enabling holistic (whole-pattern) scheduling of the virtual resources in a template instance
(stack) prior to creating or deleting them. This would usually include making decisions about where
to host virtual resources in the physical infrastructure to satisfy policy requirements. "
* [in "proposed change" section]: "Pre and post operation methods should not modify
the parameter stack(s). Any modifications would be considered to be a bug. "
* [in Patch set 7 comment by Thomas]: "Are the plug-ins allowed to modify the stack?
If yes, what parts can they modify? If not, should some code be added to restrict
modifications?"
* [in Patch set 8 comment by Bill] : "@Thomas Spatzier, The cleanest approach would
be to not allow changes to the stack parameter(s). Since this is cloud-provider-supplied
code, I think that it is reasonable to not enforce this restriction, and to treat any
modifications of the stack parameter(s) as a defect in the cloud provider's extension
code."

I think you're asking the wrong question here; it isn't a question of
what is _allowed_. The plugin runs in the same memory space as
everything else in Heat. It's _allowed_ to do anything that is possible
from Python code. The question for anyone writing a plugin is whether
that's smart.

In terms of guarantees, we can't offer any at all since we don't have
any plugins in-tree and participating in continuous integration testing.

The plugin interface itself should be considered stable (i.e. there
would be a long deprecation cycle for any backward-incompatible
changes), and if anyone brought an accidental breakage to our attention
I think it would be cause for a revert or fix.

The read-only behaviour of the arguments passed to the plugin as
parameters (e.g. the Stack object) is not considered stable. In practice
it tends to change relatively slowly, but there's much less attention
paid to not breaking this for lifecycle plugins than there is e.g. for
Resource plugins.

Finally, the behaviour on write of the arguments is not only not
considered stable, but support for it even working once is explicitly
disclaimed. You are truly on your own if you try this.

From the problem description one might understand it's desired to allow modification of resource placement
(i.e. "making decisions where to host...") by cloud provider plug-point code. Does "should not
modify the parameter stack" blocks this desired capability? Or is it just a rule not to
"touch" original parameters' values but still allow modifying, let's say availability_zone property
as long it's not effected by stack parameters?

I don't think the word 'parameter' there refers to the user-supplied
template parameters, it refers to the formal parameter of the plugin's
do_p[re|ost]_op() method named 'stack'.

On the availability zone thing specifically, I think the way forward is
to give cloud operators a more sophisticated way of selecting the AZ
when the user doesn't specify one (i.e. just requests the default). That
could happen inside Heat, but it would probably be more general if it
happened in Nova.

You might already be aware of another blueprint that's being worked on
for distributing scaling group members among AZs. I haven't caught up
with the latest discussion on that, but I think at some point in the
future we'll want to make that selection pluggable so that operators can
have their own schedulers make the decisions there. However, that would
be a separate plugin interface to the lifecycle plugins.

In case the original purpose of plugpoint mechanism doesn't allow changing the
stack, I'd suggest letting the user creating the stack, explicitly 'grant' the
cloud provider to enhance his stack characteristics by enabling cloud
provider's extra services.
By 'explicitly grant' I thought on introducing a sort of a Policy resource type
that the stack creator will be able to express his desired services he want to
leverage.

Whether the user has given the cloud provider permission is really the
least of the worries.

In case such grant appears in the stack, the plug-point code is allowed to
modify the stack to provide the desired service.

Again, it's not a matter of being allowed. It's a matter of whether the
community would freeze future development (e.g. convergence would have
to be cancelled) in order to maintain complete internal API stability
(we won't), or whether you're prepared to pay someone to constantly
maintain your plugin as internal Heat changes constantly break it (I
wouldn't, but it's up to you).

I guess it may be a possible enabler to Congress' policie

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Assaf Muller  writes:

> Hello everyone,

Hi Assaf,

> The use_namespaces option in the L3 and DHCP Neutron agents controls if you
> can create multiple routers and DHCP networks managed by a single L3/DHCP 
> agent,
> or if the agent manages only a single resource.
>
> Are the setups out there *not* using the use_namespaces option? I'm curious as
> to why, and if it would be difficult to migrate such a setup to use 
> namespaces.
>
> I'm asking because use_namespaces complicates Neutron code for what I gather
> is an option that has not been relevant for years. I'd like to deprecate the 
> option
> for Kilo and remove it in Liberty.

I'm not clear what you're proposing.  After the option is removed, will
the code always behave as it used to when use_namespaces was False, or
as when it was True?

FWIW, my project Calico [1] uses a modified Neutron DHCP agent, where
the behaviour for use_namespaces = False is closer to what we need.  So
we effectively arrange to ignore the use_namespaces setting, and behave
as though it was False [2].

However, that isn't the only change we need, and it's also not clear
that patching the Neutron DHCP agent in this way (or looking at
upstreaming such a patch) will be our long term approach.  Hence this
case probably shouldn't be a significant one for deciding on your
proposal.

Regards,
Neil

[1] http://www.projectcalico.org/
[2] 
https://github.com/Metaswitch/calico-neutron/commit/af2f613368239e2a86b6312bae6e5e70a53d1396

__
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] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Assaf Muller



- Original Message -
> Assaf Muller  writes:
> 
> > Hello everyone,
> 
> Hi Assaf,
> 
> > The use_namespaces option in the L3 and DHCP Neutron agents controls if you
> > can create multiple routers and DHCP networks managed by a single L3/DHCP
> > agent,
> > or if the agent manages only a single resource.
> >
> > Are the setups out there *not* using the use_namespaces option? I'm curious
> > as
> > to why, and if it would be difficult to migrate such a setup to use
> > namespaces.
> >
> > I'm asking because use_namespaces complicates Neutron code for what I
> > gather
> > is an option that has not been relevant for years. I'd like to deprecate
> > the option
> > for Kilo and remove it in Liberty.
> 
> I'm not clear what you're proposing.  After the option is removed, will
> the code always behave as it used to when use_namespaces was False, or
> as when it was True?

I'm sorry, I should have specified: I propose to remove the option and
keep the default behavior, which is True.

> 
> FWIW, my project Calico [1] uses a modified Neutron DHCP agent, where
> the behaviour for use_namespaces = False is closer to what we need.  So
> we effectively arrange to ignore the use_namespaces setting, and behave
> as though it was False [2].
> 
> However, that isn't the only change we need, and it's also not clear
> that patching the Neutron DHCP agent in this way (or looking at
> upstreaming such a patch) will be our long term approach.  Hence this
> case probably shouldn't be a significant one for deciding on your
> proposal.
> 
> Regards,
> Neil
> 
> [1] http://www.projectcalico.org/
> [2]
> https://github.com/Metaswitch/calico-neutron/commit/af2f613368239e2a86b6312bae6e5e70a53d1396
> 

__
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] Deprecating the use_namespaces option - Now's the time to speak up!

Assaf Muller  writes:

> Hello everyone,

Hi Assaf,

> The use_namespaces option in the L3 and DHCP Neutron agents controls if you
> can create multiple routers and DHCP networks managed by a single L3/DHCP 
> agent,
> or if the agent manages only a single resource.
>
> Are the setups out there *not* using the use_namespaces option? I'm curious as
> to why, and if it would be difficult to migrate such a setup to use 
> namespaces.
>
> I'm asking because use_namespaces complicates Neutron code for what I gather
> is an option that has not been relevant for years. I'd like to deprecate the 
> option
> for Kilo and remove it in Liberty.

I'm not clear what you're proposing.  After the option is removed, will
the code always behave as it used to when use_namespaces was False, or
as when it was True?

FWIW, my project Calico [1] uses a modified Neutron DHCP agent, where
the behaviour for use_namespaces = False is closer to what we need.  So
we effectively arrange to ignore the use_namespaces setting, and behave
as though it was False [2].

However, that isn't the only change we need, and it's also not clear
that patching the Neutron DHCP agent in this way (or looking at
upstreaming such a patch) will be our long term approach.  Hence this
case probably shouldn't be a significant one for deciding on your
proposal.

Regards,
Neil

[1] http://www.projectcalico.org/
[2] 
https://github.com/Metaswitch/calico-neutron/commit/af2f613368239e2a86b6312bae6e5e70a53d1396

__
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] Barbican : Unable to send PUT request to store the secret

2015-03-20 Thread Asha Seshagiri

Hi All ,

Now the command for put request  has been successful .the content type for
the header needs to be text/plain.
I thought that the  datatype for the data parameters would determine the
content type of the header.

For ex : In this case the data is passed in the following format   *'{"secret":
{"payload": "secretput", "payload_content_type": "text/plain }}' which is
the JSON type .*

curl -X PUT -H 'content-type:text/plain' -H 'X-Project-Id: 12345' -d
*'{"secret":
{"payload": "secretput", "payload_content_type": "text/plain }}' *
http://localhost:9311/v1/secrets/89d424c3-f4c1-4822-8bd7-7691f40f7ba3

Could anyone provide the clarity on content type of the header

Thanks and Regards,
Asha Seshagiri

On Fri, Mar 20, 2015 at 2:05 PM, Asha Seshagiri 
wrote:

> Hi All ,
>
> I am unable to send the PUT request using the CURL command for storing the
> secret .
>
>
> root@barbican:~# curl -X POST -H 'content-type:application/json' -H
> 'X-Project-Id: 12345' -d '{"secret": {"name": "secretname", "algorithm":
> "aes", "bit_length"  : 256, "mode":
> "cbc"}}' http://localhost:9311/v1/secrets
> {"secret_ref": "
> http://localhost:9311/v1/secrets/84aaac35-daa9-4ffb-b03e-18596729705d"}
>
> curl -X PUT -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d
> '{"secret": {"payload": "secretput", "payload_content_type": "text/plain"
> }}' http://localhost:9311/v1/secrets
> *{"code": 405, "description": "", "title": "Method Not Allowed"}*
>
> It would be great if some one could help me .
> Thanks in advance.
>
> --
> *Thanks and Regards,*
> *Asha Seshagiri*
>



-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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] [Ceilometer]Add hardware pollster of memory buffer and cache

2015-03-20 Thread gordon chung

this seems reasonable... this might fall into same category ironic generated 
metrics (and any other source that has their own defined list of metrics beyond 
ceilometer's list). there was discussion on how to properly handle these cases 
[1][2]

[1] 
http://eavesdrop.openstack.org/meetings/ceilometer/2015/ceilometer.2015-03-05-15.01.log.html
[2] https://review.openstack.org/#/c/130359/

cheers,
gord


From: lgy...@foxmail.com
To: openstack-dev@lists.openstack.org
Date: Thu, 19 Mar 2015 16:44:20 +0800
Subject: [openstack-dev] [Ceilometer]Add hardware pollster of memory buffer 
and cache

Hello everyone,
I am using Ceilometer to monitor both physical servers and virtutal machines in 
IAAS.And I found current Ceilometer only support 4 memory oid of SNMP:
_memory_total_oid = "1.3.6.1.4.1.2021.4.5.0"_memory_avail_real_oid = 
"1.3.6.1.4.1.2021.4.6.0"_memory_total_swap_oid = "1.3.6.1.4.1.2021.4.3.0"   
 _memory_avail_swap_oid = "1.3.6.1.4.1.2021.4.4.0"‍
But in practice, memory cache and buffer are also very useful infomation.
So I'd like to add two hardware pollster, MemoryCachePollster and 
MemoryBufferPollster.‍‍
And I want to know is there anyone else insterested in it and should I submit 
blueprint on launchpad?
Thanks.--Luo gangyiluogan...@chinamobile.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] [ceilometer] Pipeline for notifications does not seem to work

2015-03-20 Thread gordon chung

i can confirm it works for me as well... are there any noticeable errors in the 
ceilometer-agent-notifications log? the snippet below looks sane to me though.

cheers,
gord


> From: idegtia...@mirantis.com
> Date: Fri, 20 Mar 2015 18:35:56 +0200
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [ceilometer] Pipeline for notifications does not 
> seem to work
> 
> Hi Tim
> 
> I've check your case on my devstack. And I've received new hs06 meter
> in my meter list.
> 
> So something wrong with your local env.
> 
> 
> Cheers,
> Igor D.
> Igor Degtiarov
> Software Engineer
> Mirantis Inc
> www.mirantis.com
> 
> 
> On Fri, Mar 20, 2015 at 5:40 PM, Tim Bell  wrote:
> >
> >
> > I’m running Juno with ceilometer and trying to produce a new meter which is
> > based on vcpus * F (where F is a constant that is different for each
> > hypervisor).
> >
> >
> >
> > When I create a VM, I get a new sample for vcpus.
> >
> >
> >
> > However, it does not appear to fire the transformer.
> >
> >
> >
> > The same approach using “cpu” works OK but this one is polling on a regular
> > interval rather than a one off notification when the VM is created.
> >
> >
> >
> > Any suggestions or alternative approaches for how to get a sample based the
> > number of cores scaled by a fixed constant?
> >
> >
> >
> > Tim
> >
> >
> >
> > In my pipeline.yaml sources,
> >
> >
> >
> > - name: vcpu_source
> >
> >   interval: 180
> >
> >   meters:
> >
> >   - "vcpus"
> >
> >   sinks:
> >
> >   - hs06_sink
> >
> >
> >
> > In my transformers, I have
> >
> >
> >
> > - name: hs06_sink
> >
> >   transformers:
> >
> >   - name: "unit_conversion"
> >
> > parameters:
> >
> > target:
> >
> > name: "hs06"
> >
> > unit: "HS06"
> >
> > type: "gauge"
> >
> > scale: "47.0"
> >
> >   publishers:
> >
> >   - notifier://
> >
> >
> >
> >
> >
> >
> >
> >
> > __
> > 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] [Neutron][IPAM] Uniqueness of subnets within a tenant


On 03/20/2015 03:37 PM, Carl Baldwin wrote:

On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes  wrote:

This is a question purely out of curiousity. Why is Neutron averse to the
concept of using tenants as natural ways of dividing up the cloud -- which
at its core means "multi-tenant", on-demand computing and networking?


 From what I've heard others say both in this thread and privately to
me, there are already a lot of cases where a tenant will use the same
address range to stamp out identical topologies.  It occurred to me
that we might even being doing this with our own gate infrastructure
but I don't know for sure.


Is this just due to a lack of traditional use of the term in networking
literature? Or is this something more deep-grained (architecturally) than
that?


We already have NAT serving as the natural divider between them and so
there is no reason to create another artificial way of dividing them
up which will force them to change their practices.  I've come to
terms with this since my earlier replies to this thread.


OK, thanks for the info, Carl, appreciated.

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

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool


On 03/20/2015 03:02 PM, Carl Baldwin wrote:

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes  wrote:

2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of
"pool action"? Eg.:

POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}

which would return a subnet response like this (note prefix_len might
not be needed in this case)

{'id': 'meh',
   'cidr': '192.168.0.0/24 ',
   'gateway_ip': '192.168.0.1',
   'pool_id': 'my_pool_id'}

I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within
a pool, so that might be ok.


+1 to using resource subcollection semantics here.


The issue I see here is that there is a window of time between
requesting the subnet allocation and creating the subnet when the
subnet could be taken by someone else.  We need to acknowledge the
window and address it somehow.


I actually don't think the API URI structure should acknowledge if there 
is or is not a window of time that is involved in some action. Instead, 
whether or not the API call returns a 202 Accepted or a 201 Created 
should be sufficient for communicating that information to the API user.



Does IPAM hold a reservation or something on the subnet to lock out
others?  Or, does the client just retry on failure?  If there are
multiple clients requesting subnet allocations, it seems that IPAM
should keep some state (e.g. a reservation) to avoid giving out the
same one more than once to difference clients at least.


Any API that returns 202 Accepted must return information in the HTTP 
headers (Location: ) about where the client can get an update on 
the status of the resource that should be created:


https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#2xx-success-codes

Whether or not this mechanism returns a reservation resource link 
(something like /reservations/{res_id}), or a link to the resource 
itself (/subnets/{subnet_id}) is entirely implementation-dependent.


I personally prefer the latter, but could go either way.


I think that the first operation should result in full allocation of
the subnet to the tenant.  In this case, I think that the allocation
should have an id and be a first class object (it is not currently).
The tenant will need to manage these allocations like anything else.
The tenant will also be required to delete unused allocations.  This
might be the way to go long-term.


In this case, you are suggesting to make the REST API operation 
synchronous, and should use 201 Created.


There's no reason you couldn't support both the top-level and the 
subcollection resource method of creating the subnet, though.


For instance, these two API calls would essentially be the same:

POST /subnets
{
  'pool_id': 'some_pool',
  'network_id': 'some_network',
  'cidr': '192.168.0.0./24'
}

POST /subnetpools/some_pool/subnets

{
  'network_id': 'some_network',
  'cidr': '192.168.0.0./24'
}

And the above is totally fine, IMO.

Best,
-jay


If allocations have an id.  I think I'd have the client pass in the
allocation id instead of the pool id to the subnet create to
differentiate between asking for a new allocation and using an
existing allocation.

Carl

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



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

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes  wrote:
> How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK.

It isn't a valid *IP* address without the network part.  However, it
can be referred to as the "host address on the network" or the host
part of the IP address.

Carl

__
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] Uniqueness of subnets within a tenant

On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes  wrote:
> This is a question purely out of curiousity. Why is Neutron averse to the
> concept of using tenants as natural ways of dividing up the cloud -- which
> at its core means "multi-tenant", on-demand computing and networking?

>From what I've heard others say both in this thread and privately to
me, there are already a lot of cases where a tenant will use the same
address range to stamp out identical topologies.  It occurred to me
that we might even being doing this with our own gate infrastructure
but I don't know for sure.

> Is this just due to a lack of traditional use of the term in networking
> literature? Or is this something more deep-grained (architecturally) than
> that?

We already have NAT serving as the natural divider between them and so
there is no reason to create another artificial way of dividing them
up which will force them to change their practices.  I've come to
terms with this since my earlier replies to this thread.

Carl

__
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][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:09 PM, Dean Troyer  wrote:
> Template is totally the wrong word.  It is a host address without a network.
> The prefix is there for the same purpose, to OR it back into a network
> address.
>
> I just want us to stop inventing things that already exist.  You want to
> specify the gateway IP, to get that you need a network address, presumably
> to be allocated somewhere and a host address.  OR them together and you have
> an IP address.

I'm not sure template is the wrong word.  But, I think we're just
arguing terminology now.  To me, calling it a template indicates that
it must be combined with something else before it is usable for our
purpose.  Here are some options for what to call the attribute:

gateway_ip_template: '0.0.0.1'
gateway_ip_host:  '0.0.0.1'
gateway_ip_host_part:  '0.0.0.1'

I'm sure there are 100 other names we could use.  The key take-aways
for me are that we don't use '*.*.*.1' and that we don't pass the
host-only part of the address as the 'gateway_ip'.  So, these are
wrong IMO:

gateway_ip:  '0.0.0.1'
gateway_ip_template: '*.*.*.1'
gateway_ip_host_port: '*.*.*.1'

Carl

__
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][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:07 PM, Jay Pipes  wrote:
> On 03/20/2015 02:51 PM, Carl Baldwin wrote:
>>
>> On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes  wrote:
>>>
>>> What about this instead?
>>>
>>> POST /v2.0/subnets
>>>
>>> {
>>>'network_id': 'meh',
>>>'gateway_ip_template': '*.*.*.1'
>>>'prefix_len': 24,
>>>'pool_id': 'some_pool'
>>> }
>>>
>>> At least that way it's clear the gateway attribute is not an IP, but a
>>> template/string instead?
>>
>>
>> I thought about doing *s but in the world of Classless Inter-Domain
>> Routing where not all networks are /24, /16, or /8 it seemed a bit
>> imprecise.  But, maybe that doesn't matter.
>
>
> Understood.
>
>> I think the more important difference with your proposal here is that
>> it is passed as a new attribute called 'gateway_ip_template'.  I don't
>> think that attribute would ever be sent back to the user.  Is it ok to
>> have write-only attributes?  Is everyone comfortable with that?
>
>
> I don't see anything wrong with attributes that are only in the request. I
> mean, we have attributes that are only in the response (things like status,
> for example).
>
> Looking at the EC2 API, they support "write-only attributes" as well, for
> just this purpose:
>
> http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
>
> The MaxCount and MinCount attributes are not in the response but are in the
> request. Same thing for Nova's POST /servers REST API (min_count,
> max_count).

Makes sense.  I think I like this "gateway_ip_template" attribute then
for this purpose.

Carl

__
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][neutron] Best API for generating subnets from pool


On 03/20/2015 02:51 PM, Carl Baldwin wrote:

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes  wrote:

What about this instead?

POST /v2.0/subnets

{
   'network_id': 'meh',
   'gateway_ip_template': '*.*.*.1'
   'prefix_len': 24,
   'pool_id': 'some_pool'
}

At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?


I thought about doing *s but in the world of Classless Inter-Domain
Routing where not all networks are /24, /16, or /8 it seemed a bit
imprecise.  But, maybe that doesn't matter.


Understood.


I think the more important difference with your proposal here is that
it is passed as a new attribute called 'gateway_ip_template'.  I don't
think that attribute would ever be sent back to the user.  Is it ok to
have write-only attributes?  Is everyone comfortable with that?


I don't see anything wrong with attributes that are only in the request. 
I mean, we have attributes that are only in the response (things like 
status, for example).


Looking at the EC2 API, they support "write-only attributes" as well, 
for just this purpose:


http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html

The MaxCount and MinCount attributes are not in the response but are in 
the request. Same thing for Nova's POST /servers REST API (min_count, 
max_count).


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

Re: [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

+1  Would like to hear feedback hoping that deprecation is viable.

Carl

On Fri, Mar 20, 2015 at 12:57 PM, Assaf Muller  wrote:
> Hello everyone,
>
> The use_namespaces option in the L3 and DHCP Neutron agents controls if you
> can create multiple routers and DHCP networks managed by a single L3/DHCP 
> agent,
> or if the agent manages only a single resource.
>
> Are the setups out there *not* using the use_namespaces option? I'm curious as
> to why, and if it would be difficult to migrate such a setup to use 
> namespaces.
>
> I'm asking because use_namespaces complicates Neutron code for what I gather
> is an option that has not been relevant for years. I'd like to deprecate the 
> option
> for Kilo and remove it in Liberty.
>
>
> Assaf Muller, Cloud Networking Engineer
> Red Hat
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:58 PM, Dean Troyer  wrote:
>> I thought about doing *s but in the world of Classless Inter-Domain
>> Routing where not all networks are /24, /16, or /8 it seemed a bit
>> imprecise.  But, maybe that doesn't matter.
>
>
> So do a CIDR host address:  0.0.0.1/24 can be merged into a subnet just as
> easily as it can be masked out.

Dean, I'm not sure what you're suggesting.  Are you suggesting that
0.0.0.1/24 is suitable as a template for the gateway?  If so, that is
what I had originally proposed in the spec and what others seemed to
object to.

Maybe what others didn't like was that a template was passed in for
gateway_ip.  In this case, does passing a template like this as
'gateway_ip_template' make them feel better?

Carl

__
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] Barbican : Unable to send PUT request to store the secret

2015-03-20 Thread Asha Seshagiri

Hi All ,

I am unable to send the PUT request using the CURL command for storing the
secret .


root@barbican:~# curl -X POST -H 'content-type:application/json' -H
'X-Project-Id: 12345' -d '{"secret": {"name": "secretname", "algorithm":
"aes", "bit_length"  : 256, "mode":
"cbc"}}' http://localhost:9311/v1/secrets
{"secret_ref": "
http://localhost:9311/v1/secrets/84aaac35-daa9-4ffb-b03e-18596729705d"}

curl -X PUT -H 'content-type:application/json' -H 'X-Project-Id: 12345' -d
'{"secret": {"payload": "secretput", "payload_content_type": "text/plain"
}}' http://localhost:9311/v1/secrets
*{"code": 405, "description": "", "title": "Method Not Allowed"}*

It would be great if some one could help me .
Thanks in advance.

-- 
*Thanks and Regards,*
*Asha Seshagiri*
__
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][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes  wrote:
>> 2) Is the action of creating a subnet from a pool better realized as a
>> different way of creating a subnet, or should there be some sort of
>> "pool action"? Eg.:
>>
>> POST /subnet_pools/my_pool_id/subnet
>> {'prefix_len': 24}
>>
>> which would return a subnet response like this (note prefix_len might
>> not be needed in this case)
>>
>> {'id': 'meh',
>>   'cidr': '192.168.0.0/24 ',
>>   'gateway_ip': '192.168.0.1',
>>   'pool_id': 'my_pool_id'}
>>
>> I am generally not a big fan of RESTful actions. But in this case the
>> semantics of the API operation are that of a subnet creation from within
>> a pool, so that might be ok.
>
>
> +1 to using resource subcollection semantics here.

The issue I see here is that there is a window of time between
requesting the subnet allocation and creating the subnet when the
subnet could be taken by someone else.  We need to acknowledge the
window and address it somehow.

Does IPAM hold a reservation or something on the subnet to lock out
others?  Or, does the client just retry on failure?  If there are
multiple clients requesting subnet allocations, it seems that IPAM
should keep some state (e.g. a reservation) to avoid giving out the
same one more than once to difference clients at least.

I think that the first operation should result in full allocation of
the subnet to the tenant.  In this case, I think that the allocation
should have an id and be a first class object (it is not currently).
The tenant will need to manage these allocations like anything else.
The tenant will also be required to delete unused allocations.  This
might be the way to go long-term.

If allocations have an id.  I think I'd have the client pass in the
allocation id instead of the pool id to the subnet create to
differentiate between asking for a new allocation and using an
existing allocation.

Carl

__
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] [cinder] May you reconsider about huawei driver?

2015-03-20 Thread Andreas Jaeger

On 03/20/2015 04:48 PM, Walter A. Boring IV wrote:
> [...]
>>  
>>
>> *https://review.openstack.org/#/c/152401/
>>
>> Post time: 3-18 23:08:45
>>
> This patch also has NO Huawei Volume CI check results.

It has results on patches 5, 6, 7, 25, 26, 28, and 45. 45 was the only
successfull one. To see all of them you need to "Toggle CI",

Still I agree with your conclusion that this is not consistant evidence,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
   Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
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] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Assaf Muller

Hello everyone,

The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP agent,
or if the agent manages only a single resource.

Are the setups out there *not* using the use_namespaces option? I'm curious as
to why, and if it would be difficult to migrate such a setup to use namespaces.

I'm asking because use_namespaces complicates Neutron code for what I gather
is an option that has not been relevant for years. I'd like to deprecate the 
option
for Kilo and remove it in Liberty.


Assaf Muller, Cloud Networking Engineer
Red Hat

__
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] Neutron extenstions

2015-03-20 Thread Armando M.

In order to track this, and for Kyle's sanity, I have created these two RC1
bugs:

- https://bugs.launchpad.net/neutron/+bug/1434667
- https://bugs.launchpad.net/neutron/+bug/1434671

Please, let's make sure that whatever approach we decide on, the resulting
code fix targets those two bugs.

Thanks,
Armando

On 20 March 2015 at 09:51, Armando M.  wrote:

>
>
> On 19 March 2015 at 23:59, Akihiro Motoki  wrote:
>
>> Forwarding my reply to the other thread too...
>>
>> Multiple threads on the same topic is confusing.
>> Can we use this thread if we continue the discussion?
>> (The title of this thread looks approapriate)
>>
>> 
>> API extension is the only way that users know which features are
>> available unitl we support API microversioning (v2.1 or something).
>> I believe VLAN transparency support should be implemented as an
>> extension, not by changing the core resources attribute directly.
>> Otherwise users (including Horizon) cannot know we field is available or
>> not.
>>
>> Even though VLAN transparency and MTU suppotrs are basic features, it
>> is better to be implemented as an extension.
>> Configuration does not help from API perspective as it is not visible
>> through the API.
>>
>
> I was only suggesting the configuration-based approach because it was
> simpler and it didn't lead to the evil mixin business. Granted it does not
> help from the API perspective, but we can hardly claim good discoverability
> of the API capabilities anyway :)
>
> That said, I'd be ok with moving one or both of these attributes to the
> extension framework. I thought that consensus on having them as core
> resources had been reached at the time the spec proposal.
>
>
>>
>> We are discussing moving away from extension attributes as Armando
>> commented,
>> but I think it is discussed about resources/attributes which are
>> already used well and required.
>> It looks natural to me that new resources/attributes are implemented
>> via an extension.
>> The situation may be changed once we have support of API microversioning.
>> (It is being discussed in the context of Nova API microvesioning in
>> the dev list started by Jay Pipes.)
>>
>> In my understanding, the case of IPv6 two mode is an exception.
>> From the initial design we would like to have fully support of IPv6 in
>> subnet resource,
>> but through the discussion of IPv6 support it turns out some more
>> modes are required,
>> and we decided to change the subnet "core" resource. It is the exception.
>>
>> Thanks,
>> Akihiro
>>
>> 2015-03-20 8:23 GMT+09:00 Armando M. :
>> > Forwarding my reply to the other thread here:
>> >
>> > 
>> >
>> > If my memory does not fail me, changes to the API (new resources, new
>> > resource attributes or new operations allowed to resources) have always
>> been
>> > done according to these criteria:
>> >
>> > an opt-in approach: this means we know the expected behavior of the
>> plugin
>> > as someone has coded the plugin in such a way that the API change is
>> > supported;
>> > an opt-out approach: if the API change does not require explicit backend
>> > support, and hence can be deemed supported by all plugins.
>> > a 'core' extension (ones available in neutron/extensions) should be
>> > implemented at least by the reference implementation;
>> >
>> > Now, there might have been examples in the past where criteria were not
>> met,
>> > but these should be seen as exceptions rather than the rule, and as
>> such,
>> > fixed as defects so that an attribute/resource/operation that is
>> > accidentally exposed to a plugin will either be honored as expected or
>> an
>> > appropriate failure is propagated to the user. Bottom line, the server
>> must
>> > avoid to fail silently, because failing silently is bad for the user.
>> >
>> > Now both features [1] and [2] violated the opt-in criterion above: they
>> > introduced resources attributes in the core models, forcing an
>> undetermined
>> > behavior on plugins.
>> >
>> > I think that keeping [3,4] as is can lead to a poor user experience; IMO
>> > it's unacceptable to let a user specify the attribute, and see that
>> > ultimately the plugin does not support it. I'd be fine if this was an
>> > accident, but doing this by design is a bit evil. So, I'd suggest the
>> > following, in order to keep the features in Kilo:
>> >
>> > Patches [3, 4] did introduce config flags to control the plugin
>> behavior,
>> > but it looks like they were not applied correctly; for instance, the
>> > vlan_transparent case was only applied to ML2. Similarly the MTU config
>> flag
>> > was not processed server side to ensure that plugins that do not support
>> > advertisement do not fail silently. This needs to be rectified.
>> > As for VLAN transparency, we'd need to implement work item 5 (of 6) of
>> spec
>> > [2], as this extension without at least a backend able to let tagged
>> traffic
>> > pass doesn't seem right.
>> > Ensure we sort out the API tests so that we know how the features
>> behave.
>>

Re: [openstack-dev] [cinder] Request exemption for removal of NetApp FC drivers (no voting CI)

On 12:33 Fri 20 Mar , ClaytonLuce, Timothy wrote:
> I'd like to point out that for NetApp FC drivers NetApp has been in
> discussions and updating progress on these drivers since their submission.
> 
> I will point out a discussion in the Nov Core meeting where I brought up the
> challenge around FC environments and the response I received:

> NetApp has in good faith been working toward implementing a CI for FC,
> I won't go into the challenges of spending $$ for lab equipment to build out
> a scalable quality CI system but suffice it to say the lab equipment is on
> order and scheduled for arrival the first part of April, at which point we
> can put in place the CI for FC.

1) We've been talking about CI's since Feburary 2014. That's really too bad
   this took so long. The deadline itself has been overly announced on the
   mailing list and Cinder IRC meetings. [1][2][3][4][5][6][7][8]

2) We have a number of FC drivers today that had no problem meeting this
   deadline that was expressed in November 2014.

3) I've barely received updates from Netapp folks on progress here. I'm the
   only point of contact, so if you weren't talking to me, then it's unknown.
   I've expressed this to a number of your engineers and in my announcements
   about the CI deadline [8]

I had to engage with Netapp to get updates, no one came to me with updates. The
last update I heard from one of your engineers was, we bought the hardware,
but it's just sitting there. That is not acceptable with us being past the
deadline, and shows a clear sign of this not being a priority.

> NetApp has been very forthcoming in our progress and have gotten all our
> other CI systems in place for 7-mode iSCSI/NFS, cDOT iSCSI/NFS and E-Series.
> 
> I respectfully request that NetApp FC be removed from this list of drivers to
> be removed for Kilo and placed back in the releaes and we can negotiate an
> agreed upon time as to when the CI system for these drivers will be in place.

There will be no negotiating on what is an acceptable timeline for Netapp. What
we all agreed to as a *community* back at the summit and Cinder IRC meeting
was it.

[1] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[2] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html
[4] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html
[5] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html
[6] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html
[8] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html

-- 
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] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes  wrote:
> What about this instead?
>
> POST /v2.0/subnets
>
> {
>   'network_id': 'meh',
>   'gateway_ip_template': '*.*.*.1'
>   'prefix_len': 24,
>   'pool_id': 'some_pool'
> }
>
> At least that way it's clear the gateway attribute is not an IP, but a
> template/string instead?

I thought about doing *s but in the world of Classless Inter-Domain
Routing where not all networks are /24, /16, or /8 it seemed a bit
imprecise.  But, maybe that doesn't matter.

I think the more important difference with your proposal here is that
it is passed as a new attribute called 'gateway_ip_template'.  I don't
think that attribute would ever be sent back to the user.  Is it ok to
have write-only attributes?  Is everyone comfortable with that?

Carl

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

Re: [openstack-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

2015-03-20 Thread Alka Deshpande



On 3/20/15 2:19 PM, Mike Perez wrote:

On 12:37 Fri 20 Mar , Alka Deshpande wrote:

Hi MIke,

My team and I would like to respectfully request a revert for the
change at:https://review.openstack.org/#/c/165939/ to bring back the
ZFSSA drivers to Kilo. Oracle has the CI working internally and we
are in the process of going through internal security review, which
is expected to be done by the end of March.

In the mean time, we have gotten permission to post test results to
an external webserver. We will have results reported by the end of
the week. If need be, we can show proof of  CI running internally by
pasting results to pastebin: http://paste.openstack.org/show/193964/

We have been working diligently on setting up the CI system, and we
have been keeping you updated since the mid-cycle meetup in Austin.
We really appreciate your consideration.  We do take CI setup effort
very seriously and striving to get it to the level of your
satisfaction.

The tag for Kilo in Cinder has already happened, so it's too late to revert. We
may be able to revisit this in Kilo RC, but I want to see your CI reporting
reliably now to then to Cinder reviews.
Thanks for the revisit consideration for Kilo RC. My team members will 
be in touch with you with the

CI reporting information, shortly.

thanks
-Alka


FWIW, everyone who was removed told me they were taking it seriously too. Just
not serious enough to have CI's reporting by the overly announced deadline.
[1][2][3][4][5][6][7][8]

[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html
[2] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html
[4] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html
[5] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html
[6] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html
[8] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.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] [Keystone][FFE] - Reseller Implementation

2015-03-20 Thread Geoff Arnold

Glad to see this FFE. The Cisco Cloud Services team is very interested in the 
Reseller use case, and in a couple of possible extensions of the work. 
http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html 
 
covers the Keystone use cases, but there are several other developments 
required in other OpenStack projects to come up with a complete reseller 
“solution”. For my information, has anyone put together an overarching 
blueprint which captures the top level Reseller use cases and identifies all of 
the sub-projects and their dependencies? If so, wonderful. If not, we might try 
to work on this in the new Product Management WG.

I mentioned “extensions” to 
http://specs.openstack.org/openstack/keystone-specs/specs/kilo/reseller.html 
 
. There are two that we’re thinking about:
- the multi-provider reseller: adding the user story where Martha buys 
OpenStack services from two or more 
  providers and presents them to her customers through a single Horizon instance
- stacked reseller: Martha buys OpenStack services from a provider, Alex, and 
also from a reseller, Chris, who 
  purchases OpenStack services from multiple providers 

In each case, the unit of resale is a “virtual region”: a provider region 
subsetted using HMT/domains, with IdP supplied by the reseller, and constrained 
by resource consumption policies (e.g. Nova AZ “foo” is not available to 
customers of reseller “bar”).

I strongly doubt that any of this is particularly original, but I haven’t seen 
it written up anywhere.

Cheers,

Geoff Arnold
Cisco Cloud Services
geoar...@cisco.com 
ge...@geoffarnold.com 
@geoffarnold

> On Mar 19, 2015, at 11:22 AM, Raildo Mascena  wrote:
> 
> In addition, 
> 
> In the last keystone meeting in March 17 in the IRC channel 
> 
>  we decided that Henry Nash (keystone core) will sponsor this feature as a 
> FFE.
> 
> Cheers,
> 
> Raildo
> 
> On Tue, Mar 17, 2015 at 5:36 PM Raildo Mascena  > wrote:
> Hi Folks,
> 
> We’ve discussed a lot in the last Summit about the Reseller use case. 
> OpenStack needs to grow support for hierarchical ownership of objects.This 
> enables the management of subsets of users and projects in a way that is much 
> more comfortable for private clouds, besides giving to public cloud providers 
> the option of reselling a piece of their cloud.
> 
> More detailed information can be found in the spec for this change at: 
> https://review.openstack.org/#/c/139824 
> 
> 
> The current code change for this is split into 8 patches (to make it easier 
> to review). We currently have 7 patches in code review and we are finishing 
> the last one.
> 
> Here is the workflow of our patches:
> 
> 1- Adding a field to enable the possibility to have a project with the domain 
> "feature": https://review.openstack.org/#/c/157427/ 
> 
> 
> 2- Change some constraints and create some options to list projects (for 
> is_domain flag, for parent_id):
> https://review.openstack.org/#/c/159944/ 
> 
> https://review.openstack.org/#/c/158398/ 
> 
> https://review.openstack.org/#/c/161378/ 
> 
> https://review.openstack.org/#/c/158372/ 
> 
> 
> 3- Reflect domain operations to project table, mapping domains to projects 
> that have the is_domain attribute set to True. In addition, it changes the 
> read operations to use only the project table. Then, we will drop the Domain 
> Table.
> https://review.openstack.org/#/c/143763/ 
> 
> https://review.openstack.org/#/c/161854/ 
>  (Only patch with work in progress)
> 
> 4- Finally, the inherited role will not be applied to a subdomain and its sub 
> hierarchy. https://review.openstack.org/#/c/164180/ 
> 
> 
> Since we have the implementation almost completed, waiting for code review, I 
> am requesting an FFE to enable the implementation of this last patch and work 
> to have this implementation merged in Kilo.
> 
> 
> Raildo
> __
> 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

Re: [openstack-dev] [Nova] Liberty specs are now open

Neil Jerram  writes:

> Hi Michael,
>
> Michael Still  writes:
>
>> For specs approved in Juno or Kilo, there is a fast track approval
>> process for Liberty. The steps to get your spec re-approved are:
>>
>>  - Copy your spec from the specs//approved directory to
>> the specs/liberty/approved directory. [...]
>
> Perhaps I'm misunderstanding, or have failed to pull the latest
> nova-specs repo correctly, but I don't see a specs/liberty/approved
> directory.  Do you mean just specs/liberty ?

Ah, I guess the intention may be that a proposed spec patch would
_create_ the specs/liberty/approved directory.  Is that right?

   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-dev] [Heat] vnic_type in OS::Neutron::Port

2015-03-20 Thread Rob Pothier (rpothier)


Hi All,

It was brought to my attention that the recent changes with the vnic_type
possibly should not include the colon in the property value.
In the earlier versions of the review the colon was not in the property,
and was appended later.

https://review.openstack.org/#/c/129353/4..5/heat/engine/resources/neutron/port.py

let me know if this should go back to version 4, and I will open a bug
and fix it.

Thanks - Rob
__
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] Uniqueness of subnets within a tenant


On 03/11/2015 06:48 PM, John Belamaric wrote:

This has been settled and we're not moving forward with it for Kilo. I
agree tenants are an administrative concept, not a networking one so
using them for uniqueness doesn't really make sense.

In Liberty we are proposing a new grouping mechanism, as you call it,
specifically for the purpose of defining uniqueness - address scopes.
This would be owned by a tenant but could be shared across tenants. It's
still in the early stages of definition though, and more discussion is
needed but should probably wait until after Kilo is out!


This is a question purely out of curiousity. Why is Neutron averse to 
the concept of using tenants as natural ways of dividing up the cloud -- 
which at its core means "multi-tenant", on-demand computing and networking?


Is this just due to a lack of traditional use of the term in networking 
literature? Or is this something more deep-grained (architecturally) 
than that?


Genuinely curious.

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

Re: [openstack-dev] [cinder] May you reconsider about huawei driver?

On 09:41 Fri 20 Mar , Jay S. Bryant wrote:
> Mike,
> 
> Looks like this removal may have been a mistake.  We should readdress.

This was not a mistake. As Walt has mentioned that CI run failed anyways. Also
if you take a look at Huawei's CI reporting history, it's not that often AND
not reliable [1].

This is not satisfactory meeting the requirements. If we're saying they're
having networking issues from January to now, this really sounds like to me it
was *not* a priority.

[1] - 
https://review.openstack.org/#/q/reviewer:+huawei-ci+project:openstack/cinder,n,z

-- 
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] [Nova] Liberty specs are now open

Hi Michael,

Michael Still  writes:

> For specs approved in Juno or Kilo, there is a fast track approval
> process for Liberty. The steps to get your spec re-approved are:
>
>  - Copy your spec from the specs//approved directory to
> the specs/liberty/approved directory. [...]

Perhaps I'm misunderstanding, or have failed to pull the latest
nova-specs repo correctly, but I don't see a specs/liberty/approved
directory.  Do you mean just specs/liberty ?

Thanks,
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] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

On 12:37 Fri 20 Mar , Alka Deshpande wrote:
> Hi MIke,
> 
> My team and I would like to respectfully request a revert for the
> change at:https://review.openstack.org/#/c/165939/ to bring back the
> ZFSSA drivers to Kilo. Oracle has the CI working internally and we
> are in the process of going through internal security review, which
> is expected to be done by the end of March.
> 
> In the mean time, we have gotten permission to post test results to
> an external webserver. We will have results reported by the end of
> the week. If need be, we can show proof of  CI running internally by
> pasting results to pastebin: http://paste.openstack.org/show/193964/
> 
> We have been working diligently on setting up the CI system, and we
> have been keeping you updated since the mid-cycle meetup in Austin.
> We really appreciate your consideration.  We do take CI setup effort
> very seriously and striving to get it to the level of your
> satisfaction.

The tag for Kilo in Cinder has already happened, so it's too late to revert. We
may be able to revisit this in Kilo RC, but I want to see your CI reporting
reliably now to then to Cinder reviews.

FWIW, everyone who was removed told me they were taking it seriously too. Just
not serious enough to have CI's reporting by the overly announced deadline.
[1][2][3][4][5][6][7][8]

[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html
[2] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
[3] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-01-21-16.00.log.html
[4] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-04-16.04.log.html
[5] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-18-16.00.log.html
[6] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-02-25-16.00.log.html
[7] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-04-16.00.log.html
[8] - 
http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-03-18-16.00.log.html

-- 
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] [api][neutron] Best API for generating subnets from pool