date:20150320


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] [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 
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 
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 mailto:geoar...@cisco.com
ge...@geoffarnold.com mailto:ge...@geoffarnold.com
@geoffarnold

 On Mar 19, 2015, at 11:22 AM, Raildo Mascena rail...@gmail.com wrote:
 
 In addition, 
 
 In the last keystone meeting in March 17 in the IRC channel 
 http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log
  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 rail...@gmail.com 
 mailto:rail...@gmail.com 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 
 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/ 
 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/159944/
 https://review.openstack.org/#/c/158398/ 
 https://review.openstack.org/#/c/158398/
 https://review.openstack.org/#/c/161378/ 
 https://review.openstack.org/#/c/161378/
 https://review.openstack.org/#/c/158372/ 
 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/143763/
 https://review.openstack.org/#/c/161854/ 
 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/ 
 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)
Unsubscribe:

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. arma...@gmail.com wrote:



 On 19 March 2015 at 23:59, Akihiro Motoki amot...@gmail.com 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. arma...@gmail.com:
  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.
 
  Now granted that controlling the API via config flags is not the best
  solution, as this was always handled through the extension mechanism,
 but
  since we've been talking about moving away

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

2015-03-20 Thread Mike Perez

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:

snip

 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 jaypi...@gmail.com 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 http://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] [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 amul...@redhat.com 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 03/20/2015 02:51 PM, Carl Baldwin wrote:

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com 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] [cinder] May you reconsider about huawei driver?

2015-03-20 Thread Mike Perez

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

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

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com 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

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

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

On Fri, Mar 20, 2015 at 12:58 PM, Dean Troyer dtro...@gmail.com 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

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


On 03/09/2015 09:05 AM, Salvatore Orlando wrote:

POST /v2.0/subnets
{'network_id': 'meh',
  'gateway_ip': '0.0.0.1',
  'prefix_len': 24,
  'pool_id': 'some_pool'}

would indicate that the user wishes to use the first address in the
range as the gateway IP, and the API would return something like this:


Yeah, the above is definitely icky. (technical term, there...)

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?



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 http://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.


3) Would it be possible to consider putting information about how to
generate a subnet from a pool in the subnet request body as follows?

POST /v2.0/subnets
{
  'pool_info':
 {'pool_id': my_pool_id,
  'prefix_len': 24}
}


-1. Too complicated IMO.

Best,
-jay


This would return a response like the previous.
This approach is in theory simple, but composite attributes proved to a
difficult beast already - for instance you can look at
external_gateway_info in the router definition [4]

Thanks for your time and thanks in advance for your feedback.
Salvatore

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
[2] https://review.openstack.org/#/c/148698/
[3] https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py
[4]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106


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

Neil Jerram neil.jer...@metaswitch.com writes:

 Hi Michael,

 Michael Still mi...@stillhq.com 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/oldrelease/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] 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

[openstack-dev] [neutron][lbaas] Invalid import in tempest v2 api tests

2015-03-20 Thread Vijay Venkatachalam

Hi:

The LBaaS API tests are failing to run because test_pools.py(and other tests as 
well) are importing data_utils  from tempest.common.utils.

Looks like data_utils is moved to tempest_lib now and the API tests need to 
change to import from tempest_lib.

Is someone tracking this?

We are blocked in bringing up a CI for netscaler.

Also, we are thinking of running lbaas CLI tests as part of the CI.

Any suggestions/comments?


Thanks
Vijay


Sent from Surface

__
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] [Horizon] FFE request for Firewall Router insertion BP

2015-03-20 Thread Abishek Subramanian (absubram)

Dear Horizon community,

I would like to request an FFE for the review we have out currently for
the firewall feature in the project dashboard.

The review is at - https://review.openstack.org/#/c/162552/


This feature is very important for the neutron FWaaS community to move the
firewall feature from out of experimental stage.
It allows for firewalls to finally be applied to a router and having
Horizon support for this will greatly enhance the ability to use FWaaS.
The neutron side of the feature got merged just before the K-3 deadline
and there isn¹t a neutron client dependency on Horizon for this.

A final review version to address comments about UT and also a details
page will be made very shortly.
The review in its current state is ready to test and for anyone to try
out. Please make sure to include the q-fwaas service in your local.conf if
testing.


Requesting Akihiro and David to please sponsor reviews (as discussed on
IRC).

Much thanks and kind regards,

Abishek


__
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] About Sahara EDP New Ideas for Liberty

2015-03-20 Thread Andrew Lazarev

Hi Weiting,

1. Add a schedule feature to run the jobs on time:
This request comes from the customer, they usually run the job in a
specific time every day. So it should be great if there
 is a scheduler to help arrange the regular job to run.
Looks like a great feature. And should be quite easy to implement. Feel
free to create spec for that.

2. A more complex workflow design in Sahara EDP:
Current EDP only provide one job that is running on one cluster.
Yes. And ability to run several jobs in one oozie workflow is discussed on
every summit (e.g. 'coordinated jobs' at
https://etherpad.openstack.org/p/kilo-summit-sahara-edp). But for now it
was not a priority

But in a real case, it should be more complex, they usually use multiple
jobs to calculate the data and may use several different type clusters to
process it..
It means that workflow manager should be on Sahara side. Looks like a
complicated feature. But we would be happy to help with designing and
implementing it. Please file proposal for design session on ongoing summit.
Are you going to Vancouver?

Another concern is about Spark, for Spark it cannot use Oozie to do this.
So we need to create an abstract layer to help to implement this kind of
scenarios.
If workflow is on Sahara side it should work automatically for all engines.

Thanks,
Andrew.



On Sun, Mar 8, 2015 at 3:17 AM, Chen, Weiting weiting.c...@intel.com
wrote:

  Hi all.



 We got several feedbacks about Sahara EDP’s future from some China
 customers.

 Here are some ideas we would like to share with you and need your input if
 we can implement them in Sahara(Liberty).



 1. Add a schedule feature to run the jobs on time:

 This request comes from the customer, they usually run the job in a
 specific time every day. So it should be great if there is a scheduler to
 help arrange the regular job to run.



 2. A more complex workflow design in Sahara EDP:

 Current EDP only provide one job that is running on one cluster.

 But in a real case, it should be more complex, they usually use multiple
 jobs to calculate the data and may use several different type clusters to
 process it.

 For example: Raw Data - Job A(Cluster A) - Job B(Cluster B) - Job
 C(Cluster A) - Result

 Actually in my opinion, this kind of job could be easy to implement by
 using Oozie as a workflow engine. But for current EDP, it doesn’t implement
 this kind of complex case.

 Another concern is about Spark, for Spark it cannot use Oozie to do this.
 So we need to create an abstract layer to help to implement this kind of
 scenarios.



 However, any suggestion is welcome.

 Thanks.



 __
 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] [oslo.utils] allow strutils.mask_password to mask keys dynamically

2015-03-20 Thread Doug Hellmann

Excerpts from Matthew Van Dijk's message of 2015-03-20 15:06:08 +:
 I’ve come across a use case for allowing dynamic keys to be made
 secret. The hardcoded list is good for common keys, but there will be
 cases where masking a custom value is useful without having to add it
 to the hardcoded list.

Can you be more specific about what that case is?

My concern with making some keys optional is that we'll have different
security behavior in different apps, because some will mask values
that are not masked in other places. Part of the point of centralizing
behaviors like this is to keep them consistent across all of the
projects.

 I propose we add an optional parameter that is a list of secret_keys
 whose values will be masked.
 There is concern that this will lead to differing levels of security.
 But I disagree as either the message will be masked before passing on
 or mask_password will be called. In this case the developer should be
 aware of the incoming data and manually mask it.
 Keeping with a hardcoded list discourages use of the function.

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

On 19 March 2015 at 23:59, Akihiro Motoki amot...@gmail.com 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)

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

Thanks,
Akihiro

2015-03-20 8:23 GMT+09:00 Armando M. arma...@gmail.com:
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.

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.

Thoughts?
Armando

[1]

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
[2]

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html
[3]

Re: [openstack-dev] [ceilometer] Pipeline for notifications does not seem to work

2015-03-20 Thread Igor Degtiarov

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 tim.b...@cern.ch 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-dev] [OpenStack-Infra] [cinder] Could you please re-consider Oracle ZFS/SA Cinder drivers (iSCSI and NFS)

2015-03-20 Thread Alka Deshpande


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.


Thanks for your time and consideration.

-Alka Deshpande
(Sr. Software Development Manager,
 Oracle Corporation)






__
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] [Manila] Nominate Igor Malinovskiy for core team

2015-03-20 Thread Valeriy Ponomaryov

+1 from me.


On 03/18/2015 03:04 PM, Ben Swartzlander wrote:

 Igor (u_glide on IRC) joined the Manila team back in December and has
 done a consistent amount of reviews and contributed significant new core
 features in the last 2-3 months. I would like to nominate him to join the
 Manila core reviewer team.

 -Ben Swartzlander
 Manila PTL


 __

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




-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@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 ge...@geoffarnold.com 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 rail...@gmail.com wrote:

In addition,

In the last keystone meeting in March 17 in the IRC channel
http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2015-03-17.log
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 rail...@gmail.com 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.

[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] [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 neil.jer...@metaswitch.com wrote:
 Neil Jerram neil.jer...@metaswitch.com writes:

 Hi Michael,

 Michael Still mi...@stillhq.com 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/oldrelease/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

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

Davanum Srinivas dava...@gmail.com 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] [api][neutron] Best API for generating subnets from pool

On Fri, Mar 20, 2015 at 1:09 PM, Dean Troyer dtro...@gmail.com 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] [Neutron][IPAM] Uniqueness of subnets within a tenant

On Fri, Mar 20, 2015 at 12:31 PM, Jay Pipes jaypi...@gmail.com 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 03/20/2015 03:02 PM, Carl Baldwin wrote:

On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com 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 http://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: URI) 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] [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 jaypi...@gmail.com 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] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

Assaf Muller amul...@redhat.com 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!

Assaf Muller amul...@redhat.com writes:

Hello everyone,

Hi Assaf,

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?

Regards,
Neil

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

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] [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 tim.b...@cern.ch 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] 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 asha.seshag...@gmail.com
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] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

2015-03-20 Thread Assaf Muller

- Original Message -
Assaf Muller amul...@redhat.com writes:

Hello everyone,

Hi Assaf,

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.

Regards,
Neil

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

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' policies as well.

That

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

On Fri, Mar 20, 2015 at 1:07 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 03/20/2015 02:51 PM, Carl Baldwin wrote:

 On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com 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