date:20140527

Hi-

Our CI FTP server is active now.

You may check the same at http://115.249.211.42/


--
Trinath Somanchi - B39208
trinath.soman...@freescale.com | extn: 4048

-Original Message-
From: trinath.soman...@freescale.com [mailto:trinath.soman...@freescale.com] 
Sent: Wednesday, May 28, 2014 12:28 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

Hi Kyle-

I'm working the issues with our FTP server which is hosting the CI testing logs.

Will update the status of the Server in this Email chain.

-
Trinath



From: Kyle Mestery 
Sent: Wednesday, May 28, 2014 12:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

I've marked it as Juno-1 for now, but as Salvatore indicated, there are some 
issues with third party testing which need to be addressed before this can be 
merged. It would be a good idea to attend the IRC meeting Anita pointed out as 
well.

Thanks,
Kyle

On Tue, May 27, 2014 at 1:45 PM, trinath.soman...@freescale.com 
 wrote:
> Hi Kyle-
>
> The BP Spec approved.
>
> https://review.openstack.org/#/c/88190/
>
> Kindly consider my BP spec for Juno-1.
>
> Thanking all the code reviewers for their time to review my ML2 MD Spec and 
> making me to improve the spec.
>
> -
> Trinaths
>
> 
> From: Kyle Mestery 
> Sent: Tuesday, May 27, 2014 10:46 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav  wrote:
>> Hi,
>>
>> I have been working on the port mirroring blueprint and i was asked 
>> to submit a neutron spec related to this I have drafter the spec and 
>> ready to commit it to the 
>> 'git://git.openstack.org/openstack/neutron-specs' repository for 
>> review. Since the blueprint for this was old i was asked to submit 
>> the spec for review. should i also bring the old blueprint to life by 
>> linking it the spec that i will commit.
>>
> You can file a BP in launchpad. We're using those to track progress 
> against milestones for release management reasons. Please see the 
> instructions here [1]. Once the BP is filed in neutron-specs, reviewed 
> and approved, we can track it to milestones. But at this point, this 
> won't make it to Juno-1, given that's 2 weeks away.
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>> We are calling the new spec Tap-as-a-Service
>>
>> Cheers,
>>
>> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}
>>
>>
>> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery 
>> 
>> wrote:
>>>
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are 
>>> documented at the link below [1]. There are a large number of BPs 
>>> currently under review right now in neutron-specs. If we land some 
>>> of those specs this week, it's possible some of these could make it 
>>> into Juno-1, pending review cycles and such. But I just wanted to 
>>> highlight that I removed a large number of BPs from targeting Juno-1 
>>> now which did not have specifications linked to them nor 
>>> specifications which were actively under review in neutron-specs.
>>>
>>> Also, a gentle reminder that the process for submitting 
>>> specifications to Neutron is documented here [2].
>>>
>>> Thanks, and please reach out to me if you have any questions!
>>>
>>> Kyle
>>>
>>> [1] https://launchpad.net/neutron/+milestone/juno-1
>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

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

Re: [openstack-dev] [Horizon] Selenium test fixes

2014-05-27 Thread Kieran Spear

No failures in the last 24 hours. \o/

On 26 May 2014 23:44, Kieran Spear  wrote:
> Hi peeps,
>
> Could I ask reviewers to prioritise the following:
>
> https://review.openstack.org/#/c/95392/
>
> It should eliminate our selenium gate failures, which seem to be happening 
> many times per day now.
>
> Cheers,
> Kieran
>

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread mar...@redhat.com

On 27/05/14 17:14, Kyle Mestery wrote:
> Hi Neutron developers:
> 
> I've spent some time cleaning up the BPs for Juno-1, and they are
> documented at the link below [1]. There are a large number of BPs
> currently under review right now in neutron-specs. If we land some of
> those specs this week, it's possible some of these could make it into
> Juno-1, pending review cycles and such. But I just wanted to highlight
> that I removed a large number of BPs from targeting Juno-1 now which
> did not have specifications linked to them nor specifications which
> were actively under review in neutron-specs.
> 
> Also, a gentle reminder that the process for submitting specifications
> to Neutron is documented here [2].
> 
> Thanks, and please reach out to me if you have any questions!


Hi Kyle,

Can you please consider my "PUT /subnets/subnet allocation_pools:{}"
review at [1] for Juno-1? Also, I see you have included a bug [1] and
associated review [2] that I've worked on but the review is already
pushed to master. Is it there for any pending backports?

thanks! marios

[1] https://review.openstack.org/#/c/62042/
[2] https://bugs.launchpad.net/neutron/+bug/1255338
[3] https://review.openstack.org/#/c/59212/


> 
> Kyle
> 
> [1] https://launchpad.net/neutron/+milestone/juno-1
> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Eugene Nikanorov

Hi folks,

>From lbaas design session I have an impression that we need to have a kind
of merge of existing API and new proposed API.
E.g. the blueprint implementation should not be brand new API and DB
backend.
So I'd say from implementation perspective we may want to minimize amount
of changes for the patch that will bring existing model to a new design.
Such things as relationships M:N instead of 1:N are usually complicate
things a lot, so I'd probably consider to implement them in following
patches.
Changing 1:N to 1:1 (pools - healthmons) falls into another category: we
need to deprecate this rather than remove at once.
Same applies for status/status_description: we need to deprecate those.

Thanks,
Eugene.



On Wed, May 28, 2014 at 7:36 AM, Doug Wiegley  wrote:

>  Hi Stephen,
>
>  > Doug:  What do you think of the idea of having both IPv4 and IPv6
> attributes on a 'load balancer' object? One doesn't need to have a single
> appliance serving both types of addresses for the listener, but there's
> certainly a chance (albeit small) to hit an async scenario if they're not.
>
>  I made the same suggestion in the bp review , so I have no issue with
> it.  :-)
>
>  I can think of at least one backend that pairs ip:port in their listener
> object, so the driver for that can implement the v4/v6 model natively with
> no issue (but not a true N:N).  For the ones that don’t, at least the race
> condition outlined earlier is limited to two objects, which is ok if the
> use case is common enough to warrant it.  I’d still prefer that issue be
> handled as far up the chain as possible, but I’d be ok.
>
>  Doug
>
>
>   From: Stephen Balukoff 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, May 27, 2014 at 8:42 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in
> object model refactor blueprint
>
>   Hi y'all!
>
>
> On Tue, May 27, 2014 at 12:32 PM, Brandon Logan <
> brandon.lo...@rackspace.com> wrote:
>
>> Referencing this blueprint:
>>
>> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>>
>> Anyone who has suggestions to possible issues or can answer some of
>> these questions please respond.
>>
>>
>> 1. LoadBalancer to Listener relationship M:N vs 1:N
>> The main reason we went with the M:N was so IPv6 could use the same
>> listener as IPv4.  However this can be accomplished by the user just
>> creating a second listener and pool with the same configuration.  This
>> will end up being a bad user experience when the listener and pool
>> configuration starts getting complex (adding in TLS, health monitors,
>> SNI, etc). A good reason to not do the M:N is because the logic on might
>> get complex when dealing with status.  I'd like to get people's opinions
>> on this on whether we should do M:N or just 1:N.  Another option, is to
>> just implement 1:N right now and later implement the M:N in another
>> blueprint if it is decided that the user experience suffers greatly.
>>
>> My opinion: I like the idea of leaving it to another blueprint to
>> implement.  However, we would need to watch out for any major
>> architecture changes in the time itis not implemented that could make
>> this more difficult than what it needs to be.
>>
>
>  Is there such a thing as a 'possibly planned but not implemented design'
> to serve as a placeholder when considering other in-parallel blueprints and
> designs which could potentially conflict with the ability to implement an
> anticipated design like this?  (I'm guessing "no." I really wish we had a
> better design tracking tool than blueprint.)
>
>  Anyway, I don't have a problem with implementing 1:N right now. But, I
> do want to point out: The one and only common case I've seen where listener
> re-use actually makes a lot of sense (IPv4 and IPv6 for same listener)
> could be alleviated by adding separate ipv4 and ipv6 attributes to the
> loadbalancer object. I believe this was shot down when people were still
> calling it a VIP for philosophical reasons. Are people more open to this
> idea now that we're calling the object a 'load balancer'?  ;)
>
> Does anyone have any other use cases where listener re-use makes sense?
>
>
>>
>> 2. Pool to Health Monitor relationship 1:N vs 1:1
>> Currently, I believe this is 1:N however it was suggested to deprecate
>> this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
>> objections to channging to 1:1?
>>
>> My opinion: I'm for 1:1 as long as there aren't any major reasons why
>> there needs to be 1:N.
>>
>>
>  Yep, totally on-board with 1:1 for pool and health monitor.
>
>
>> 3. Does the Pool object need a status field now that it is a pure
>> logical object?
>>
>> My opinion: I don't think it needs the status field.  I think the
>> LoadBalancer object may be the only thing that

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Kieran Spear

Hi Joe,

On 28/05/2014, at 11:21 AM, Joe Gordon  wrote:

> 
> 
> 
> On Tue, May 27, 2014 at 1:30 PM, Kieran Spear  wrote:
> 
> On 28/05/2014, at 6:11 AM, Vishvananda Ishaya  wrote:
> 
> > Phil,
> >
> > You are correct and this seems to be an error. I don’t think in the earlier 
> > ML thread[1] that anyone remembered that the quota classes were being used 
> > for default quotas. IMO we need to revert this removal as we (accidentally) 
> > removed a Havana feature with no notification to the community. I’ve 
> > reactivated a bug[2] and marked it critical.
> 
> +1.
> 
> We rely on this to set the default quotas in our cloud.
> 
> Hi Kieran,
> 
> Can you elaborate on this point. Do you actually use the full quota-class 
> functionality that allows for quota classes, if so what provides the quota 
> classes? If you only use this for setting the default quotas, why do you 
> prefer the API and not setting the config file?

We just need the defaults. My comment was more to indicate that yes, this is 
being used by people. I'm sure we could switch to using the config file, and 
generally I prefer to keep configuration in code, but finding out about this 
half way through a release cycle isn't ideal.

I notice that only the API has been removed in Icehouse, so I'm assuming the 
impact is limited to *changing* the defaults, which we don't do often. I was 
initially worried that after upgrading to Icehouse we'd be left with either no 
quotas or whatever the config file defaults are, but it looks like this isn't 
the case.

Unfortunately the API removal in Nova was followed by similar changes in 
novaclient and Horizon, so fixing Icehouse at this point is probably going to 
be difficult.

Cheers,
Kieran

>  
> 
> Kieran
> 
> >
> > Vish
> >
> > [1] 
> > http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
> > [2] https://bugs.launchpad.net/nova/+bug/1299517
> >
> > On May 27, 2014, at 12:19 PM, Day, Phil  wrote:
> >
> >> Hi Vish,
> >>
> >> I think quota classes have been removed from Nova now.
> >>
> >> Phil
> >>
> >>
> >> Sent from Samsung Mobile
> >>
> >>
> >>  Original message 
> >> From: Vishvananda Ishaya
> >> Date:27/05/2014 19:24 (GMT+00:00)
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> Subject: Re: [openstack-dev] [nova] nova default quotas
> >>
> >> Are you aware that there is already a way to do this through the cli using 
> >> quota-class-update?
> >>
> >> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html 
> >> (near the bottom)
> >>
> >> Are you suggesting that we also add the ability to use just regular 
> >> quota-update? I’m not sure i see the need for both.
> >>
> >> Vish
> >>
> >> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J 
> >>  wrote:
> >>
> >>> I would to hear your thoughts about an idea to add a way to manage the 
> >>> default quota values through the API.
> >>>
> >>> The idea is to use the current quota api, but sending ''default' instead 
> >>> of the tenant_id. This change would apply to quota-show and quota-update 
> >>> methods.
> >>>
> >>> This approach will help to simplify the implementation of another 
> >>> blueprint named per-flavor-quotas
> >>>
> >>> Feedback? Suggestions?
> >>>
> >>>
> >>> Sergio Juan Cazzolato
> >>> Intel Software Argentina
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

Hi,

Sorry somehow I missed this email. I don't think you want to disable it,
though we can definitely have it run less often. The issue with disabling
it is if one of the notifications from neutron->nova never gets sent
successfully to nova (neutron-server is restarted before the event is sent
or some other internal failure). Nova will never update it's cache if
the heal_instance_info_cache_interval is set to 0.  The neutron->nova
events help to ensure that the nova info_cache is up to date sooner by
having neutron inform nova whenever a port's data has changed (@Joe Gordon
- this happens regardless of virt driver).

If you're using the libvirt virt driver the neutron->nova events will also
be used to ensure that the networking is 'ready' before the instance is
powered on.

Best,

Aaron

P.S: we're working on making the heal_network call to neutron a lot less
expensive as well in the future.




On Tue, May 27, 2014 at 7:25 PM, Joe Gordon  wrote:

>
>
>
> On Wed, May 21, 2014 at 6:21 AM, Assaf Muller  wrote:
>
>> Dear Nova aficionados,
>>
>> Please make sure I understand this correctly:
>> Each nova compute instance selects a single VM out of all of the VMs
>> that it hosts, and every  seconds
>> queries Neutron for all of its networking information, then updates
>> Nova's DB.
>>
>> If the information above is correct, then I fail to see how that
>> is in anyway useful. For example, for a compute node hosting 20 VMs,
>> it would take 20 minutes to update the last one. Seems unacceptable
>> to me.
>>
>> Considering Icehouse's Neutron to Nova notifications, my question
>> is if we can change the default to 0 (Disable the feature), deprecate
>> it, then delete it in the K cycle. Is there a good reason not to do this?
>>
>
> Based on the patch that introduced this function [0] you may be on to
> something, but AFAIK unfortunately the neutron to nova notifications only
> work in libvirt right now [1], so I don' think we can fully deprecate this
> periodic task. That being said turning it off by default may be an option.
> Have you tried disabling this feature and seeing what happens (in the gate
> and/or in production)?
>
>
> [0] https://review.openstack.org/#/c/4269/
> [1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse
>
>
>>
>>
>> Assaf Muller, Cloud Networking Engineer
>> Red Hat
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Gerrit downtime on May 23 for project renames

2014-05-27 Thread Stefano Maffulli

On 05/23/2014 03:58 PM, James E. Blair wrote:
> This is complete.  The actual list of renamed projects is:
[...]

have any of these projects changed also their launchpad name?

thanks
.stef

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

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-27 Thread Carl Baldwin

Paul, do you have enough to be able to put up a WIP in gerrit?  This
discussion is getting to the point where having a discussion in gerrit
will be beneficial.

Carl

On Tue, May 27, 2014 at 12:37 PM, Paul Michali (pcm)  wrote:
> So I hit some more complexity, when I got to the IPSec connection resource’s
> update API…
>
> I was doing code like this:
>
> In VPN plugin:
> def create_ipsec_site_connection(self, context, ipsec_site_connection):
> driver = self._get_driver_for_ipsec_site_connection(
> context, ipsec_site_connection)
> driver.validate_create_ipsec_site_connection(context,
>  ipsec_site_connection)
> ipsec_site_connection = super(
> VPNDriverPlugin, self).create_ipsec_site_connection(
> context, ipsec_site_connection)
> driver.apply_create_ipsec_site_connection(context,
>   ipsec_site_connection)
> return ipsec_site_connection
>
>
> In ABC for service drvier:
>
> def validate_create_ipsec_site_connection(self, context,
>   ipsec_site_connection):
> ipsec_sitecon = ipsec_site_connection['ipsec_site_connection']
> dpd = ipsec_sitecon.get('dpd', {})
> ipsec_sitecon['dpd_action'] = dpd.get('action', 'hold')
> ipsec_sitecon['dpd_interval'] = dpd.get('interval', 30)
> ipsec_sitecon['dpd_timeout'] = dpd.get('timeout', 120)
> self._check_dpd(ipsec_sitecon)
> self._check_mtu(context,
> ipsec_sitecon['mtu'],
> ipsec_sitecon['vpnservice_id'])
>
>
> However, when considering the update_ipsec_site_connection() API, I realized
> that there could be multiple requests coming in to change the same
> connection’s attributes. In this case, validating and then persisting has
> the issue of incompatible changes being committed (e.g. one client changes
> DPD interval, and another client changes DPD timeout, such that they fail
> the _check_mtu() call).
>
> I’m wondering what the thoughts are, regarding how to handle this. One way,
> I guess, may be do call the service driver validation from within the
> database logic, like this:
>
> In VPN plugin
> def create_ipsec_site_connection(self, context, ipsec_site_connection):
> driver = self._get_driver_for_ipsec_site_connection(
> context, ipsec_site_connection)
> ipsec_site_connection = super(
> VPNDriverPlugin, self).create_ipsec_site_connection(
> context, ipsec_site_connection)
> driver.apply_create_ipsec_site_connection(context,
>   ipsec_site_connection)
> return ipsec_site_connection
>
> In Database (pseudo-code)
> def create_ipsec_site_connection(self, context, ipsec_site_connection):
> ipsec_sitecon = ipsec_site_connection['ipsec_site_connection']
> tenant_id = self._get_tenant_id_for_create(context, ipsec_sitecon)
> with context.session.begin(subtransactions=True):
> # I guess this would actually call the child class method to
> # get the driver?
> driver = self._get_driver_for_ipsec_site_connection(
> context, ipsec_sitecon)
> driver.validate_create_ipsec_site_connection(context,
> ipsec_sitecon)
>
>
> The database method is a base class of the VPN plugin class, so I’m
> thinking, although awkward, it could work. Can’t say I’m comfortable with
> the call flow here.  Probably could add an abstract method for
> _get_driver_for_ipsec_site_connection(), so that it cannot be called with an
> instance of the database class.
>
> I’m not seeing a really clean solution here.
>
>
> Any thoughts?
>
> PCM (Paul Michali)
>
> MAIL …..…. p...@cisco.com
> IRC ……..… pcm_ (irc.freenode.com)
> TW ………... @pmichali
> GPG Key … 4525ECC253E31A83
> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>
>
>
> On May 27, 2014, at 7:37 AM, Paul Michali (pcm)  wrote:
>
> Thanks for the comments Mandeep!  Responses in-line #PCM
>
> On May 23, 2014, at 8:57 PM, Mandeep Dhami  wrote:
>
> My preferences:
>
> For where, I'd go with Gary's recommendation (A) for two reasons (1)
> Consistency and (2) I don't think it will create any boilerplate
> requirements since the abstract class provides the default implementation.
>
>
> #PCM Actually, (A) requires a lot of additional code that doesn’t currently
> exist today. ABC methods would be needed for each validation. In addition,
> to be consistent, there should be an abstract method for the apply function,
> and a “pass” implementation on each of the concrete classes. Overall, it is
> adding a lot of code, for arguably little benefit.
>
>
>
> For naming, I'd prefer to go with ML2 terminology for two reasons (1) Again
> Consistency, and (2) it is then clear what actions are happening within a
> t

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Doug Wiegley

Hi Stephen,

> Doug:  What do you think of the idea of having both IPv4 and IPv6 attributes 
> on a 'load balancer' object? One doesn't need to have a single appliance 
> serving both types of addresses for the listener, but there's certainly a 
> chance (albeit small) to hit an async scenario if they're not.

I made the same suggestion in the bp review , so I have no issue with it.  :-)

I can think of at least one backend that pairs ip:port in their listener 
object, so the driver for that can implement the v4/v6 model natively with no 
issue (but not a true N:N).  For the ones that don’t, at least the race 
condition outlined earlier is limited to two objects, which is ok if the use 
case is common enough to warrant it.  I’d still prefer that issue be handled as 
far up the chain as possible, but I’d be ok.

Doug

From: Stephen Balukoff mailto:sbaluk...@bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, May 27, 2014 at 8:42 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object 
model refactor blueprint

Hi y'all!

On Tue, May 27, 2014 at 12:32 PM, Brandon Logan 
mailto:brandon.lo...@rackspace.com>> wrote:
Referencing this blueprint:
https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst

Anyone who has suggestions to possible issues or can answer some of
these questions please respond.

1. LoadBalancer to Listener relationship M:N vs 1:N
The main reason we went with the M:N was so IPv6 could use the same
listener as IPv4.  However this can be accomplished by the user just
creating a second listener and pool with the same configuration.  This
will end up being a bad user experience when the listener and pool
configuration starts getting complex (adding in TLS, health monitors,
SNI, etc). A good reason to not do the M:N is because the logic on might
get complex when dealing with status.  I'd like to get people's opinions
on this on whether we should do M:N or just 1:N.  Another option, is to
just implement 1:N right now and later implement the M:N in another
blueprint if it is decided that the user experience suffers greatly.

My opinion: I like the idea of leaving it to another blueprint to
implement.  However, we would need to watch out for any major
architecture changes in the time itis not implemented that could make
this more difficult than what it needs to be.

Is there such a thing as a 'possibly planned but not implemented design' to 
serve as a placeholder when considering other in-parallel blueprints and 
designs which could potentially conflict with the ability to implement an 
anticipated design like this?  (I'm guessing "no." I really wish we had a 
better design tracking tool than blueprint.)

Anyway, I don't have a problem with implementing 1:N right now. But, I do want 
to point out: The one and only common case I've seen where listener re-use 
actually makes a lot of sense (IPv4 and IPv6 for same listener) could be 
alleviated by adding separate ipv4 and ipv6 attributes to the loadbalancer 
object. I believe this was shot down when people were still calling it a VIP 
for philosophical reasons. Are people more open to this idea now that we're 
calling the object a 'load balancer'?  ;)

Does anyone have any other use cases where listener re-use makes sense?

2. Pool to Health Monitor relationship 1:N vs 1:1
Currently, I believe this is 1:N however it was suggested to deprecate
this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
objections to channging to 1:1?

My opinion: I'm for 1:1 as long as there aren't any major reasons why
there needs to be 1:N.

Yep, totally on-board with 1:1 for pool and health monitor.

3. Does the Pool object need a status field now that it is a pure
logical object?

My opinion: I don't think it needs the status field.  I think the
LoadBalancer object may be the only thing that needs a status, other
than the pool members for health monitoring.  I might be corrected on
this though.

So, I think it does make sense when using L7 rules. And it's specifically like 
this:

A pool is 'UP' if at least one non-backup member is 'UP' and 'DOWN' otherwise. 
This can be an important monitoring point if, for example, operations wants to 
be informed if the 'api pool' is down while the 'web frontend' pool is still 
up, in some meaningful way (ie. other than having to sort through a potential 
barrage of member down notifications to see wether any members of a given pool 
are still up.) Also, given that member status might be more than just 'UP' and 
'DOWN' (eg. "PROVISIONING" or "DRAINING" might also be valid status types for 
certain kinds of back-ends.) It's harder for an operator to know whether a 
given pool is 'UP' or 'DOWN' without some kind of indication.

Also note that the larger the pool,

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

On Tue, May 27, 2014 at 8:13 PM, Mike Spreitzer  wrote:

> Joe Gordon  wrote on 05/27/2014 07:31:16 PM:
>
> > From: Joe Gordon 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > ,
> > Date: 05/27/2014 07:32 PM
> > Subject: Re: [openstack-dev] [neutron] Supporting retries in
> neutronclient
> >
> >
>
> > On Tue, May 27, 2014 at 1:51 PM, Eugene Nikanorov <
> enikano...@mirantis.com
> > > wrote:
> > In fact, nova should be careful about changing number of retries for
> > neutron client.
> > It's known that under significant load (people test serial VM
> > creation) neutron client may timeout on POST operation which does
> > port creation; retrying this again leads to multiple fixed IPs
> > assigned to a VM
> >
> > This sounds like a bug in nova, nova should be able to handle
> > intermittent service timeouts without doing the wrong thing.
>
> It's just one of many bugs that are unavoidable consequences of APIs that
> do not support idempotent usage.
>

++


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

[openstack-dev] [Neutron][LBaaS] Requirements around statistics and billing

2014-05-27 Thread Stephen Balukoff

Hi folks!

We have yet to have any kind of meaningful discussion on this list around
load balancer stats (which, I presume to include data that will eventually
need to be consumed by a billing system). I'd like to get the discussion
started here, as this will have significant meaning for how we both make
this data available to users, and how we implement back-end systems to be
able to provide this data.

So!  What kinds of data are people looking for, as far as load balancer
statistics.

For our part, as an absolute minimum we need the following per loadbalancer
+ listener combination:

* Total bytes transferred in for a given period
* Total bytes transferred out for a given period

Our product and billing people I'm sure would like the following as well:

* Some kind of peak connections / second data (95th percentile or average
over a period, etc.)
* Total connections for a given period
* Total HTTP / HTTPS requests served for a given period

And the people who work on UIs and put together dashboards would like:

* Current requests / second (average for last X seconds, either on-demand,
or simply dumped regularly).
* Current In/Out bytes throughput

And our monitoring people would like this:

* Errors / second
* Current connections / second and bytes throughput secant slope (ie. like
derivative but easier to calculate from digital data) for last X seconds
(ie. detecting massive spikes or drops in traffic, potentially useful for
detecting a problem before it becomes critical)

And some of our users would like all of the above data per pool, and not
just for loadbalancer + listener. Some would also like to see it per member
(though I'm less inclined to make this part of our standard).

I'm also interested in hearing vendor capabilities here, as it doesn't make
sense to design stats that most can't implement, and I imagine vendors also
have valuable data on what their customer ask for / what stats are most
useful in troubleshooting.

What other statistics data for load balancing are meaningful and hopefully
not too arduous to calculate? What other data are your users asking for or
accustomed to seeing?

Thanks,
Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Mike Spreitzer

Joe Gordon  wrote on 05/27/2014 07:31:16 PM:

> From: Joe Gordon 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , 
> Date: 05/27/2014 07:32 PM
> Subject: Re: [openstack-dev] [neutron] Supporting retries in 
neutronclient
> 
> 

> On Tue, May 27, 2014 at 1:51 PM, Eugene Nikanorov 
 > wrote:
> In fact, nova should be careful about changing number of retries for
> neutron client.
> It's known that under significant load (people test serial VM 
> creation) neutron client may timeout on POST operation which does 
> port creation; retrying this again leads to multiple fixed IPs 
> assigned to a VM
> 
> This sounds like a bug in nova, nova should be able to handle 
> intermittent service timeouts without doing the wrong thing.

It's just one of many bugs that are unavoidable consequences of APIs that 
do not support idempotent usage.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Stephen Balukoff

Hi y'all!

On Tue, May 27, 2014 at 12:32 PM, Brandon Logan  wrote:

> Referencing this blueprint:
>
> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>
> Anyone who has suggestions to possible issues or can answer some of
> these questions please respond.
>
>
> 1. LoadBalancer to Listener relationship M:N vs 1:N
> The main reason we went with the M:N was so IPv6 could use the same
> listener as IPv4.  However this can be accomplished by the user just
> creating a second listener and pool with the same configuration.  This
> will end up being a bad user experience when the listener and pool
> configuration starts getting complex (adding in TLS, health monitors,
> SNI, etc). A good reason to not do the M:N is because the logic on might
> get complex when dealing with status.  I'd like to get people's opinions
> on this on whether we should do M:N or just 1:N.  Another option, is to
> just implement 1:N right now and later implement the M:N in another
> blueprint if it is decided that the user experience suffers greatly.
>
> My opinion: I like the idea of leaving it to another blueprint to
> implement.  However, we would need to watch out for any major
> architecture changes in the time itis not implemented that could make
> this more difficult than what it needs to be.
>

Is there such a thing as a 'possibly planned but not implemented design' to
serve as a placeholder when considering other in-parallel blueprints and
designs which could potentially conflict with the ability to implement an
anticipated design like this?  (I'm guessing "no." I really wish we had a
better design tracking tool than blueprint.)

Anyway, I don't have a problem with implementing 1:N right now. But, I do
want to point out: The one and only common case I've seen where listener
re-use actually makes a lot of sense (IPv4 and IPv6 for same listener)
could be alleviated by adding separate ipv4 and ipv6 attributes to the
loadbalancer object. I believe this was shot down when people were still
calling it a VIP for philosophical reasons. Are people more open to this
idea now that we're calling the object a 'load balancer'?  ;)

Does anyone have any other use cases where listener re-use makes sense?

>
> 2. Pool to Health Monitor relationship 1:N vs 1:1
> Currently, I believe this is 1:N however it was suggested to deprecate
> this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
> objections to channging to 1:1?
>
> My opinion: I'm for 1:1 as long as there aren't any major reasons why
> there needs to be 1:N.
>
>
Yep, totally on-board with 1:1 for pool and health monitor.

> 3. Does the Pool object need a status field now that it is a pure
> logical object?
>
> My opinion: I don't think it needs the status field.  I think the
> LoadBalancer object may be the only thing that needs a status, other
> than the pool members for health monitoring.  I might be corrected on
> this though.
>

So, I think it does make sense when using L7 rules. And it's specifically
like this:

A pool is 'UP' if at least one non-backup member is 'UP' and 'DOWN'
otherwise. This can be an important monitoring point if, for example,
operations wants to be informed if the 'api pool' is down while the 'web
frontend' pool is still up, in some meaningful way (ie. other than having
to sort through a potential barrage of member down notifications to see
wether any members of a given pool are still up.) Also, given that member
status might be more than just 'UP' and 'DOWN' (eg. "PROVISIONING" or
"DRAINING" might also be valid status types for certain kinds of
back-ends.) It's harder for an operator to know whether a given pool is
'UP' or 'DOWN' without some kind of indication.

Also note that the larger the pool, the less meaningful individual members'
statuses are: If you've got 1000 servers in a pool, it's probably OK if 3-4
of them are 'down' at any given time.

Having said this, if someone asks for the status of a pool, I'd be OK if
the response was simply an array of statuses of each member in the pool,
plus one 'summary' status (ie. as described above) and it's left to the
user to do with that data whatever makes sense for their application. This
would allow one to see, for example, that a pool with no members is by
definition 'DOWN'.

Are we going to allow a pool to be set administratively down? (ex. for
maintenance on one pool of servers powering a listener, while other pools
remain online and available.) In this case, having a response that says the
pool is 'ADMIN_DOWN' probably also makes sense.

Doug:  What do you think of the idea of having both IPv4 and IPv6
attributes on a 'load balancer' object? One doesn't need to have a single
appliance serving both types of addresses for the listener, but there's
certainly a chance (albeit small) to hit an async scenario if they're not.

Vijay:  I think the plan here was to come up with an use an entirely
different DB schema than the legacy Neutron LBaaS, and then retro

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

Hi,

Is it possible to detect when the ssl handshaking error occurs on the
client side (and only retry for that)? If so I think we should do that
rather than retrying multiple times. The danger here is mostly for POST
operations (as Eugene pointed out) where it's possible for the response to
not make it back to the client and for the operation to actually succeed.

Having this retry logic nested in the client also prevents things like nova
from handling these types of failures individually since this retry logic
is happening inside of the client. I think it would be better not to have
this internal mechanism in the client and instead make the user of the
client implement retry so they are aware of failures.

Aaron

On Tue, May 27, 2014 at 10:48 AM, Paul Ward  wrote:

> Currently, neutronclient is hardcoded to only try a request once in
> retry_request by virtue of the fact that it uses self.retries as the retry
> count, and that's initialized to 0 and never changed.  We've seen an issue
> where we get an ssl handshaking error intermittently (seems like more of an
> ssl bug) and a retry would probably have worked.  Yet, since neutronclient
> only tries once and gives up, it fails the entire operation.  Here is the
> code in question:
>
>
> https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L1296
>
> Does anybody know if there's some explicit reason we don't currently allow
> configuring the number of retries?  If not, I'm inclined to propose a
> change for just that.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Neutron] heal_instance_info_cache_interval - Can we kill it?

On Wed, May 21, 2014 at 6:21 AM, Assaf Muller  wrote:

> Dear Nova aficionados,
>
> Please make sure I understand this correctly:
> Each nova compute instance selects a single VM out of all of the VMs
> that it hosts, and every  seconds
> queries Neutron for all of its networking information, then updates
> Nova's DB.
>
> If the information above is correct, then I fail to see how that
> is in anyway useful. For example, for a compute node hosting 20 VMs,
> it would take 20 minutes to update the last one. Seems unacceptable
> to me.
>
> Considering Icehouse's Neutron to Nova notifications, my question
> is if we can change the default to 0 (Disable the feature), deprecate
> it, then delete it in the K cycle. Is there a good reason not to do this?
>

Based on the patch that introduced this function [0] you may be on to
something, but AFAIK unfortunately the neutron to nova notifications only
work in libvirt right now [1], so I don' think we can fully deprecate this
periodic task. That being said turning it off by default may be an option.
Have you tried disabling this feature and seeing what happens (in the gate
and/or in production)?


[0] https://review.openstack.org/#/c/4269/
[1] https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse


>
>
> Assaf Muller, Cloud Networking Engineer
> Red Hat
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS]TLS API support for authentication

2014-05-27 Thread Stephen Balukoff

Hi y'all!

On Fri, May 23, 2014 at 1:24 PM, Carlos Garza wrote:

> Right so are you advocating that the front end API never return a
> private key back to the user once regardless if the key was generated
> on the back end or sent in to the API from the user? We kind of are
> already are implying that they can refer to the key via a private
> key id.
>

I would advocate that if the user asks the front-end API for the private
key information (ie. "GET" request), what they get back is the key's
modulus and nothing else. This should work to verify whether a given key
matches a given cert, and doesn't break security requirements for those who
are never allowed to actually touch private key data. And if a user added
the key themselves through the front-end API, I think it's safe to assume
the responsibility for keeping a copy of the key they can access lies with
the user.

Having said this, of course anything which spins up virtual appliances, or
configures physical appliances is going to need access to the actual
private key. So any back-end API(s) will probably need to have different
behavior here.

One thing I do want to point out is that with the 'transient' nature of
back-end guests / virtual servers, it's probably going to be important to
store the private key data in something non-volatile, like barbican's
store. While it may be a good idea to add a feature that generates a
private key and certificate signing request via our API someday for certain
organizations' security requirements, one should never have the only store
for this private key be a single virtual server. This is also going to be
important if a certificate + key combination gets re-used in another
listener in some way, or when horizontal scaling features get added.

Thanks,
Stephen

-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [solum] [mistral] [heat] keystone chained trusts / oauth

2014-05-27 Thread Steve Martinelli

Hey Angus,

If I understand the scenario correctly,
I think you might run into the same problem with OAuth Access Tokens.

>> We currently use a trust token and that fails
because both mistral and
>> heat want to create trust tokens as well :-O (trust tokens can't
be
>> rescoped).

i.e.: Use OAuth Access Token (oa) to
get a Keystone token (kt), then use that Keystone token (kt) to get another
Keystone token? (scoped or not, the request will be denied to prevent chaining)

>> I believe there might be some limitations
to oauth (are roles supported?).

You may specify any number of roles
to be delegated in an OAuth Access Token, the only limitation I can think
of, is that only projects are supported, not domains.


Regards,

Steve Martinelli
Software Developer - Openstack
Keystone Core Member





Phone:
1-905-413-2851
E-mail: steve...@ca.ibm.com

8200 Warden Ave
Markham, ON L6G 1C7
Canada




From:      
 Angus Salkeld 
To:      
 "OpenStack Development
Mailing List (not for usage questions)" ,

Date:      
 05/27/2014 08:58 PM
Subject:    
   [openstack-dev]
[solum] [mistral] [heat] keystone chained trusts /      
 oauth




-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all

During our Solum meeting it was felt we should make sure that all three
team are on the same page wrt $subject.

I'll describe the use case we are trying to solve and hopefully get some
guidance from the keystone team about the best way forward.

Solum implements a ci/cd pipeline that we want to trigger based on a git
receive hook. What we do is generate a magic webhook (should be
ec2signed url - on the todo list) and when it is hit we want
to call mistral-execution-create (which runs a workflow that calls
to other openstack services (heat is one of them).

We currently use a trust token and that fails because both mistral and
heat want to create trust tokens as well :-O (trust tokens can't be
rescoped).

So what is the best mechanism for this? I spoke to Steven Hardy at
summit and he suggested (after talking to some keystone folks) we all
move to using the new oauth functionality in keystone.

I believe there might be some limitations to oauth (are roles supported?).

Basically I want to make sure we are doing the right (and compatible)
thing so autonomous actions can be carried out across services.

Regards
Angus

refs:
https://blueprints.launchpad.net/mistral/+spec/mistral-oauth
https://blueprints.launchpad.net/solum/+spec/solum-oauth
https://blueprints.launchpad.net/heat/+spec/heat-oauth

other interesting stuff:
http://adam.younglogic.com/2013/03/trusts-and-oauth/
http://homakov.blogspot.com.au/2013/03/oauth1-oauth2-oauth.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThTRTAAoJEFrDYBLxZjWoQgYH/2/TyJH2INIFojxu6lwntbHh
6IhVmcXIybY+F/RN++YTBLduqA7qVxsGY2ZrGkztK3wISquI9Hw97Lw6jHelfK3J
3FnuS68xdxfhFwRNB8Slp5FT8ssHYazqpKn6kB5Rz7icZe6kWBTDGD8LTyiPwmJs
fWotAu/uzQJD0qcvg1XOE6Yddxm7owf85wY4BSSURzjBakK9ANwT1rW+pBoVFWF3
sxxIOCnDXmCJsiN18x3hHAXXxIxiLwlBp/YIuIUSznDK3a8JiIoaQ3jjM/FvcvX4
P7zQZL2qEoV4PXnvW5NmMaguOc/teTcw7ga3txry0RDHAYfDWmetKCuUjJtAKYQ=
=XaIS
-END PGP SIGNATURE-

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





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

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

I believe this patch should fix the issue, It seems to for me:
https://review.openstack.org/#/c/95938/ (It's in the process of merging
into icehouse and havana now). Thanks for the report.



arosen@arosen-MacBookPro:~/devstack$ neutron net-list
+--+-++
| id   | name| subnets
   |
+--+-++
| 18b00633-2a32-494d-88cf-41c19211597d | private |
556f3c44-01bb-468a-8064-10c833eb3715 10.0.0.0/24   |
|  | |
e8180cc2-e5ea-4892-997e-e9ff96b426f4 2008:129:2bf:cd1::/64 |
| b9869a8e-cc7b-409f-99c9-ae1a2a4a4855 | public  |
9b9f49b2-0297-4528-92d3-b2ca7abd5be4   |
+--+-++
arosen@arosen-MacBookPro:~/devstack$ neutron router-list
+--+-+-+
| id   | name| external_gateway_info
|
+--+-+-+
| 96d4a3cb-4138-41af-b88e-8ebe5405f2bb | router1 | {"network_id":
"b9869a8e-cc7b-409f-99c9-ae1a2a4a4855", "enable_snat": true} |
+--+-+-+
arosen@arosen-MacBookPro:~/devstack$ neutron router-interface-delete
router1 556f3c44-01bb-468a-8064-10c833eb3715
Removed interface from router router1.
arosen@arosen-MacBookPro:~/devstack$ neutron router-interface-delete
router1 e8180cc2-e5ea-4892-997e-e9ff96b426f4
Removed interface from router router1.
arosen@arosen-MacBookPro:~/devstack$ neutron net-delete private
Deleted network: private



On Tue, May 27, 2014 at 3:57 PM, Martinx - ジェームズ
wrote:

> Hi Aaron!
>
> The BUG report https://bugs.launchpad.net/neutron/+bug/1322945 is about
> this problem, I posted there the instructions to reproduce it...
>
> Basically, after attaching a private IPv6 subnet to your L3 Router, it
> will break the "External Network" and its "Floating IPs", then, it becomes
> impossible to delete that "External Network"... It enters in a "stuck"
> state...
>
> Regards,
> Thiago
>
>
> On 27 May 2014 18:34, Aaron Rosen  wrote:
>
>> Hi,
>>
>> can you open a bug report on this and provide your setup configuration? I
>> just tested this with ML2 and wasn't able to reproduce the issue.
>>
>> arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
>>  --provider:network_type vlan  --provider:segmentation_id 124
>> --provider:physical_network  asdf
>> Unable to create the network. The VLAN 124 on physical network asdf is in
>> use.
>>
>> arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
>> Deleted network: asdf
>>
>> Thanks,
>>
>> Aaron
>>
>>
>> On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ <
>> thiagocmarti...@gmail.com> wrote:
>>
>>> Guys,
>>>
>>> I'm trying to delete a network in Neutron but it is failing, from
>>> Horizon it triggers the error message above (subject), and from CLI, it
>>> shows this:
>>>
>>> ---
>>> root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
>>> Request Failed: internal server error while processing your request.
>>> ---
>>>
>>> The logs shows:
>>>
>>> ---
>>> ==> /var/log/neutron/server.log <==
>>> 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
>>> ('2804:290:4:dead::10', 56908, 0, 0)
>>>
>>> 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting
>>> new HTTP connection (1): psuaa-1.mng.tcmc.com.br
>>> 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
>>> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
>>> [21/May/2014 11:49:54] "GET
>>> /v2.0/networks.json?fields=id&id=a1654832-8aac-42d5-8837-6d27b7421892
>>> HTTP/1.1" 200 251 0.089015
>>>
>>> 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
>>> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
>>> ('2804:290:4:dead::10', 56910, 0, 0)
>>>
>>> 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
>>> [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
>>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback
>>> (most recent call last):
>>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>>> "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 87, in
>>> resource
>>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
>>> method(request=request, **args)
>>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>>> "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line

Re: [openstack-dev] [nova] nova default quotas

On Tue, May 27, 2014 at 1:11 PM, Vishvananda Ishaya
wrote:

> Phil,
>
> You are correct and this seems to be an error. I don’t think in the
> earlier ML thread[1] that anyone remembered that the quota classes were
> being used for default quotas. IMO we need to revert this removal as we
> (accidentally) removed a Havana feature with no notification to the
> community. I’ve reactivated a bug[2] and marked it critcal.
>

While I agree that we shouldn't have removed support for a working feature
like updating the default quota via the REST API. I don't think we should
just do a revert.

The good news is we haven't dropped any tables yet, so a revert won't
require any migrations.

* quota-classes never worked for anything except changing default quotas,
and this feature adds a whole bunch of DB calls to every quota lookup (a
big overhead for a mostly broken feature). I am not a huge fan of bringing
back a feature that is known to be mostly broken. I am also not a fan of
breaking working features, which we did. Perhaps the right answer is to
bring back just the default value override support.
* But having a rest API to override config file options sounds like a step
in the wrong direction. I can see this easily leading to confusion about
where the default quota values are coming from. This is part of a larger
issue: folks want to update config options without restarting any services,
as far as I know there is no reason why we cannot support this with minimal
changes in a way that we can use this for other config options.

>
> Vish
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
> [2] https://bugs.launchpad.net/nova/+bug/1299517
>
> On May 27, 2014, at 12:19 PM, Day, Phil  wrote:
>
> > Hi Vish,
> >
> > I think quota classes have been removed from Nova now.
> >
> > Phil
> >
> >
> > Sent from Samsung Mobile
> >
> >
> >  Original message 
> > From: Vishvananda Ishaya
> > Date:27/05/2014 19:24 (GMT+00:00)
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > Subject: Re: [openstack-dev] [nova] nova default quotas
> >
> > Are you aware that there is already a way to do this through the cli
> using quota-class-update?
> >
> > http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html(near 
> > the bottom)
> >
> > Are you suggesting that we also add the ability to use just regular
> quota-update? I’m not sure i see the need for both.
> >
> > Vish
> >
> > On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J <
> sergio.j.cazzol...@intel.com> wrote:
> >
> >> I would to hear your thoughts about an idea to add a way to manage the
> default quota values through the API.
> >>
> >> The idea is to use the current quota api, but sending ''default'
> instead of the tenant_id. This change would apply to quota-show and
> quota-update methods.
> >>
> >> This approach will help to simplify the implementation of another
> blueprint named per-flavor-quotas
> >>
> >> Feedback? Suggestions?
> >>
> >>
> >> Sergio Juan Cazzolato
> >> Intel Software Argentina
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova default quotas

On Tue, May 27, 2014 at 1:30 PM, Kieran Spear  wrote:

>
> On 28/05/2014, at 6:11 AM, Vishvananda Ishaya 
> wrote:
>
> > Phil,
> >
> > You are correct and this seems to be an error. I don’t think in the
> earlier ML thread[1] that anyone remembered that the quota classes were
> being used for default quotas. IMO we need to revert this removal as we
> (accidentally) removed a Havana feature with no notification to the
> community. I’ve reactivated a bug[2] and marked it critical.
>
> +1.
>
> We rely on this to set the default quotas in our cloud.
>

Hi Kieran,

Can you elaborate on this point. Do you actually use the full quota-class
functionality that allows for quota classes, if so what provides the quota
classes? If you only use this for setting the default quotas, why do you
prefer the API and not setting the config file?


>
> Kieran
>
> >
> > Vish
> >
> > [1]
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
> > [2] https://bugs.launchpad.net/nova/+bug/1299517
> >
> > On May 27, 2014, at 12:19 PM, Day, Phil  wrote:
> >
> >> Hi Vish,
> >>
> >> I think quota classes have been removed from Nova now.
> >>
> >> Phil
> >>
> >>
> >> Sent from Samsung Mobile
> >>
> >>
> >>  Original message 
> >> From: Vishvananda Ishaya
> >> Date:27/05/2014 19:24 (GMT+00:00)
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> Subject: Re: [openstack-dev] [nova] nova default quotas
> >>
> >> Are you aware that there is already a way to do this through the cli
> using quota-class-update?
> >>
> >> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html(near
> >>  the bottom)
> >>
> >> Are you suggesting that we also add the ability to use just regular
> quota-update? I’m not sure i see the need for both.
> >>
> >> Vish
> >>
> >> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J <
> sergio.j.cazzol...@intel.com> wrote:
> >>
> >>> I would to hear your thoughts about an idea to add a way to manage the
> default quota values through the API.
> >>>
> >>> The idea is to use the current quota api, but sending ''default'
> instead of the tenant_id. This change would apply to quota-show and
> quota-update methods.
> >>>
> >>> This approach will help to simplify the implementation of another
> blueprint named per-flavor-quotas
> >>>
> >>> Feedback? Suggestions?
> >>>
> >>>
> >>> Sergio Juan Cazzolato
> >>> Intel Software Argentina
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Xen and Libvirt.

2014-05-27 Thread Tian, Shuangtai

Hi，
   Does anyone use the latest libvirt + xen +openstack ? In my ubuntu 
environment, It can not create VM , Because the blktap2 does not work.

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Tuesday, May 27, 2014 5:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Xen and Libvirt.

On Mon, May 26, 2014 at 09:45:07AM -0400, Alvin Starr wrote:
> 
> What is the status of Xen and libvirt under Openstack?
> I noticed bits of discussions about deprecating the interface but I 
> did not see any clear answers.

There is *no* intention to deprecated it. It was merely marked as being in Tier 
3 support state, primarily due to lack of any automated testing.
The lack of CI testing is being addressed, hopefully to be up & running before 
end of Juno.

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

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

Re: [openstack-dev] [Openstack-docs] [Heat][Documentation] Heat template documentation

2014-05-27 Thread Steve Baker

On 28/05/14 03:15, Gauvain Pocentek wrote:
> Le 2014-05-23 15:57, Anne Gentle a écrit :
>> On Fri, May 23, 2014 at 8:42 AM, Steven Hardy  wrote:
>>
>>> On Fri, May 23, 2014 at 08:09:06AM -0500, Anne Gentle wrote:
 On Fri, May 23, 2014 at 6:19 AM, Steven Hardy 
 wrote:

> On Fri, May 23, 2014 at 12:38:40PM +0200, Andreas Jaeger wrote:
>> On 05/23/2014 12:13 PM, Steven Hardy wrote:
>>> [...]
>>> I'll hold my hand up as one developer who tried to contribute
>>> but ran
> away
>>> screaming due to all the XML-java-ness of the current process.
>>> I don't think markup complexity is a major barrier to contribution.
> Needing
>>> to use a closed source editor and download unfathomably huge
>>> amounts of
>>> java to build locally definitely are though IMO/IME.
>> You do not need a closed sourced editor for XML - I'm using emacs
>> and
>> others in the team use vi for it.
> Sure, maybe "need" was the wrong word to use, my apologies.
>  Regardless,
> the docs refer to a closed source tool being "encouraged", which
> immediately discouraged me when trying to figure out the workflow.
> I've tried editing XML in vim a few times, and although it's
> obviously
> possible, it's far less painful when I'm dealing with other more
> human-friendly formats.
>
>> Yes, it downloads a lot Java once. We also now build the
>> documents as
>> part of the gate, so you can also check changes by clicking the
>> "checkbuild" target, it will show you the converted books,
> Sure, that's good, but my (and I'd guess many others) preference
> is for
> formats which can be easily built locally with only
> distro-provided tools,
> not a huge pile of third party java.
> Not trying to start a format-advocacy argument here, just trying
> to provide
> a data-point that, if the success criteria is developer
> participation in
> the docs process, then the current toolchain is definitely a
> barrier to
> participation for some potential contributors.
>

 Thanks for the discussions -- let's keep a tone of civility.
 Understand
 that doc writers have specific tools that work well for them. That
 said, we
 do want to collaborate more with our end users specifically.
>>> My apologies if my remarks have been interpreted as uncivil, that was
>>> definitely not my intention.
>> Oh no not at all, sorry -- my intent is that we are all staying civil
>> and it's good. :)
>>  
>>
>>> The only point I really wanted to convey was +1 on trying out an easier
>>> markup, and thanks for bringing up the topic of a user orientated
>>> orchestration guide - I would definitely like to contribute to the
>>> effort.
>> So we're still a little stuck on the tradeoffs -- with easier markup
>> we lose some features. 
>> For other generated reference docs, we maintain a set of python
>> scripts in openstack-doc-tools. Is it possible for someone to look
>> into generating the Heat template reference information outside of
>> Sphinx?
>
> Yes, I can look into that.
>
> The idea would be to generate some docbook from RST... So why not do
> it for the whole to-be-written heat user guide in that case?
>
> What I get from this thread is that 1) docbook is the best format to
> use to generate a nice and feature-rich output, 2) developers don't
> want to write docbook. Without being able to handle a different format
> developers will no contribute, which is bad because they want, and we
> want them to contribute :)
>
> So my feeling is that we should work on the tools to convert RST (or
> whatever format, but RST seems to be the "norm" for openstack
> projects) to docbook, and generate our online documentation from
> there. There are tools that can help us doing that, and I don't see an
> other solution that would make us move forward.
>
> Anne, you talked about experimenting with the end user guide, and
> after the discussion and the technical info brought by Doug, Steve and
> Steven, I now think it is worth trying.
>
In this vein, I enabled the sphinx xml builder in heat:
https://review.openstack.org/#/c/95979/

And here is a sample of the output:
http://paste.openstack.org/show/81811/
http://paste.openstack.org/show/81812/

This looks like it could be readily transformed into DocBook via XSL.

Alternatively we could write a Docutils writer which writes docbook
directly, possibly using this as a starting point:
http://docutils.sourceforge.net/sandbox/oliverr/docbook/

Any takers to start playing with this?

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

[openstack-dev] [solum] [mistral] [heat] keystone chained trusts / oauth

2014-05-27 Thread Angus Salkeld

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all

During our Solum meeting it was felt we should make sure that all three
team are on the same page wrt $subject.

I'll describe the use case we are trying to solve and hopefully get some
guidance from the keystone team about the best way forward.

Solum implements a ci/cd pipeline that we want to trigger based on a git
receive hook. What we do is generate a magic webhook (should be
ec2signed url - on the todo list) and when it is hit we want
to call mistral-execution-create (which runs a workflow that calls
to other openstack services (heat is one of them).

We currently use a trust token and that fails because both mistral and
heat want to create trust tokens as well :-O (trust tokens can't be
rescoped).

So what is the best mechanism for this? I spoke to Steven Hardy at
summit and he suggested (after talking to some keystone folks) we all
move to using the new oauth functionality in keystone.

I believe there might be some limitations to oauth (are roles supported?).

Basically I want to make sure we are doing the right (and compatible)
thing so autonomous actions can be carried out across services.

Regards
Angus

refs:
https://blueprints.launchpad.net/mistral/+spec/mistral-oauth
https://blueprints.launchpad.net/solum/+spec/solum-oauth
https://blueprints.launchpad.net/heat/+spec/heat-oauth

other interesting stuff:
http://adam.younglogic.com/2013/03/trusts-and-oauth/
http://homakov.blogspot.com.au/2013/03/oauth1-oauth2-oauth.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJThTRTAAoJEFrDYBLxZjWoQgYH/2/TyJH2INIFojxu6lwntbHh
6IhVmcXIybY+F/RN++YTBLduqA7qVxsGY2ZrGkztK3wISquI9Hw97Lw6jHelfK3J
3FnuS68xdxfhFwRNB8Slp5FT8ssHYazqpKn6kB5Rz7icZe6kWBTDGD8LTyiPwmJs
fWotAu/uzQJD0qcvg1XOE6Yddxm7owf85wY4BSSURzjBakK9ANwT1rW+pBoVFWF3
sxxIOCnDXmCJsiN18x3hHAXXxIxiLwlBp/YIuIUSznDK3a8JiIoaQ3jjM/FvcvX4
P7zQZL2qEoV4PXnvW5NmMaguOc/teTcw7ga3txry0RDHAYfDWmetKCuUjJtAKYQ=
=XaIS
-END PGP SIGNATURE-

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

Re: [openstack-dev] Gate and Skipped Tests

On Fri, May 23, 2014 at 11:11 AM, Ben Nemec  wrote:

> On 05/22/2014 06:31 PM, Johannes Erdfelt wrote:
> > I noticed recently that some tests are being skipped in the Nova gate.
> >
> > Some will always be skipped, but others are conditional.
> >
> > In particular the ZooKeeper driver tests are being skipped because an
> > underlying python module is missing.
> >
> > It seems to me that we should want no tests to be conditionally skipped
> > in the gate. This could lead to fragile behavior where an underlying
> > environmental problem could cause tests to be erroneously skipped and
> > broken code could get merged.
> >
> > Any opinions on this?
>
> This is not a hypothetical problem either - we've run into this exact
> scenario with Qpid in the past.  The Qpid tests were conditional on
> python-qpid being installed, and since it wasn't listed in
> test-requirements those tests never got run and broken code found its
> way in.  I believe that's been fixed everywhere now, but it demonstrates
> that this is a legitimate problem.
>
> I'm not sure whether "no skips at all" is going to be doable, but I
> definitely agree that conditional tests should be avoided whenever
> possible.
>

Ben,

This sounds very similar to the dependency directory idea [0].  Another
option  is to add a unit test job that swaps requirements.txt with the
global-requirements [1] (perhaps in an intelligent way so we don't change
the versions of libraries that are already in requirements). I put up a
quick test of this to see what happens [2]


[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026976.html
[1]
http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt
[2] https://review.openstack.org/95981


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

Re: [openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

2014-05-27 Thread Shixiong Shang

I am reading the meeting minute, and saw the discussion on this BP submitted by 
xuhanp:

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

I don’t see any reason why we need it….do you?

Shixiong



On May 27, 2014, at 12:47 PM, Collins, Sean  
wrote:

> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html
> 
> -- 
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Designate Incubation Request

On Sat, May 24, 2014 at 10:24 AM, Hayes, Graham  wrote:

>
> Hi all,
>
> Designate would like to apply for incubation status in OpenStack.


> Our application is here:
> https://wiki.openstack.org/wiki/Designate/Incubation_Application


Based on
http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements.rstI
have a few questions:

* You mention nova's dns capabilities as not being adequate one of the
incubation requirements is:

  Project should not inadvertently duplicate functionality present in other
  OpenStack projects. If they do, they should have a clear plan and timeframe
  to prevent long-term scope duplication


So what is the plan for this?

* Can you expand on why this doesn't make sense in neutron when things
like LBaaS do.

* Your application doesn't cover all the items raised in the incubation
requirements list. For example the QA requirement of

 Project must have a basic devstack-gate job set up


  which as far as I can tell isn't really there, although there
appears to be a devstack based job run as third party which in at
least once case didn't run on a merged patch
(https://review.openstack.org/#/c/91115/)



>
> As part of our application we would like to apply for a new program. Our
> application for the program is here:
>
> https://wiki.openstack.org/wiki/Designate/Program_Application
>
> Designate is a DNS as a Service project, providing both end users,
> developers, and administrators with an easy to use REST API to manage
> their DNS Zones and Records.
>
> Thanks,
>
> Graham
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Ironic] [Infra] Making Ironic vote as a third-party Nova driver

On Fri, May 23, 2014 at 7:38 PM, Devananda van der Veen <
devananda@gmail.com> wrote:

> Hi all!
>
> This is a follow-up to several summit discussions on
> how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
> raise awareness of the project's status, and hopefully gain some interest
> from folks on nova-core to help with spec and code reviews.
>
> The nova.virt.ironic driver lives in Ironic's git tree today [1]. We're
> cleaning it up and submitting it to Nova again this cycle. I've posted
> specs [2] outlining the design and planned upgrade process. Earlier today,
> we enabled voting in Ironic's check and gate queues for the
> tempest-dsvm-virtual-ironic job. This runs a tempest scenario test [3]
> against devstack, exercising Nova with the Ironic driver to PXE boot a
> virtual machine. It has been running for a few months on Ironic, and has
> been stable for more than a month. However, because Ironic is not
> integrated, we also can't vote in check/gate queues on integrated projects
> (like Nova). We can - and do - report the test result in a non-voting way,
> though that's easy to miss, since it looks like every other non-voting test.
>
> At the summit [4], it was suggested that we make this job report as though
> it were a third-party CI test for a Nova driver. This would be removed at
> the time that Ironic graduates and the job is allowed to vote in the gate.
> Until that time, I'm happy to have the nova.virt.ironic driver reporting as
> a third-party driver (even though it's not) simply to help raise awareness
> (third-party CI jobs are watched more closely than non-voting jobs) and
> decrease the likelihood that Nova developers will inadvertently break
> Ironic's gate.
>
> Given that there's a concrete plan forward, why am I sending this email to
> all three teams? A few reasons:
> - document the plan that we discussed
> - many people from infra and nova were not present during the discussion
> and may not be aware of the details
> - I may have gotten something wrong (it was a long week)
> - and mostly because I don't technically know how to make an upstream job
> report as though it's a third-party job, and am hoping someone wants to
> volunteer to help figure that out
>
>
Sounds like a great plan to me - this should help raise awareness in nova,
although I cannot speak to what is needed to make ironic vote the same way
a third party CI system does.



> Regards,
> Devananda
>
>
> 1: https://github.com/openstack/ironic/tree/master/ironic/nova/virt/ironic
>
> 2: https://review.openstack.org/95024 and
> https://review.openstack.org/95025
>
> 3:
> https://github.com/openstack/tempest/blob/master/tempest/scenario/test_baremetal_basic_ops.py
>
> 4: https://etherpad.openstack.org/p/juno-nova-deprecating-baremetal
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Policy for linking bug or bp in commit message

On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno  wrote:

> Hi Ben, Joe
>
> Thank you for your reply
>
> (2) Avoid duplication of works
> I have several experience of this.  Anyway, we should encourage people
> to check listed bug before
> writing patches.
>

That's a very good point, but I don't think requiring a bug/bp for every
patch is a good way to address this. Perhaps there is another way.


>
> (3) Release management
> -> TTX is doing this after each release. so we can know how many bugs we
> fixed.
> (or we can know how many bugs remaining in this release)


> (4) sync code from oslo-incubator
> IMO, this kind of 'sync' commit don't need to filing bug such as
> Transmaniax, requirement update etc.
>

This is why a strict rule won't work IMHO.


>
>
>
>
>
> 2014-05-23 12:16 GMT-07:00 Joe Gordon :
> >
> >
> >
> > On Sat, May 24, 2014 at 4:02 AM, Joe Gordon 
> wrote:
> >>
> >>
> >>
> >>
> >> On Sat, May 24, 2014 at 2:23 AM, Nachi Ueno  wrote:
> >>>
> >>> Hi folks
> >>>
> >>> I believed we should link bug or bp for any commit except automated
> >>> commit by infra.
> >>> However, I found also there is no written policy for this.
> >>> so may be, I'm wrong for here.
> >>>
> >>> The reason, we need bug or bp linked , is
> >>>
> >>> (1) Triage for core reviewing
> >>>
> >>> (2) Avoid duplication of works
> >>
> >>
> >> I'm not sure how this will help. folks will just file duplicate bugs
> write
> >> before the push there patch for review.
> >>
> >>>
> >>> (3) Release management
> >>
> >>
> >> Can you give some examples to show why requiring a bug or bp helps with
> >> the items listed above.
> >>
> >>>
> >>>
> >>> IMO, generally, the answer is yes.
> >>>
> >>> However, how about small 5-6 nit change?
> >>> so such patch will be exception or not?
> >>>
> >>> I wanna ask community opinion, and I'll update gerrit workflow page
> based
> >>> on
> >>> this discussion.
> >>
> >>
> >> I don't trying to enforce this policy alone will help. For a patch that
> >> doesn't have a bug or blueprint assocatiated we have two options.
> >>
> >> * File a blueprint. Now that many projects use specs repos blueprints
> have
> >> a significant overhead associated with them, so we should be careful
> about
> >> incurring that overhead.
> >> * File a bug. Sure we can file a bug for every patch, but there is still
> >> an overhead associated with that, and in most cases I don't think it
> really
> >> buys us much. If the change isn't a real bug but say 'sync code from
> >> oslo-incubator' what does adding a linked bug really buy us?
> >>
> >
> >
> > Wow, that came out garbled, I guess that is what a long flight does.
> Here is
> > take two:
> >
> > I don't think this policy of requiring a linked blueprint or bug for
> every
> > patch is enough to significantly help with the list of items listed
> above.
> >
> > Now that many projects use specs repositories, we have just ratcheted up
> the
> > overhead associated with using blueprints. While this is a good thing
> > overall, this also means we should be careful about making process
> changes
> > that require folks to file more blueprints.
> > As for bugs, it is unclear to me what the value of filing a bug for a
> patch
> > that 'synces code from oslo-incubator' is. How would this help with
> review
> > triage, especially when we don't do a great job of bug triage?
> >
> >
> >
> >
> >
> >
> >>>
> >>>
> >>> Best
> >>> Nachi
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Vijay B

Hi Brandon,

The current reviews of the schema itself are absolutely valid and
necessary, and must go on. However, the place of implementation of this
schema needs to be clarified. Rather than make any changes whatsoever to
the existing neutron db schema for LBaaS, this new db schema outlined needs
to be implemented for a separate LBaaS core service.

What we should be providing in neutron is a switch (a global conf) that can
be set to instruct neutron to do one of two things:

1. Use the existing neutron LBaaS API, with the backend being the existing
neutron LBaaS db schema. This is the status quo.
2. Use the existing neutron LBaaS API, with the backend being the new LBaaS
service. This will invoke calls not to neutron's current LBaaS code at all,
rather, it will call into a new set of proxy "backend" code in neutron that
will translate the older LBaaS API calls into the newer REST calls serviced
by the new LBaaS service, which will write down these details accordingly
in its new db schema. As long as the request and response objects to legacy
neutron LBaaS calls are preserved as is, there should be no issues. Writing
unit tests should also be comparatively more straightforward, and old
functional tests can be retained, and newer ones will not clash with legacy
code. Legacy code itself will work, having not been touched at all. The
blueprint for the db schema that you have referenced (
https://review.openstack.org/#/c/89903/5/specs/juno/lbaas
-api-and-objmodel-improvement.rst) should be implemented for this new LBaaS
service, post reviews.

The third option would be to turn off neutron LBaaS API, and use the new
LBaaS core service directly, but for this we can simply disable neutron
lbaas, and don't need a config parameter in neutron.

Implementing this db schema within neutron instead will be not just
complicated, but a huge effort that will go waste in future once the new
LBaaS service is implemented. Also, migration will unnecessarily retain the
same steps needed to go from legacy neutron LBaaS to the new core LBaaS
service in this approach (twice, in succession) in case for any reason the
version goes from legacy neutron LBaaS -> new neutron LBaaS -> new LBaaS
core service.

Going forward, the legacy neutron LBaaS API can be deprecated, and the new
API that directly contacts the new LBaaS core service can be used.

We have discussed the above architecture previously, but outside of the ML,
and a draft of the blueprint for this new LBaaS core service is underway,
and is a collation of all the discussions among a large number of LBaaS
engineers including yourself during the summit - I will be posting it for
review within a couple of days, as planned.

Regards,
Vijay

On Tue, May 27, 2014 at 12:32 PM, Brandon Logan  wrote:

> Referencing this blueprint:
>
> https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst
>
> Anyone who has suggestions to possible issues or can answer some of
> these questions please respond.
>
>
> 1. LoadBalancer to Listener relationship M:N vs 1:N
> The main reason we went with the M:N was so IPv6 could use the same
> listener as IPv4.  However this can be accomplished by the user just
> creating a second listener and pool with the same configuration.  This
> will end up being a bad user experience when the listener and pool
> configuration starts getting complex (adding in TLS, health monitors,
> SNI, etc). A good reason to not do the M:N is because the logic on might
> get complex when dealing with status.  I'd like to get people's opinions
> on this on whether we should do M:N or just 1:N.  Another option, is to
> just implement 1:N right now and later implement the M:N in another
> blueprint if it is decided that the user experience suffers greatly.
>
> My opinion: I like the idea of leaving it to another blueprint to
> implement.  However, we would need to watch out for any major
> architecture changes in the time itis not implemented that could make
> this more difficult than what it needs to be.
>
> 2. Pool to Health Monitor relationship 1:N vs 1:1
> Currently, I believe this is 1:N however it was suggested to deprecate
> this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
> objections to channging to 1:1?
>
> My opinion: I'm for 1:1 as long as there aren't any major reasons why
> there needs to be 1:N.
>
> 3. Does the Pool object need a status field now that it is a pure
> logical object?
>
> My opinion: I don't think it needs the status field.  I think the
> LoadBalancer object may be the only thing that needs a status, other
> than the pool members for health monitoring.  I might be corrected on
> this though.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.opensta

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Vasudevan, Swaminathan (PNB Roseville)

On Tue, May 27, 2014 at 1:51 PM, Eugene Nikanorov
wrote:

> In fact, nova should be careful about changing number of retries for
> neutron client.
> It's known that under significant load (people test serial VM creation)
> neutron client may timeout on POST operation which does port creation;
> retrying this again leads to multiple fixed IPs assigned to a VM
>

This sounds like a bug in nova, nova should be able to handle intermittent
service timeouts without doing the wrong thing.


>
> Thanks,
> Eugene.
>
>
> On Wed, May 28, 2014 at 12:09 AM, Kyle Mestery 
> wrote:
>
>> I'm not aware of any such change at the moment, no.
>>
>> On Tue, May 27, 2014 at 3:06 PM, Paul Ward  wrote:
>> > Great!  Do you know if there's any corresponding nova changes to support
>> > this as a conf option that gets passed in to this new parm?
>> >
>> >
>> >
>> > Kyle Mestery  wrote on 05/27/2014 01:56:12
>> PM:
>> >
>> >> From: Kyle Mestery 
>> >> To: "OpenStack Development Mailing List (not for usage questions)"
>> >> ,
>> >> Date: 05/27/2014 02:00 PM
>> >> Subject: Re: [openstack-dev] [neutron] Supporting retries in
>> neutronclient
>> >
>> >
>> >>
>> >> On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
>> >> > Currently, neutronclient is hardcoded to only try a request once in
>> >> > retry_request by virtue of the fact that it uses self.retries as the
>> >> > retry
>> >> > count, and that's initialized to 0 and never changed.  We've seen an
>> >> > issue
>> >> > where we get an ssl handshaking error intermittently (seems like
>> more of
>> >> > an
>> >> > ssl bug) and a retry would probably have worked.  Yet, since
>> >> > neutronclient
>> >> > only tries once and gives up, it fails the entire operation.  Here is
>> >> > the
>> >> > code in question:
>> >> >
>> >> > https://github.com/openstack/python-neutronclient/blob/master/
>> >> neutronclient/v2_0/client.py#L1296
>> >> >
>> >> > Does anybody know if there's some explicit reason we don't currently
>> >> > allow
>> >> > configuring the number of retries?  If not, I'm inclined to propose a
>> >> > change
>> >> > for just that.
>> >> >
>> >> There is a review to address this in place now [1]. I've given a -1
>> >> due to a trivial reason which I hope Jakub will address soon so we can
>> >> land this patch in the client code.
>> >>
>> >> Thanks,
>> >> Kyle
>> >>
>> >> [1] https://review.openstack.org/#/c/90104/
>> >>
>> >> >
>> >> > ___
>> >> > OpenStack-dev mailing list
>> >> > OpenStack-dev@lists.openstack.org
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >>
>> >> ___
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

2014-05-27 Thread Martinx - ジェームズ

Hi Aaron!

The BUG report https://bugs.launchpad.net/neutron/+bug/1322945 is about
this problem, I posted there the instructions to reproduce it...

Basically, after attaching a private IPv6 subnet to your L3 Router, it will
break the "External Network" and its "Floating IPs", then, it becomes
impossible to delete that "External Network"... It enters in a "stuck"
state...

Regards,
Thiago


On 27 May 2014 18:34, Aaron Rosen  wrote:

> Hi,
>
> can you open a bug report on this and provide your setup configuration? I
> just tested this with ML2 and wasn't able to reproduce the issue.
>
> arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
>  --provider:network_type vlan  --provider:segmentation_id 124
> --provider:physical_network  asdf
> Unable to create the network. The VLAN 124 on physical network asdf is in
> use.
>
> arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
> Deleted network: asdf
>
> Thanks,
>
> Aaron
>
>
> On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ <
> thiagocmarti...@gmail.com> wrote:
>
>> Guys,
>>
>> I'm trying to delete a network in Neutron but it is failing, from Horizon
>> it triggers the error message above (subject), and from CLI, it shows this:
>>
>> ---
>> root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
>> Request Failed: internal server error while processing your request.
>> ---
>>
>> The logs shows:
>>
>> ---
>> ==> /var/log/neutron/server.log <==
>> 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
>> ('2804:290:4:dead::10', 56908, 0, 0)
>>
>> 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
>> HTTP connection (1): psuaa-1.mng.tcmc.com.br
>> 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
>> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
>> [21/May/2014 11:49:54] "GET
>> /v2.0/networks.json?fields=id&id=a1654832-8aac-42d5-8837-6d27b7421892
>> HTTP/1.1" 200 251 0.089015
>>
>> 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
>> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
>> ('2804:290:4:dead::10', 56910, 0, 0)
>>
>> 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
>> [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback
>> (most recent call last):
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 87, in
>> resource
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
>> method(request=request, **args)
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 449, in
>> delete
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
>> obj_deleter(request.context, id, **kwargs)
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py", line 494,
>> in delete_network
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
>> self.type_manager.release_segment(session, segment)
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
>> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line
>> 101, in release_segment
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
>> driver.obj.release_segment(session, segment)
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
>> AttributeError: 'NoneType' object has no attribute 'obj'
>> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
>> 2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
>> [req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
>> [21/May/2014 11:49:54] "DELETE
>> /v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1" 500 296
>> 0.048123
>> ---
>>
>> What can I do to delete a "net" that "doesn't want" to be deleted? Do I
>> just need to clean some tables directly on mysql, for example... ?
>>
>> NOTE: I'm double posting it here on dev list, because on user list no one
>> seems to be able to help me... Sorry BTW...   :)
>>
>> Tks!
>> Thiago
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Nader Lahouti

Thanks Kyle.

One more question: I have a BP for changes in python-neutronclient. Do I
need to have add a neutron-spec for that?

Thanks,
Nader.




On Tue, May 27, 2014 at 10:08 AM, Kyle Mestery wrote:

> On Tue, May 27, 2014 at 12:01 PM, Nader Lahouti 
> wrote:
> > Hi Kyle,
> >
>  ... But I just wanted to highlight
> >
>  that I removed a large number of BPs from targeting Juno-1 now which
>  did not have specifications linked to them...
> >
> > Will those BP be reviewed after updating the link to the specification?
> >
> The BPs will be reviewed per normal, but Juno-1 is 2 weeks out now, so
> realistically given review cycles, it's unlikely additional things
> (unless small) will land in Juno-1.
>
> Thanks,
> Kyle
>
> >
> > Thanks,
> > Nader.
> >
> >
> >
> >
> >
> > On Tue, May 27, 2014 at 7:14 AM, Kyle Mestery  >
> > wrote:
> >>
> >> Hi Neutron developers:
> >>
> >> I've spent some time cleaning up the BPs for Juno-1, and they are
> >> documented at the link below [1]. There are a large number of BPs
> >> currently under review right now in neutron-specs. If we land some of
> >> those specs this week, it's possible some of these could make it into
> >> Juno-1, pending review cycles and such. But I just wanted to highlight
> >> that I removed a large number of BPs from targeting Juno-1 now which
> >> did not have specifications linked to them nor specifications which
> >> were actively under review in neutron-specs.
> >>
> >> Also, a gentle reminder that the process for submitting specifications
> >> to Neutron is documented here [2].
> >>
> >> Thanks, and please reach out to me if you have any questions!
> >>
> >> Kyle
> >>
> >> [1] https://launchpad.net/neutron/+milestone/juno-1
> >> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Solum] PTL Candidacy Open

2014-05-27 Thread Anita Kuno

On 05/27/2014 06:25 PM, Adrian Otto wrote:
> Team,
> 
> If you would like to declare a candidacy for PTL for Solum, you may send an 
> email with the subject "[Solum] Solum PTL Candidacy” to this mailing list 
> declaring your candidacy. Please respond with candidacy notices no later than 
> 00:00 UTC on 2014-06-02. 
> 
> The following rules apply:
> 
> https://wiki.openstack.org/wiki/Solum/Elections
> 
> Thanks,
> 
> Adrian
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
Hi,

Can we get the wikipage broken up into sections a bit, for easier
consumption? This might be a reasonable template:
https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014

Note there is a section for the election official name and contact
information. This is useful to have on the wikipage.

Thanks, have a good election,
Anita.

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

[openstack-dev] Distributed Virtual Router Meeting Cancelled for May 28th 2014

Hi Folks,
Tomorrow's ( May 28th 2014)  Distributed Virtual Router will be cancelled. ( 
Since most of our team will be in an internal meeting).
We will resume our meeting next week.

Thanks

Swaminathan Vasudevan
Systems Software Engineer (TC)


HP Networking
Hewlett-Packard
8000 Foothills Blvd
M/S 5541
Roseville, CA - 95747
tel: 916.785.0937
fax: 916.785.1815
email: swaminathan.vasude...@hp.com


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

[openstack-dev] [Solum] PTL Candidacy Open

2014-05-27 Thread Adrian Otto

Team,

If you would like to declare a candidacy for PTL for Solum, you may send an 
email with the subject "[Solum] Solum PTL Candidacy” to this mailing list 
declaring your candidacy. Please respond with candidacy notices no later than 
00:00 UTC on 2014-06-02. 

The following rules apply:

https://wiki.openstack.org/wiki/Solum/Elections

Thanks,

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

Re: [openstack-dev] [TripleO] CI needs YOU

2014-05-27 Thread Robert Collins

Latest outage was due to nodepool having a stuck TCP connection to the
HP1 region again.

I've filed https://bugs.launchpad.net/python-novaclient/+bug/1323862
about it. If someone were to pick this up and run with it it would be
super useful.

-Rob

On 24 May 2014 05:01, Clint Byrum  wrote:
> I forgot to include a link explaining our cloud:
>
> https://wiki.openstack.org/wiki/TripleO/TripleOCloud
>
> Thanks!
>
> Excerpts from Clint Byrum's message of 2014-05-22 15:24:05 -0700:
>> Ahoy there, TripleO interested parties. In the last few months, we've
>> gotten a relatively robust, though not nearly complete, CI system for
>> TripleO. It is a bit unorthodox, as we have a strong desire to ensure
>> PXE booting works, and that requires us running in our own cloud.
>>
>> We have this working, in two regions of TripleO deployed clouds which
>> we manage ourselves. We've had quite a few issues, mostly hardware
>> related, and some related to the fact that TripleO doesn't have HA yet,
>> so our CI clouds go down whenever our controllers go down.
>>
>> Anyway, Derek Higgins, Dan Prince, Robert Collins, and myself, have been
>> doing most of the heavy lifting on this. As a result, CI is not up and
>> working all that often. It needs more operational support.
>>
>> So, I would encourage anyone interested in TripleO development to start
>> working with us to maintain these two cloud regions (hopefully more
>> regions will come up soon) so that we can keep CI flowing and expand
>> coverage to include even more of TripleO.
>>
>> Thank you!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins 
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Vishvananda Ishaya

I’m not sure that this is the right approach. We really have to add the old 
extension back for compatibility, so it might be best to simply keep that 
extension instead of adding a new way to do it.

Vish

On May 27, 2014, at 1:31 PM, Cazzolato, Sergio J  
wrote:

> I have created a blueprint to add this functionality to nova.
> 
> https://review.openstack.org/#/c/94519/
> 
> 
> -Original Message-
> From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] 
> Sent: Tuesday, May 27, 2014 5:11 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] nova default quotas
> 
> Phil,
> 
> You are correct and this seems to be an error. I don't think in the earlier 
> ML thread[1] that anyone remembered that the quota classes were being used 
> for default quotas. IMO we need to revert this removal as we (accidentally) 
> removed a Havana feature with no notification to the community. I've 
> reactivated a bug[2] and marked it critcal.
> 
> Vish
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
> [2] https://bugs.launchpad.net/nova/+bug/1299517
> 
> On May 27, 2014, at 12:19 PM, Day, Phil  wrote:
> 
>> Hi Vish,
>> 
>> I think quota classes have been removed from Nova now.
>> 
>> Phil
>> 
>> 
>> Sent from Samsung Mobile
>> 
>> 
>>  Original message 
>> From: Vishvananda Ishaya
>> Date:27/05/2014 19:24 (GMT+00:00)
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: Re: [openstack-dev] [nova] nova default quotas
>> 
>> Are you aware that there is already a way to do this through the cli using 
>> quota-class-update?
>> 
>> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
>> the bottom)
>> 
>> Are you suggesting that we also add the ability to use just regular 
>> quota-update? I'm not sure i see the need for both.
>> 
>> Vish
>> 
>> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J 
>>  wrote:
>> 
>>> I would to hear your thoughts about an idea to add a way to manage the 
>>> default quota values through the API.
>>> 
>>> The idea is to use the current quota api, but sending ''default' instead of 
>>> the tenant_id. This change would apply to quota-show and quota-update 
>>> methods.
>>> 
>>> This approach will help to simplify the implementation of another blueprint 
>>> named per-flavor-quotas
>>> 
>>> Feedback? Suggestions?
>>> 
>>> 
>>> Sergio Juan Cazzolato
>>> Intel Software Argentina
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [nova][vmware] Current state of the spawn refactor

2014-05-27 Thread Davanum Srinivas

Hi Michael,

* Phase 1 has one review left - https://review.openstack.org/#/c/92691/
* I'll update the phase 2 patch shortly -
https://review.openstack.org/#/c/87002/
* Once the 2 reviews above get approved, we will resurrect the
oslo.vmware BP/review - https://review.openstack.org/#/c/70175/

There is a team etherpad that has a game plan we try to keep
up-to-date - https://etherpad.openstack.org/p/vmware-subteam-juno.
Based on discussions during the summit, We are hoping to get the 3
items above into juno-1. So we can work on the features mentioned in
the etherpad.

Tracy,GaryK,Others, please chime in.

thanks,
dims

On Tue, May 27, 2014 at 5:31 PM, Michael Still  wrote:
> Hi.
>
> I've been looking at the current state of the vmware driver spawn
> refactor work, and as best as I can tell phase one is now complete.
> However, I can only find one phase two patch, and it is based on an
> outdated commit. That patch is:
>
> https://review.openstack.org/#/c/87002/
>
> There also aren't any phase three patches that I can see. What is the
> current state of this work? Is it still targeting juno-1?
>
> Thanks,
> Michael
>
> --
> Rackspace Australia
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Davanum Srinivas :: http://davanum.wordpress.com

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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward


That is great information, thanks Eugene.


Eugene Nikanorov  wrote on 05/27/2014 03:51:36 PM:

> From: Eugene Nikanorov 
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 05/27/2014 03:56 PM
> Subject: Re: [openstack-dev] [neutron] Supporting retries in
neutronclient
>
> In fact, nova should be careful about changing number of retries for
> neutron client.
> It's known that under significant load (people test serial VM
> creation) neutron client may timeout on POST operation which does
> port creation; retrying this again leads to multiple fixed IPs
> assigned to a VM
>
> Thanks,
> Eugene.
>

> On Wed, May 28, 2014 at 12:09 AM, Kyle Mestery  > wrote:
> I'm not aware of any such change at the moment, no.
>
> On Tue, May 27, 2014 at 3:06 PM, Paul Ward  wrote:
> > Great!  Do you know if there's any corresponding nova changes to
support
> > this as a conf option that gets passed in to this new parm?
> >
> >
> >
> > Kyle Mestery  wrote on 05/27/2014 01:56:12
PM:
> >
> >> From: Kyle Mestery 
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> ,
> >> Date: 05/27/2014 02:00 PM
> >> Subject: Re: [openstack-dev] [neutron] Supporting retries in
neutronclient
> >
> >
> >>
> >> On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
> >> > Currently, neutronclient is hardcoded to only try a request once in
> >> > retry_request by virtue of the fact that it uses self.retries as the
> >> > retry
> >> > count, and that's initialized to 0 and never changed.  We've seen an
> >> > issue
> >> > where we get an ssl handshaking error intermittently (seems like
more of
> >> > an
> >> > ssl bug) and a retry would probably have worked.  Yet, since
> >> > neutronclient
> >> > only tries once and gives up, it fails the entire operation.  Here
is
> >> > the
> >> > code in question:
> >> >
> >> > https://github.com/openstack/python-neutronclient/blob/master/
> >> neutronclient/v2_0/client.py#L1296
> >> >
> >> > Does anybody know if there's some explicit reason we don't currently
> >> > allow
> >> > configuring the number of retries?  If not, I'm inclined to propose
a
> >> > change
> >> > for just that.
> >> >
> >> There is a review to address this in place now [1]. I've given a -1
> >> due to a trivial reason which I hope Jakub will address soon so we can
> >> land this patch in the client code.
> >>
> >> Thanks,
> >> Kyle
> >>
> >> [1] https://review.openstack.org/#/c/90104/
> >>
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][vmware] Current state of the spawn refactor

2014-05-27 Thread Michael Still

Hi.

I've been looking at the current state of the vmware driver spawn
refactor work, and as best as I can tell phase one is now complete.
However, I can only find one phase two patch, and it is based on an
outdated commit. That patch is:

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

There also aren't any phase three patches that I can see. What is the
current state of this work? Is it still targeting juno-1?

Thanks,
Michael

-- 
Rackspace Australia

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

Re: [openstack-dev] [IceHouse][Neutron][Ubuntu 14.04] Error: Failed to delete network

Hi,

can you open a bug report on this and provide your setup configuration? I
just tested this with ML2 and wasn't able to reproduce the issue.

arosen@arosen-MacBookPro:~/devstack$ neutron net-create asdf
 --provider:network_type vlan  --provider:segmentation_id 124
--provider:physical_network  asdf
Unable to create the network. The VLAN 124 on physical network asdf is in
use.

arosen@arosen-MacBookPro:~/devstack$ neutron net-delete asdf
Deleted network: asdf

Thanks,

Aaron


On Fri, May 23, 2014 at 10:52 AM, Martinx - ジェームズ  wrote:

> Guys,
>
> I'm trying to delete a network in Neutron but it is failing, from Horizon
> it triggers the error message above (subject), and from CLI, it shows this:
>
> ---
> root@psuaa-1:~# neutron net-delete a1654832-8aac-42d5-8837-6d27b7421892
> Request Failed: internal server error while processing your request.
> ---
>
> The logs shows:
>
> ---
> ==> /var/log/neutron/server.log <==
> 2014-05-21 11:49:54.242 5797 INFO neutron.wsgi [-] (5797) accepted
> ('2804:290:4:dead::10', 56908, 0, 0)
>
> 2014-05-21 11:49:54.245 5797 INFO urllib3.connectionpool [-] Starting new
> HTTP connection (1): psuaa-1.mng.tcmc.com.br
> 2014-05-21 11:49:54.332 5797 INFO neutron.wsgi
> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] 2804:290:4:dead::10 - -
> [21/May/2014 11:49:54] "GET
> /v2.0/networks.json?fields=id&id=a1654832-8aac-42d5-8837-6d27b7421892
> HTTP/1.1" 200 251 0.089015
>
> 2014-05-21 11:49:54.334 5797 INFO neutron.wsgi
> [req-e1c4d6c4-71de-4bfa-a7db-f09fa0571377 None] (5797) accepted
> ('2804:290:4:dead::10', 56910, 0, 0)
>
> 2014-05-21 11:49:54.380 5797 ERROR neutron.api.v2.resource
> [req-f216416d-8433-444f-9108-f4a17f5bf49d None] delete failed
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource Traceback (most
> recent call last):
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 87, in
> resource
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource result =
> method(request=request, **args)
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 449, in
> delete
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
> obj_deleter(request.context, id, **kwargs)
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/plugin.py", line 494,
> in delete_network
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
> self.type_manager.release_segment(session, segment)
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource   File
> "/usr/lib/python2.7/dist-packages/neutron/plugins/ml2/managers.py", line
> 101, in release_segment
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
> driver.obj.release_segment(session, segment)
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource AttributeError:
> 'NoneType' object has no attribute 'obj'
> 2014-05-21 11:49:54.380 5797 TRACE neutron.api.v2.resource
> 2014-05-21 11:49:54.383 5797 INFO neutron.wsgi
> [req-f216416d-8433-444f-9108-f4a17f5bf49d None] 2804:290:4:dead::10 - -
> [21/May/2014 11:49:54] "DELETE
> /v2.0/networks/a1654832-8aac-42d5-8837-6d27b7421892.json HTTP/1.1" 500 296
> 0.048123
> ---
>
> What can I do to delete a "net" that "doesn't want" to be deleted? Do I
> just need to clean some tables directly on mysql, for example... ?
>
> NOTE: I'm double posting it here on dev list, because on user list no one
> seems to be able to help me... Sorry BTW...   :)
>
> Tks!
> Thiago
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Storyboard] [UX] Atlanta Storyboard UX Summary

2014-05-27 Thread Jacki Bauer


On May 22, 2014, at 4:28 AM, Thierry Carrez 
mailto:thie...@openstack.org>> wrote:

Now I understand it can be confusing, especially for people without a
Launchpad Bugs background. Maybe we can find a better term for "tasks"
("work items" ? "steps" ? "commits" ?), maybe we need to
educate/document more, maybe the UI should make it easier to grasp as a
concept. But given that our primary audience is OpenStack developers, I
suspect that once they understand the concept it's not that much of an
issue. And since most of them have to use Launchpad Bugs now (which has
a similar concept), the learning curve is not too steep...


Is there a mockup/prototype or anything that shows what the longer term vision 
of storyboard is - how the information architecture and workflow will be? As an 
easy example, is there a plan for a story to ever have a type - like ‘bug’, 
‘suggestion’, etc? The reason I ask is it can be hard to select good labels for 
things without knowing what the full data schema is going to look like. and 
vice versa, once more of that is visible in the UI, users might become less 
confused!

I’m also curious about the terms selected - ‘story’ has a specific meaning in 
agile but looks to be different in storyboard, and it seems like ‘blueprint’ 
isn’t being used anymore. If we understand the overall thinking behind the 
concepts, it will be easier for people to help come up with terms that better 
reflect those underlying concepts.

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

Re: [openstack-dev] [Horizon][UX] Improving the User Experience of Messaging in Horizon

2014-05-27 Thread Jacki Bauer


On May 20, 2014, at 3:37 PM, Liz Blanchard 
mailto:lsure...@redhat.com>> wrote:

I put together a page on the wiki [1] capturing a first draft of some ideas on 
how to improve the User Experience of the messaging in Horizon. These are not 
technical and really just focus on the presentation layer of these messages, 
but it would be great to see this be expanded or additional proposals be 
created around some of the technical discussions that need to take place for 
improving messaging.

Please feel free to add to/edit this page as you think makes sense. Also, any 
feedback is much appreciated.

Thanks for doing this! I think the content is spot on, and the big challenge is 
to get people using it. We probably need some place to keep all UI related 
standards (once they are created) and then point to it from places like Horizon 
launchpad or the Horizon project on the wiki so that people know it’s there.

I would like if we could eventually provide different examples of messages, 
good and bad, mocked up as either inline messages or the error ‘bubbles’ we use 
now - so developers could have a bunch of message ideas to copy and tweak to 
their needs.

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

Re: [openstack-dev] Spec repo names

2014-05-27 Thread Kurt Griffiths

> +1 to code names.

Technically, if a program contains multiple projects, it would be more
correct to use the program name, but at this point I think it is pretty
ingrained in our culture (including IRC, mailing list and summits) to
refer to things by their code/project names, so IMO using those names will
be more intuitive to contributors.

--Kurt

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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Eugene Nikanorov

In fact, nova should be careful about changing number of retries for
neutron client.
It's known that under significant load (people test serial VM creation)
neutron client may timeout on POST operation which does port creation;
retrying this again leads to multiple fixed IPs assigned to a VM

Thanks,
Eugene.


On Wed, May 28, 2014 at 12:09 AM, Kyle Mestery wrote:

> I'm not aware of any such change at the moment, no.
>
> On Tue, May 27, 2014 at 3:06 PM, Paul Ward  wrote:
> > Great!  Do you know if there's any corresponding nova changes to support
> > this as a conf option that gets passed in to this new parm?
> >
> >
> >
> > Kyle Mestery  wrote on 05/27/2014 01:56:12
> PM:
> >
> >> From: Kyle Mestery 
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> ,
> >> Date: 05/27/2014 02:00 PM
> >> Subject: Re: [openstack-dev] [neutron] Supporting retries in
> neutronclient
> >
> >
> >>
> >> On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
> >> > Currently, neutronclient is hardcoded to only try a request once in
> >> > retry_request by virtue of the fact that it uses self.retries as the
> >> > retry
> >> > count, and that's initialized to 0 and never changed.  We've seen an
> >> > issue
> >> > where we get an ssl handshaking error intermittently (seems like more
> of
> >> > an
> >> > ssl bug) and a retry would probably have worked.  Yet, since
> >> > neutronclient
> >> > only tries once and gives up, it fails the entire operation.  Here is
> >> > the
> >> > code in question:
> >> >
> >> > https://github.com/openstack/python-neutronclient/blob/master/
> >> neutronclient/v2_0/client.py#L1296
> >> >
> >> > Does anybody know if there's some explicit reason we don't currently
> >> > allow
> >> > configuring the number of retries?  If not, I'm inclined to propose a
> >> > change
> >> > for just that.
> >> >
> >> There is a review to address this in place now [1]. I've given a -1
> >> due to a trivial reason which I hope Jakub will address soon so we can
> >> land this patch in the client code.
> >>
> >> Thanks,
> >> Kyle
> >>
> >> [1] https://review.openstack.org/#/c/90104/
> >>
> >> >
> >> > ___
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Cazzolato, Sergio J

I have created a blueprint to add this functionality to nova.

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


-Original Message-
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] 
Sent: Tuesday, May 27, 2014 5:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] nova default quotas

Phil,

You are correct and this seems to be an error. I don't think in the earlier ML 
thread[1] that anyone remembered that the quota classes were being used for 
default quotas. IMO we need to revert this removal as we (accidentally) removed 
a Havana feature with no notification to the community. I've reactivated a 
bug[2] and marked it critcal.

Vish

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
[2] https://bugs.launchpad.net/nova/+bug/1299517

On May 27, 2014, at 12:19 PM, Day, Phil  wrote:

> Hi Vish,
> 
> I think quota classes have been removed from Nova now.
> 
> Phil
> 
> 
> Sent from Samsung Mobile
> 
> 
>  Original message 
> From: Vishvananda Ishaya
> Date:27/05/2014 19:24 (GMT+00:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [nova] nova default quotas
> 
> Are you aware that there is already a way to do this through the cli using 
> quota-class-update?
> 
> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
> the bottom)
> 
> Are you suggesting that we also add the ability to use just regular 
> quota-update? I'm not sure i see the need for both.
> 
> Vish
> 
> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J 
>  wrote:
> 
>> I would to hear your thoughts about an idea to add a way to manage the 
>> default quota values through the API.
>> 
>> The idea is to use the current quota api, but sending ''default' instead of 
>> the tenant_id. This change would apply to quota-show and quota-update 
>> methods.
>> 
>> This approach will help to simplify the implementation of another blueprint 
>> named per-flavor-quotas
>> 
>> Feedback? Suggestions?
>> 
>> 
>> Sergio Juan Cazzolato
>> Intel Software Argentina
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Kieran Spear


On 28/05/2014, at 6:11 AM, Vishvananda Ishaya  wrote:

> Phil,
> 
> You are correct and this seems to be an error. I don’t think in the earlier 
> ML thread[1] that anyone remembered that the quota classes were being used 
> for default quotas. IMO we need to revert this removal as we (accidentally) 
> removed a Havana feature with no notification to the community. I’ve 
> reactivated a bug[2] and marked it critical.

+1.

We rely on this to set the default quotas in our cloud.

Kieran

> 
> Vish
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
> [2] https://bugs.launchpad.net/nova/+bug/1299517
> 
> On May 27, 2014, at 12:19 PM, Day, Phil  wrote:
> 
>> Hi Vish,
>> 
>> I think quota classes have been removed from Nova now.
>> 
>> Phil
>> 
>> 
>> Sent from Samsung Mobile
>> 
>> 
>>  Original message 
>> From: Vishvananda Ishaya
>> Date:27/05/2014 19:24 (GMT+00:00)
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: Re: [openstack-dev] [nova] nova default quotas
>> 
>> Are you aware that there is already a way to do this through the cli using 
>> quota-class-update?
>> 
>> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
>> the bottom)
>> 
>> Are you suggesting that we also add the ability to use just regular 
>> quota-update? I’m not sure i see the need for both.
>> 
>> Vish
>> 
>> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J 
>>  wrote:
>> 
>>> I would to hear your thoughts about an idea to add a way to manage the 
>>> default quota values through the API.
>>> 
>>> The idea is to use the current quota api, but sending ''default' instead of 
>>> the tenant_id. This change would apply to quota-show and quota-update 
>>> methods.
>>> 
>>> This approach will help to simplify the implementation of another blueprint 
>>> named per-flavor-quotas
>>> 
>>> Feedback? Suggestions?
>>> 
>>> 
>>> Sergio Juan Cazzolato
>>> Intel Software Argentina
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward

Great!  Do you know if there's any corresponding nova changes to support
this as a conf option that gets passed in to this new parm?



Kyle Mestery  wrote on 05/27/2014 01:56:12 PM:

> From: Kyle Mestery 
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 05/27/2014 02:00 PM
> Subject: Re: [openstack-dev] [neutron] Supporting retries in
neutronclient
>
> On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
> > Currently, neutronclient is hardcoded to only try a request once in
> > retry_request by virtue of the fact that it uses self.retries as the
retry
> > count, and that's initialized to 0 and never changed.  We've seen an
issue
> > where we get an ssl handshaking error intermittently (seems like more
of an
> > ssl bug) and a retry would probably have worked.  Yet, since
neutronclient
> > only tries once and gives up, it fails the entire operation.  Here is
the
> > code in question:
> >
> > https://github.com/openstack/python-neutronclient/blob/master/
> neutronclient/v2_0/client.py#L1296
> >
> > Does anybody know if there's some explicit reason we don't currently
allow
> > configuring the number of retries?  If not, I'm inclined to propose a
change
> > for just that.
> >
> There is a review to address this in place now [1]. I've given a -1
> due to a trivial reason which I hope Jakub will address soon so we can
> land this patch in the client code.
>
> Thanks,
> Kyle
>
> [1] https://review.openstack.org/#/c/90104/
>
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Vishvananda Ishaya

Phil,

You are correct and this seems to be an error. I don’t think in the earlier ML 
thread[1] that anyone remembered that the quota classes were being used for 
default quotas. IMO we need to revert this removal as we (accidentally) removed 
a Havana feature with no notification to the community. I’ve reactivated a 
bug[2] and marked it critcal.

Vish

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027574.html
[2] https://bugs.launchpad.net/nova/+bug/1299517

On May 27, 2014, at 12:19 PM, Day, Phil  wrote:

> Hi Vish,
> 
> I think quota classes have been removed from Nova now.
> 
> Phil
> 
> 
> Sent from Samsung Mobile
> 
> 
>  Original message 
> From: Vishvananda Ishaya
> Date:27/05/2014 19:24 (GMT+00:00)
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [nova] nova default quotas
> 
> Are you aware that there is already a way to do this through the cli using 
> quota-class-update?
> 
> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
> the bottom)
> 
> Are you suggesting that we also add the ability to use just regular 
> quota-update? I’m not sure i see the need for both.
> 
> Vish
> 
> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J 
>  wrote:
> 
>> I would to hear your thoughts about an idea to add a way to manage the 
>> default quota values through the API.
>> 
>> The idea is to use the current quota api, but sending ''default' instead of 
>> the tenant_id. This change would apply to quota-show and quota-update 
>> methods.
>> 
>> This approach will help to simplify the implementation of another blueprint 
>> named per-flavor-quotas
>> 
>> Feedback? Suggestions?
>> 
>> 
>> Sergio Juan Cazzolato
>> Intel Software Argentina
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

I'm not aware of any such change at the moment, no.

On Tue, May 27, 2014 at 3:06 PM, Paul Ward  wrote:
> Great!  Do you know if there's any corresponding nova changes to support
> this as a conf option that gets passed in to this new parm?
>
>
>
> Kyle Mestery  wrote on 05/27/2014 01:56:12 PM:
>
>> From: Kyle Mestery 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> ,
>> Date: 05/27/2014 02:00 PM
>> Subject: Re: [openstack-dev] [neutron] Supporting retries in neutronclient
>
>
>>
>> On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
>> > Currently, neutronclient is hardcoded to only try a request once in
>> > retry_request by virtue of the fact that it uses self.retries as the
>> > retry
>> > count, and that's initialized to 0 and never changed.  We've seen an
>> > issue
>> > where we get an ssl handshaking error intermittently (seems like more of
>> > an
>> > ssl bug) and a retry would probably have worked.  Yet, since
>> > neutronclient
>> > only tries once and gives up, it fails the entire operation.  Here is
>> > the
>> > code in question:
>> >
>> > https://github.com/openstack/python-neutronclient/blob/master/
>> neutronclient/v2_0/client.py#L1296
>> >
>> > Does anybody know if there's some explicit reason we don't currently
>> > allow
>> > configuring the number of retries?  If not, I'm inclined to propose a
>> > change
>> > for just that.
>> >
>> There is a review to address this in place now [1]. I've given a -1
>> due to a trivial reason which I hope Jakub will address soon so we can
>> land this patch in the client code.
>>
>> Thanks,
>> Kyle
>>
>> [1] https://review.openstack.org/#/c/90104/
>>
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Openstack] [Keystone] Help extending Keystone JSON documents with custom attributes, safe?

2014-05-27 Thread Phillip Guerin

Are there any best practices defined around extending the Keystone JSON 
documents, 
or is there a better source to go to in order to get some guidance on this?

Thanks again for your time,

-PG

-Original Message-
From: Phillip Guerin [mailto:pgue...@sandvine.com] 
Sent: Thursday, May 22, 2014 9:30 AM
To: openst...@lists.openstack.org; openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Openstack] [Keystone] Help extending Keystone 
JSON documents with custom attributes, safe?


To be a bit more succinct, if I PATCH existing Keystone JSON documents 
(projects, roles, users, etc) with my own custom JSON attributes, can I expect 
this to be a safe practice? 

Meaning, I'd like to add my own custom attributes and be able to query them 
back at a later time when I look up the user or verify the authentication token.

Is this a behavior that we can count on working in the future?

If it is an appropriate way to add the metadata we want, are there naming 
conventions we must preserve in our custom attributes to avoid name collisions 
in the future?

Thank you very much for your time, help, and consideration,

-PG

-Original Message-
From: Phillip Guerin 
Sent: Thursday, May 15, 2014 4:16 PM
To: 'openst...@lists.openstack.org'
Subject: [Openstack] [Keystone] Extending Keystone JSON documents with custom 
attributes, safe?

Hello, 

We're working on a project that uses a REST interface that exposes a set of 
APIs to our internal systems. We'd like to leverage the Keystone data models 
for our own fine grained authorization by adding our own custom attributes to 
Keystone 'projects', 'users', etc.

For example:

"user": {
"domain": {
"id": "1789d1",
"links": {
"self": "http://identity:35357/v3/domains/1789d1";
},
"name": "example.com"
},
"id": "0ca8f6",
"links": {
"self": "http://identity:35357/v3/users/0ca8f6";
},
"name": "Joe"

"sandvine": {
"authorization": {
"requests": ["url", "url?fields=a,b,c"]
"attributes": {
"obfuscation": ["attr1"]
}
}
"accounting": { 
}
}

}

While I've done some simple tests and it essentially works, is this procedure 
of PATCHing Keystone user/role/etc... documents acceptable practice from your 
point of view?

Is this a behaviour that we can count on working in the future?

If it is an appropriate way to add the metadata we want, are there naming 
conventions we must preserve in our custom attributes to avoid name collisions 
in the future?

While this works on the direct objects I update, I don't see my custom fields 
when I verify the associated user token. Meaning, I can add my own attributes 
to 'user', but when I verify the token, I only see a subset of the 'user' 
attributes in the response payload. I don't see my own custom attributes and I 
don't see the 'links' attribute either. Whereas when I do a GET on the 'user' I 
just PATCHed, I see 'links' and my own custom attributes as well.

Is this by design, or am I potentially missing something in my token 
verification request or configuration that would return the full data model 
associated with the token? 
 - My work flow is to create a user, PATCH the user, GET the user to 
   confirm, then GET the token to ensure the PATCHed data has been 
   associated to it. I see changes to pre-existing Keystone attributes
   when I GET the token, I just don't see my custom additions.

If this isn't appropriate, is there an alternative method to add custom 
metadata to elements in the data model (users/roles/etc..)?

For example, we've also considered building a single nested JSON document and 
serializing that into the 'blob' section of the 'policy'
attribute.

Our service is not an Openstack service, so we cannot take advantage of writing 
policy to handle fine grained authorization of the APIs we're exploring through 
our own REST interface. The above is how we're trying to bridge that gap.


Thanks a lot for your time and feedback!

Phillip Guerin
Software Engineer
+1-519-572-4668
skype: phillip.guerin



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

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

[openstack-dev] [python-openstacksdk] Tuesday May 27 Meeting Minutes

2014-05-27 Thread Brian Curtin

Meeting ended Tue May 27 20:00:28 2014 UTC

Minutes: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.html

Minutes (text):
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.txt

Log: 
http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-27-19.01.log.html


Next meeting is Tuesday June 3 at 1900 UTC. I will be at PyCon Russia
and won't be able to run the meeting, so I'll try to grab someone else
to run the meeting.

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

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-27 Thread Sumit Naiksatam

There seems to be a fair bit of confusion with the PoC/prototype
patches. As such, and per reviewer feedback to introduce the Endpoint
Group related patch sooner than later, we will start a new series. You
will see this first patch land shortly, and we can incrementally make
progress from there.

On Tue, May 27, 2014 at 10:33 AM, Carlos Gonçalves  wrote:
> Hi,
>
> On 27 May 2014, at 15:55, Mohammad Banikazemi  wrote:
>
> GP like any other Neutron extension can have different implementations. Our
> idea has been to have the GP code organized similar to how ML2 and mechanism
> drivers are organized, with the possibility of having different drivers for
> realizing the GP API. One such driver (analogous to an ML2 mechanism driver
> I would say) is the mapping driver that was implemented for the PoC. I
> certainly do not see it as the only implementation. The mapping driver is
> just the driver we used for our PoC implementation in order to gain
> experience in developing such a driver. Hope this clarifies things a bit.
>
>
> The code organisation adopted to implement the PoC for the GP is indeed very
> similar to the one ML2 is using. There is one aspect I think GP will hit
> soon if it continues to follow with its current code base where multiple
> (policy) drivers will be available, and as Mohammad putted it as being
> analogous to an ML2 mech driver, but are independent from ML2’s. I’m
> unaware, however, if the following problem has already been brought to
> discussion or not.
>
> From here I see the GP effort going, besides from some code refactoring, I'd
> say expanding the supported policy drivers is the next goal. With that ODL
> support might next. Now, administrators enabling GP ODL support will have to
> configure ODL data twice (host, user, password) in case they’re using ODL as
> a ML2 mech driver too, because policy drivers share no information between
> ML2 ones. This can become more troublesome if ML2 is configured to load
> multiple mech drivers.
>
> With that said, if it makes any sense, a different implementation should be
> considered. One that somehow allows mech drivers living in ML2 umbrella to
> be extended; BP [1] [2] may be a first step towards that end, I’m guessing.
>
> Thanks,
> Carlos Gonçalves
>
> [1]
> https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
> [2] https://review.openstack.org/#/c/89208/
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Doug Wiegley

Thanks, Brandon.  My opinion, reproduced from an IRC conversation that we
had earlier today:

I don't have a strong objection, just an implementation shudder.  Of the
two backends that I'm familiar with, they support 1:N, not N:N  So, we
fake it by duping listeners on the fly. But, consider the extreme, say
1000 LB's and 1 shared listener.  How long does it take to create 1000
listeners?  What happens when it fails on 998?  Ok, we rollback.  What
happens when the rollback fails?  Inconsistent state.  Driver's can't
async.  Driver's can't run cleanup routines later.

What about when half the LB's have lit listeners and the other half don't;
does the db say that N:N link is there yet or not?

Shrink the allowed number of listeners and the window of pain gets
smaller, but at operator scale, even a small window will get hit.

Thanks,

doug

On 5/27/14, 1:32 PM, "Brandon Logan"  wrote:

>Referencing this blueprint:
>https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel
>-improvement.rst
>
>Anyone who has suggestions to possible issues or can answer some of
>these questions please respond.
>
>
>1. LoadBalancer to Listener relationship M:N vs 1:N
>The main reason we went with the M:N was so IPv6 could use the same
>listener as IPv4.  However this can be accomplished by the user just
>creating a second listener and pool with the same configuration.  This
>will end up being a bad user experience when the listener and pool
>configuration starts getting complex (adding in TLS, health monitors,
>SNI, etc). A good reason to not do the M:N is because the logic on might
>get complex when dealing with status.  I'd like to get people's opinions
>on this on whether we should do M:N or just 1:N.  Another option, is to
>just implement 1:N right now and later implement the M:N in another
>blueprint if it is decided that the user experience suffers greatly.
>
>My opinion: I like the idea of leaving it to another blueprint to
>implement.  However, we would need to watch out for any major
>architecture changes in the time itis not implemented that could make
>this more difficult than what it needs to be.
>
>2. Pool to Health Monitor relationship 1:N vs 1:1
>Currently, I believe this is 1:N however it was suggested to deprecate
>this in favor of 1:1 by Susanne and Kyle agreed.  Are there any
>objections to channging to 1:1?
>
>My opinion: I'm for 1:1 as long as there aren't any major reasons why
>there needs to be 1:N.
>
>3. Does the Pool object need a status field now that it is a pure
>logical object?
>
>My opinion: I don't think it needs the status field.  I think the
>LoadBalancer object may be the only thing that needs a status, other
>than the pool members for health monitoring.  I might be corrected on
>this though.
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Neutron][LBaaS] Unanswered questions in object model refactor blueprint

2014-05-27 Thread Brandon Logan

Referencing this blueprint:
https://review.openstack.org/#/c/89903/5/specs/juno/lbaas-api-and-objmodel-improvement.rst

Anyone who has suggestions to possible issues or can answer some of
these questions please respond.

1. LoadBalancer to Listener relationship M:N vs 1:N
The main reason we went with the M:N was so IPv6 could use the same
listener as IPv4. However this can be accomplished by the user just
creating a second listener and pool with the same configuration. This
will end up being a bad user experience when the listener and pool
configuration starts getting complex (adding in TLS, health monitors,
SNI, etc). A good reason to not do the M:N is because the logic on might
get complex when dealing with status. I'd like to get people's opinions
on this on whether we should do M:N or just 1:N. Another option, is to
just implement 1:N right now and later implement the M:N in another
blueprint if it is decided that the user experience suffers greatly.

My opinion: I like the idea of leaving it to another blueprint to
implement. However, we would need to watch out for any major
architecture changes in the time itis not implemented that could make
this more difficult than what it needs to be.

2. Pool to Health Monitor relationship 1:N vs 1:1
Currently, I believe this is 1:N however it was suggested to deprecate
this in favor of 1:1 by Susanne and Kyle agreed. Are there any
objections to channging to 1:1?

My opinion: I'm for 1:1 as long as there aren't any major reasons why
there needs to be 1:N.

3. Does the Pool object need a status field now that it is a pure
logical object?

My opinion: I don't think it needs the status field. I think the
LoadBalancer object may be the only thing that needs a status, other
than the pool members for health monitoring. I might be corrected on
this though.

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

Re: [openstack-dev] [MagnetoDB] PTL elections

2014-05-27 Thread Sergey Lukjanov

Hey Charles,

it's a self-nomination and it's for the Juno dev cycle (to adjust next
elections with dev cycle).

Thanks.

On Tue, May 27, 2014 at 7:48 PM, Charles Wang  wrote:
> Hi Sergey,
>
> A couple of questions with regard to the process:
>
> 1. Is it self nomination only or we can nominate someone else?
> 2. Is the PTL for Juno, or for a length of 6 months?
>
> Thanks,
>
> Charles Wang
> charles_w...@symantec.com
>
>
> On 5/26/14, 8:16 AM, "Sergey Lukjanov"  wrote:
>
>>Hi folks,
>>
>>due to the requirement to have PTL for the program, we're running
>>elections for the MagnetoDB PTL for Juno cycle. Schedule and policies
>>are fully aligned with official OpenStack PTLs elections.
>>
>>You can find more info in official Juno elections wiki page [0] and
>>the same page for MagnetoDB elections [1], additionally some more info
>>in official nominations opening email [2].
>>
>>Timeline:
>>
>>till 05:59 UTC May 30, 2014: Open candidacy to MagnetoDB PTL positions
>>May 30, 2014 - 1300 UTC June 6, 2014: PTL elections
>>
>>To announce your candidacy please start a new openstack-dev at
>>lists.openstack.org mailing list thread with the following subject:
>>"[MagnetoDB] PTL Candidacy".
>>
>>[0] https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
>>[1] https://wiki.openstack.org/wiki/MagnetoDB/PTL_Elections_Juno
>>[2]
>>http://lists.openstack.org/pipermail/openstack-dev/2014-March/031239.html
>>
>>Thank you.
>>
>>
>>--
>>Sincerely yours,
>>Sergey Lukjanov
>>Sahara Technical Lead
>>(OpenStack Data Processing)
>>Mirantis Inc.
>>
>>___
>>OpenStack-dev mailing list
>>OpenStack-dev@lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.

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

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Day, Phil

Hi Vish,

I think quota classes have been removed from Nova now.

Phil


Sent from Samsung Mobile


 Original message 
From: Vishvananda Ishaya
Date:27/05/2014 19:24 (GMT+00:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [nova] nova default quotas

Are you aware that there is already a way to do this through the cli using 
quota-class-update?

http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
the bottom)

Are you suggesting that we also add the ability to use just regular 
quota-update? I’m not sure i see the need for both.

Vish

On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J  
wrote:

> I would to hear your thoughts about an idea to add a way to manage the 
> default quota values through the API.
>
> The idea is to use the current quota api, but sending ''default' instead of 
> the tenant_id. This change would apply to quota-show and quota-update methods.
>
> This approach will help to simplify the implementation of another blueprint 
> named per-flavor-quotas
>
> Feedback? Suggestions?
>
>
> Sergio Juan Cazzolato
> Intel Software Argentina
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Trove] Trove-Gate idle time

2014-05-27 Thread Lowery, Mathew

Trove-Gate appears to sit idle after the last output from the test run. See the 
following samples:

Excerpt from https://rdjenkins.dyndns.org/job/Trove-Gate/3792/console

12:59:47 202.03 proboscis.case.MethodTest 
(test_instance_returns_to_active_after_resize)
13:47:06 **

Excerpt from https://rdjenkins.dyndns.org/job/Trove-Gate/3790/console

12:25:13 237.68 proboscis.case.MethodTest 
(test_instance_returns_to_active_after_resize)
13:10:54 **

Notice the timestamps of the lines. The first line in each sample is the last 
line of output from the int tests. The second line in each sample is the 
boot-hpcloud-vm plugin. In the absence of the timeout setting in the 
boot-hpcloud-vm plugin, I don't think these jobs would ever end. But the 
boot-hpcloud-vm plugin does have a timeout. I was able to reproduce what I 
think is the same problem with the following code:

cat << EOF > $temp_file
...beginning of script omitted...
./redstack int-tests
EOF
scp $temp_file stack@$ip:/home/stack
ssh stack@$ip /bin/bash -e /home/stack/$(basename $temp_file)

All of the tests pass but the job sits there spinning forever. However, if I 
add "-t -t" to the last line like so:

ssh -t -t stack@$ip /bin/bash -e /home/stack/$(basename $temp_file)

The job completes. Note: Adding "-t -t" makes the int tests process think I 
have a color terminal so I also added the following line before kicking off the 
tests:

export TERM=xterm-mono

Questions:

  *   I don't understand tty very well. Can someone help me understand why this 
works (if in fact this is the cause)? Possibly related question: Why does the 
README.md
 say, "chmod 660 /dev/pts/1"?
  *   If this is the fix, then some edits may be needed 
here
 using 
this.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

Hi Kyle-

I'm working the issues with our FTP server which is hosting the CI testing logs.

Will update the status of the Server in this Email chain.

-
Trinath



From: Kyle Mestery 
Sent: Wednesday, May 28, 2014 12:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

I've marked it as Juno-1 for now, but as Salvatore indicated, there
are some issues with third party testing which need to be addressed
before this can be merged. It would be a good idea to attend the IRC
meeting Anita pointed out as well.

Thanks,
Kyle

On Tue, May 27, 2014 at 1:45 PM, trinath.soman...@freescale.com
 wrote:
> Hi Kyle-
>
> The BP Spec approved.
>
> https://review.openstack.org/#/c/88190/
>
> Kindly consider my BP spec for Juno-1.
>
> Thanking all the code reviewers for their time to review my ML2 MD Spec and 
> making me to improve the spec.
>
> -
> Trinaths
>
> 
> From: Kyle Mestery 
> Sent: Tuesday, May 27, 2014 10:46 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav  wrote:
>> Hi,
>>
>> I have been working on the port mirroring blueprint and i was asked to
>> submit a neutron spec related to this
>> I have drafter the spec and ready to commit it to the
>> 'git://git.openstack.org/openstack/neutron-specs' repository for
>> review. Since the blueprint for this was old i was asked to submit the spec
>> for review. should i also bring the old blueprint to life
>> by linking it the spec that i will commit.
>>
> You can file a BP in launchpad. We're using those to track progress
> against milestones for release management reasons. Please see the
> instructions here [1]. Once the BP is filed in neutron-specs, reviewed
> and approved, we can track it to milestones. But at this point, this
> won't make it to Juno-1, given that's 2 weeks away.
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>> We are calling the new spec Tap-as-a-Service
>>
>> Cheers,
>>
>> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}
>>
>>
>> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery 
>> wrote:
>>>
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are
>>> documented at the link below [1]. There are a large number of BPs
>>> currently under review right now in neutron-specs. If we land some of
>>> those specs this week, it's possible some of these could make it into
>>> Juno-1, pending review cycles and such. But I just wanted to highlight
>>> that I removed a large number of BPs from targeting Juno-1 now which
>>> did not have specifications linked to them nor specifications which
>>> were actively under review in neutron-specs.
>>>
>>> Also, a gentle reminder that the process for submitting specifications
>>> to Neutron is documented here [2].
>>>
>>> Thanks, and please reach out to me if you have any questions!
>>>
>>> Kyle
>>>
>>> [1] https://launchpad.net/neutron/+milestone/juno-1
>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [neutron] Supporting retries in neutronclient

On Tue, May 27, 2014 at 12:48 PM, Paul Ward  wrote:
> Currently, neutronclient is hardcoded to only try a request once in
> retry_request by virtue of the fact that it uses self.retries as the retry
> count, and that's initialized to 0 and never changed.  We've seen an issue
> where we get an ssl handshaking error intermittently (seems like more of an
> ssl bug) and a retry would probably have worked.  Yet, since neutronclient
> only tries once and gives up, it fails the entire operation.  Here is the
> code in question:
>
> https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L1296
>
> Does anybody know if there's some explicit reason we don't currently allow
> configuring the number of retries?  If not, I'm inclined to propose a change
> for just that.
>
There is a review to address this in place now [1]. I've given a -1
due to a trivial reason which I hope Jakub will address soon so we can
land this patch in the client code.

Thanks,
Kyle

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

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

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Anita Kuno

On 05/27/2014 02:42 PM, trinath.soman...@freescale.com wrote:
> 
> Hi-
> 
> Sure Anita. I have been attending meeting for ML2 at #openstack-meeting-alt.
> 
> Will also, attend the below mentioned meetings ..
> 
> Thanking you.
> 
> -
> Trinaths
Great. Have you ever considered spending time in the channels I
mentioned (they aren't meetings) and asking questions in the channel?
Some people find that is a very efficient way of working.

Anita.
> 
> From: Anita Kuno 
> Sent: Tuesday, May 27, 2014 10:45 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
> 
> On 05/27/2014 01:03 PM, trinath.soman...@freescale.com wrote:
>> Hi-
>>
>>
>> Thanks a lot Salvatore.
>>
>>
>> I'm looking into that issue. I'm troubleshooting the same.
>>
>>
>> Will update this mail chain when its accessible for review.
>>
>>
>> Thanks a lot for the review Salvatore.
>>
>>
>> --
>>
>> Trinath
> Have you considered starting an irc client, navigating to freenode and
> joining the #openstack-dev and #openstack-neutron channels? It would
> increase the rate at which you learn how to amend your code to get it
> merged. It also would help as you troubleshoot your CI system.
> 
> Give it some thought,
> Anita.
>>
>>
>> 
>> From: Salvatore Orlando 
>> Sent: Tuesday, May 27, 2014 10:29 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>>
>> Too late.
>>
>> I just approved the specification.
>> I don't think there is any need for reverting the blueprint and just 
>> updating the topic in the patch.
>>
>> Please have a look at Freescale CI - logs are not accessible at the moment.
>>
>> Salvatore
>>
>>
>> On 27 May 2014 18:51, 
>> trinath.soman...@freescale.com 
>> mailto:trinath.soman...@freescale.com>> 
>> wrote:
>> Hi-
>>
>> Sure!. Will change the topic and update you.
>>
>> Thanks a lot for the reply and review.
>>
>> Your review helps me a lot to proceed further with code.
>>
>> Thanking you ..
>>
>> -
>> Trinath Somanchi
>> 
>> From: Edgar Magana Perdomo (eperdomo) 
>> mailto:eperd...@cisco.com>>
>> Sent: Tuesday, May 27, 2014 10:18 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>>
>> My only comment is that the name of the topic should be:
>>
>> bp/fsl-sdn-os-mech-driver
>>
>>
>> Instead of:
>> bp/https
>>
>>
>> I guss we can pass this..
>>
>> Edgar
>>
>> On 5/27/14, 9:23 AM, 
>> "trinath.soman...@freescale.com"
>> mailto:trinath.soman...@freescale.com>> 
>> wrote:
>>
>>> Hi Kyle
>>>
>>> Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>>> for Juno1.
>>>
>>> I have been mailing the reviewer to kindly make some to to review the BP
>>> spec.
>>>
>>> I have code too in place for review along with working CI.
>>>
>>> The Code for review : https://review.openstack.org/#/c/78092/
>>>
>>> Kindly please do the needful.
>>>
>>> --
>>> Trinath Somanchi.
>>>
>>> 
>>> From: Kyle Mestery 
>>> mailto:mest...@noironetworks.com>>
>>> Sent: Tuesday, May 27, 2014 7:44 PM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [neutron] BPs for Juno-1
>>>
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are
>>> documented at the link below [1]. There are a large number of BPs
>>> currently under review right now in neutron-specs. If we land some of
>>> those specs this week, it's possible some of these could make it into
>>> Juno-1, pending review cycles and such. But I just wanted to highlight
>>> that I removed a large number of BPs from targeting Juno-1 now which
>>> did not have specifications linked to them nor specifications which
>>> were actively under review in neutron-specs.
>>>
>>> Also, a gentle reminder that the process for submitting specifications
>>> to Neutron is documented here [2].
>>>
>>> Thanks, and please reach out to me if you have any questions!
>>>
>>> Kyle
>>>
>>> [1] https://launchpad.net/neutron/+milestone/juno-1
>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [neutron] BPs for Juno-1

I've marked it as Juno-1 for now, but as Salvatore indicated, there
are some issues with third party testing which need to be addressed
before this can be merged. It would be a good idea to attend the IRC
meeting Anita pointed out as well.

Thanks,
Kyle

On Tue, May 27, 2014 at 1:45 PM, trinath.soman...@freescale.com
 wrote:
> Hi Kyle-
>
> The BP Spec approved.
>
> https://review.openstack.org/#/c/88190/
>
> Kindly consider my BP spec for Juno-1.
>
> Thanking all the code reviewers for their time to review my ML2 MD Spec and 
> making me to improve the spec.
>
> -
> Trinaths
>
> 
> From: Kyle Mestery 
> Sent: Tuesday, May 27, 2014 10:46 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav  wrote:
>> Hi,
>>
>> I have been working on the port mirroring blueprint and i was asked to
>> submit a neutron spec related to this
>> I have drafter the spec and ready to commit it to the
>> 'git://git.openstack.org/openstack/neutron-specs' repository for
>> review. Since the blueprint for this was old i was asked to submit the spec
>> for review. should i also bring the old blueprint to life
>> by linking it the spec that i will commit.
>>
> You can file a BP in launchpad. We're using those to track progress
> against milestones for release management reasons. Please see the
> instructions here [1]. Once the BP is filed in neutron-specs, reviewed
> and approved, we can track it to milestones. But at this point, this
> won't make it to Juno-1, given that's 2 weeks away.
>
> Thanks,
> Kyle
>
> [1] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>> We are calling the new spec Tap-as-a-Service
>>
>> Cheers,
>>
>> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}
>>
>>
>> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery 
>> wrote:
>>>
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are
>>> documented at the link below [1]. There are a large number of BPs
>>> currently under review right now in neutron-specs. If we land some of
>>> those specs this week, it's possible some of these could make it into
>>> Juno-1, pending review cycles and such. But I just wanted to highlight
>>> that I removed a large number of BPs from targeting Juno-1 now which
>>> did not have specifications linked to them nor specifications which
>>> were actively under review in neutron-specs.
>>>
>>> Also, a gentle reminder that the process for submitting specifications
>>> to Neutron is documented here [2].
>>>
>>> Thanks, and please reach out to me if you have any questions!
>>>
>>> Kyle
>>>
>>> [1] https://launchpad.net/neutron/+milestone/juno-1
>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] BPs for Juno-1


Hi-

Sure Anita. I have been attending meeting for ML2 at #openstack-meeting-alt.

Will also, attend the below mentioned meetings ..

Thanking you.

-
Trinaths

From: Anita Kuno 
Sent: Tuesday, May 27, 2014 10:45 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

On 05/27/2014 01:03 PM, trinath.soman...@freescale.com wrote:
> Hi-
>
>
> Thanks a lot Salvatore.
>
>
> I'm looking into that issue. I'm troubleshooting the same.
>
>
> Will update this mail chain when its accessible for review.
>
>
> Thanks a lot for the review Salvatore.
>
>
> --
>
> Trinath
Have you considered starting an irc client, navigating to freenode and
joining the #openstack-dev and #openstack-neutron channels? It would
increase the rate at which you learn how to amend your code to get it
merged. It also would help as you troubleshoot your CI system.

Give it some thought,
Anita.
>
>
> 
> From: Salvatore Orlando 
> Sent: Tuesday, May 27, 2014 10:29 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> Too late.
>
> I just approved the specification.
> I don't think there is any need for reverting the blueprint and just updating 
> the topic in the patch.
>
> Please have a look at Freescale CI - logs are not accessible at the moment.
>
> Salvatore
>
>
> On 27 May 2014 18:51, 
> trinath.soman...@freescale.com 
> mailto:trinath.soman...@freescale.com>> wrote:
> Hi-
>
> Sure!. Will change the topic and update you.
>
> Thanks a lot for the reply and review.
>
> Your review helps me a lot to proceed further with code.
>
> Thanking you ..
>
> -
> Trinath Somanchi
> 
> From: Edgar Magana Perdomo (eperdomo) 
> mailto:eperd...@cisco.com>>
> Sent: Tuesday, May 27, 2014 10:18 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> My only comment is that the name of the topic should be:
>
> bp/fsl-sdn-os-mech-driver
>
>
> Instead of:
> bp/https
>
>
> I guss we can pass this..
>
> Edgar
>
> On 5/27/14, 9:23 AM, 
> "trinath.soman...@freescale.com"
> mailto:trinath.soman...@freescale.com>> wrote:
>
>> Hi Kyle
>>
>> Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>> for Juno1.
>>
>> I have been mailing the reviewer to kindly make some to to review the BP
>> spec.
>>
>> I have code too in place for review along with working CI.
>>
>> The Code for review : https://review.openstack.org/#/c/78092/
>>
>> Kindly please do the needful.
>>
>> --
>> Trinath Somanchi.
>>
>> 
>> From: Kyle Mestery 
>> mailto:mest...@noironetworks.com>>
>> Sent: Tuesday, May 27, 2014 7:44 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [neutron] BPs for Juno-1
>>
>> Hi Neutron developers:
>>
>> I've spent some time cleaning up the BPs for Juno-1, and they are
>> documented at the link below [1]. There are a large number of BPs
>> currently under review right now in neutron-specs. If we land some of
>> those specs this week, it's possible some of these could make it into
>> Juno-1, pending review cycles and such. But I just wanted to highlight
>> that I removed a large number of BPs from targeting Juno-1 now which
>> did not have specifications linked to them nor specifications which
>> were actively under review in neutron-specs.
>>
>> Also, a gentle reminder that the process for submitting specifications
>> to Neutron is documented here [2].
>>
>> Thanks, and please reach out to me if you have any questions!
>>
>> Kyle
>>
>> [1] https://launchpad.net/neutron/+milestone/juno-1
>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-b

Re: [openstack-dev] [Fuel-dev] access-control-master-node

2014-05-27 Thread Andrew Woodward

AFIK, if we implement ironic as a replacement for cobbler, we will
have Keystone on the fuel-master anyway. Supporting OAuth as an
additional authentication entry would awesome too, but I'm not sure if
there would be much demand over Keystone.

On Tue, May 27, 2014 at 8:31 AM, Lukasz Oles  wrote:
> There is some misunderstanding here. By using keystone I mean running
> keystone on fuel master node. After all it's just python program. It's used
> by OpenStack as authorization tool but it also can be used as standalone
> software or by different tools completely not connected with OpenStack.
> In future if  want to use LDAP source, keystone already have plugin for it.
>
> Regards
>
>
> On Tue, May 27, 2014 at 5:08 PM, David Easter  wrote:
>>
>> The other challenge of utilizing Keystone is which one to use.  Fuel
>> enables the deployment of multiple cloud environments from one UI; so when
>> accessing the Fuel Master Node, it would be ambiguous which already deployed
>> Keystone to contact for authentication.  If/When Triple-O is utilized, one
>> could perhaps see designating the Keystone of the undercloud; but that’s
>> more a future requirement.
>>
>> For now, I’d suggest an internal authentication in the immediate short
>> term.  External auth sources can be added in future milestones – most likely
>> an LDAP source that’s outside the deployed clouds and designated by IT.
>>
>> Thanks,
>>
>> - David J. Easter
>>   Director of Product Management, Mirantis
>>
>> From: Jesse Pretorius 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Tuesday, May 27, 2014 at 7:43 AM
>>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node
>>
>> On 27 May 2014 13:42, Lukasz Oles  wrote:
>>>
>>> Hello fuelers,
>>>
>>> we(I and Kamil) would like start discussion about "Enforce access control
>>> for Fuel UI" blueprint
>>> https://blueprints.launchpad.net/fuel/+spec/access-control-master-node.
>>>
>>> First question to David, as he proposed this bp. Do you want to add more
>>> requirements?
>>>
>>> To all. What do you think about using keystone as authorization tool? We
>>> described all pros/cons in the specification.
>>
>>
>> I would suggest both an internal authentication database and the option of
>> plugging additional options in, with keystone being one of them and perhaps
>> something like oauth being another.
>>
>> Keystone may not be available at the time of the build, or accessible from
>> the network that's used for the initial build.
>> ___ OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to : fuel-...@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Łukasz Oleś
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to : fuel-...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Andrew
Mirantis
Ceph community

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

Re: [openstack-dev] [neutron] BPs for Juno-1

Hi Kyle-

The BP Spec approved.

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

Kindly consider my BP spec for Juno-1.

Thanking all the code reviewers for their time to review my ML2 MD Spec and 
making me to improve the spec.

-
Trinaths


From: Kyle Mestery 
Sent: Tuesday, May 27, 2014 10:46 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav  wrote:
> Hi,
>
> I have been working on the port mirroring blueprint and i was asked to
> submit a neutron spec related to this
> I have drafter the spec and ready to commit it to the
> 'git://git.openstack.org/openstack/neutron-specs' repository for
> review. Since the blueprint for this was old i was asked to submit the spec
> for review. should i also bring the old blueprint to life
> by linking it the spec that i will commit.
>
You can file a BP in launchpad. We're using those to track progress
against milestones for release management reasons. Please see the
instructions here [1]. Once the BP is filed in neutron-specs, reviewed
and approved, we can track it to milestones. But at this point, this
won't make it to Juno-1, given that's 2 weeks away.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Blueprints#Neutron

> We are calling the new spec Tap-as-a-Service
>
> Cheers,
>
> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}
>
>
> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery 
> wrote:
>>
>> Hi Neutron developers:
>>
>> I've spent some time cleaning up the BPs for Juno-1, and they are
>> documented at the link below [1]. There are a large number of BPs
>> currently under review right now in neutron-specs. If we land some of
>> those specs this week, it's possible some of these could make it into
>> Juno-1, pending review cycles and such. But I just wanted to highlight
>> that I removed a large number of BPs from targeting Juno-1 now which
>> did not have specifications linked to them nor specifications which
>> were actively under review in neutron-specs.
>>
>> Also, a gentle reminder that the process for submitting specifications
>> to Neutron is documented here [2].
>>
>> Thanks, and please reach out to me if you have any questions!
>>
>> Kyle
>>
>> [1] https://launchpad.net/neutron/+milestone/juno-1
>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

[openstack-dev] [Neutron][QoS] First meeting minutes

2014-05-27 Thread Collins, Sean

http://eavesdrop.openstack.org/meetings/neutron_qos/2014/neutron_qos.2014-05-27-18.01.html

See everyone next week!
-- 
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Supporting retries in neutronclient

2014-05-27 Thread Paul Ward



Currently, neutronclient is hardcoded to only try a request once in
retry_request by virtue of the fact that it uses self.retries as the retry
count, and that's initialized to 0 and never changed.  We've seen an issue
where we get an ssl handshaking error intermittently (seems like more of an
ssl bug) and a retry would probably have worked.  Yet, since neutronclient
only tries once and gives up, it fails the entire operation.  Here is the
code in question:

https://github.com/openstack/python-neutronclient/blob/master/neutronclient/v2_0/client.py#L1296

Does anybody know if there's some explicit reason we don't currently allow
configuring the number of retries?  If not, I'm inclined to propose a
change for just that.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Seeking opinions on scope of code refactoring...

2014-05-27 Thread Paul Michali (pcm)

So I hit some more complexity, when I got to the IPSec connection resource’s 
update API…

I was doing code like this:

In VPN plugin:
def create_ipsec_site_connection(self, context, ipsec_site_connection):
driver = self._get_driver_for_ipsec_site_connection(
context, ipsec_site_connection)
driver.validate_create_ipsec_site_connection(context,
 ipsec_site_connection)
ipsec_site_connection = super(
VPNDriverPlugin, self).create_ipsec_site_connection(
context, ipsec_site_connection)
driver.apply_create_ipsec_site_connection(context,
  ipsec_site_connection)
return ipsec_site_connection

In ABC for service drvier:

def validate_create_ipsec_site_connection(self, context,
  ipsec_site_connection):
ipsec_sitecon = ipsec_site_connection['ipsec_site_connection']
dpd = ipsec_sitecon.get('dpd', {})
ipsec_sitecon['dpd_action'] = dpd.get('action', 'hold')
ipsec_sitecon['dpd_interval'] = dpd.get('interval', 30)
ipsec_sitecon['dpd_timeout'] = dpd.get('timeout', 120)
self._check_dpd(ipsec_sitecon)
self._check_mtu(context,
ipsec_sitecon['mtu'],
ipsec_sitecon['vpnservice_id'])

However, when considering the update_ipsec_site_connection() API, I realized 
that there could be multiple requests coming in to change the same connection’s 
attributes. In this case, validating and then persisting has the issue of 
incompatible changes being committed (e.g. one client changes DPD interval, and 
another client changes DPD timeout, such that they fail the _check_mtu() call).

I’m wondering what the thoughts are, regarding how to handle this. One way, I 
guess, may be do call the service driver validation from within the database 
logic, like this:

In VPN plugin
def create_ipsec_site_connection(self, context, ipsec_site_connection):
driver = self._get_driver_for_ipsec_site_connection(
context, ipsec_site_connection)
ipsec_site_connection = super(
VPNDriverPlugin, self).create_ipsec_site_connection(
context, ipsec_site_connection)
driver.apply_create_ipsec_site_connection(context,
  ipsec_site_connection)
return ipsec_site_connection

In Database (pseudo-code)
def create_ipsec_site_connection(self, context, ipsec_site_connection):
ipsec_sitecon = ipsec_site_connection['ipsec_site_connection']
tenant_id = self._get_tenant_id_for_create(context, ipsec_sitecon)
with context.session.begin(subtransactions=True):
# I guess this would actually call the child class method to
# get the driver?
driver = self._get_driver_for_ipsec_site_connection(
context, ipsec_sitecon)
driver.validate_create_ipsec_site_connection(context, ipsec_sitecon)

The database method is a base class of the VPN plugin class, so I’m thinking, 
although awkward, it could work. Can’t say I’m comfortable with the call flow 
here.  Probably could add an abstract method for 
_get_driver_for_ipsec_site_connection(), so that it cannot be called with an 
instance of the database class.

I’m not seeing a really clean solution here.

Any thoughts?

PCM (Paul Michali)

MAIL …..…. p...@cisco.com
IRC ……..… pcm_ (irc.freenode.com)
TW ………... @pmichali
GPG Key … 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83

On May 27, 2014, at 7:37 AM, Paul Michali (pcm)  wrote:

> Thanks for the comments Mandeep!  Responses in-line #PCM
> 
> On May 23, 2014, at 8:57 PM, Mandeep Dhami  wrote:
> 
>> My preferences:
>> 
>> For where, I'd go with Gary's recommendation (A) for two reasons (1) 
>> Consistency and (2) I don't think it will create any boilerplate 
>> requirements since the abstract class provides the default implementation.
> 
> #PCM Actually, (A) requires a lot of additional code that doesn’t currently 
> exist today. ABC methods would be needed for each validation. In addition, to 
> be consistent, there should be an abstract method for the apply function, and 
> a “pass” implementation on each of the concrete classes. Overall, it is 
> adding a lot of code, for arguably little benefit.
> 
> 
>> 
>> For naming, I'd prefer to go with ML2 terminology for two reasons (1) Again 
>> Consistency, and (2) it is then clear what actions are happening within a 
>> transaction or outside of it. With a "validation function" no "transaction 
>> fence" is implied by it's name - but for any validation that depends on what 
>> currently exists in the database, these transaction semantics are important.
> 
> #PCM I’m still struggling with the naming for question #2.  I must admit, I 
> like the naming of validate/apply becaus

[openstack-dev] [Murano] repository murano-api renamed to murano

2014-05-27 Thread Ruslan Kamaldinov

Just a heads up:
Repository stackforge/murano-api was renamed to stackforge/murano on
May 23. All the commit and review history is preserved and can be
viewed under the new name [1], [2].

We also renamed [3]:
* internal package name from muranoapi to murano
* config file names under etc/murano

Now, our devstack/tempest job is green again. As it was agreed on the
meeting today we're going to mark it as voting in one week from now.


[1] https://git.openstack.org/cgit/stackforge/murano
[2] https://review.openstack.org/#/q/project:stackforge/murano,n,z
[3] https://blueprints.launchpad.net/murano/+spec/rename-murano-api-to-murano

--
Ruslan

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

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Scott Devoid

Also I would prefer that we not add "special" tenant names. Roles already
had/has problems with "admin", "Member" and "_member_" having special
meaning in some projects.

~ Scott


On Tue, May 27, 2014 at 1:20 PM, Vishvananda Ishaya
wrote:

> Are you aware that there is already a way to do this through the cli using
> quota-class-update?
>
> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html(near 
> the bottom)
>
> Are you suggesting that we also add the ability to use just regular
> quota-update? I’m not sure i see the need for both.
>
> Vish
>
> On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J <
> sergio.j.cazzol...@intel.com> wrote:
>
> > I would to hear your thoughts about an idea to add a way to manage the
> default quota values through the API.
> >
> > The idea is to use the current quota api, but sending ''default' instead
> of the tenant_id. This change would apply to quota-show and quota-update
> methods.
> >
> > This approach will help to simplify the implementation of another
> blueprint named per-flavor-quotas
> >
> > Feedback? Suggestions?
> >
> >
> > Sergio Juan Cazzolato
> > Intel Software Argentina
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] SR-IOV nova-specs

2014-05-27 Thread Robert Li (baoli)

Hi John,

Now that we have agreement during the summit on how to proceed in order to get 
it in to Juno, please take a look at this:

https://review.openstack.org/#/c/86606/16

Please let us know your comments or what is still missing. I’m also not sure if 
your  –2 needs to be removed before the other cores will take a look at it.

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

Re: [openstack-dev] [nova] nova default quotas

2014-05-27 Thread Vishvananda Ishaya

Are you aware that there is already a way to do this through the cli using 
quota-class-update?

http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html (near 
the bottom)

Are you suggesting that we also add the ability to use just regular 
quota-update? I’m not sure i see the need for both.

Vish

On May 20, 2014, at 9:52 AM, Cazzolato, Sergio J  
wrote:

> I would to hear your thoughts about an idea to add a way to manage the 
> default quota values through the API. 
> 
> The idea is to use the current quota api, but sending ''default' instead of 
> the tenant_id. This change would apply to quota-show and quota-update methods.
> 
> This approach will help to simplify the implementation of another blueprint 
> named per-flavor-quotas
> 
> Feedback? Suggestions?
> 
> 
> Sergio Juan Cazzolato
> Intel Software Argentina 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-27 Thread Carlos Gonçalves

Hi,

On 27 May 2014, at 15:55, Mohammad Banikazemi  wrote:

> GP like any other Neutron extension can have different implementations. Our 
> idea has been to have the GP code organized similar to how ML2 and mechanism 
> drivers are organized, with the possibility of having different drivers for 
> realizing the GP API. One such driver (analogous to an ML2 mechanism driver I 
> would say) is the mapping driver that was implemented for the PoC. I 
> certainly do not see it as the only implementation. The mapping driver is 
> just the driver we used for our PoC implementation in order to gain 
> experience in developing such a driver. Hope this clarifies things a bit.

The code organisation adopted to implement the PoC for the GP is indeed very 
similar to the one ML2 is using. There is one aspect I think GP will hit soon 
if it continues to follow with its current code base where multiple (policy) 
drivers will be available, and as Mohammad putted it as being analogous to an 
ML2 mech driver, but are independent from ML2’s. I’m unaware, however, if the 
following problem has already been brought to discussion or not.

From here I see the GP effort going, besides from some code refactoring, I'd 
say expanding the supported policy drivers is the next goal. With that ODL 
support might next. Now, administrators enabling GP ODL support will have to 
configure ODL data twice (host, user, password) in case they’re using ODL as a 
ML2 mech driver too, because policy drivers share no information between ML2 
ones. This can become more troublesome if ML2 is configured to load multiple 
mech drivers.

With that said, if it makes any sense, a different implementation should be 
considered. One that somehow allows mech drivers living in ML2 umbrella to be 
extended; BP [1] [2] may be a first step towards that end, I’m guessing.

Thanks,
Carlos Gonçalves

[1] 
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
[2] https://review.openstack.org/#/c/89208/

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

[openstack-dev] [Containers][Nova] Top Themes for OpenStack Containers Team

2014-05-27 Thread Adrian Otto

Team,

Today the OpenStack Containers Team[1] held our weekly IRC meeting, and reached 
consensus among a few areas of initial focus. They are:

1) Container support in OpenStack, with minimum code duplication
2) Drive agreement on where containers belong
3) API support for using features from Containers that are not offered by 
virtual machines.

The above are recorded in the team wiki page[2]. If you take an interest in 
supporting containers in OpenStack, and would like to offer your input on where 
the Containers Team should focus, or express your concerns we welcome you to 
join the Containers Team, and attend our sub-team meetings[3] on our 
alternating schedule of 1600 UTC and 2200 UTC on Tuesdays. We also welcome your 
feedback on this thread to confirm that we are focusing on the areas that will 
result in the biggest positive outcome on the OpenStack community.

Thanks,

Adrian

References:
[1] https://wiki.openstack.org/wiki/Teams/Containers
[2] https://wiki.openstack.org/wiki/Teams/Containers#Top_Themes
[3] https://wiki.openstack.org/wiki/Meetings/Containers
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Anita Kuno

On 05/27/2014 01:03 PM, trinath.soman...@freescale.com wrote:
> Hi-
> 
> 
> Thanks a lot Salvatore.
> 
> 
> I'm looking into that issue. I'm troubleshooting the same.
> 
> 
> Will update this mail chain when its accessible for review.
> 
> 
> Thanks a lot for the review Salvatore.
> 
> 
> --
> 
> Trinath
Have you considered starting an irc client, navigating to freenode and
joining the #openstack-dev and #openstack-neutron channels? It would
increase the rate at which you learn how to amend your code to get it
merged. It also would help as you troubleshoot your CI system.

Give it some thought,
Anita.
> 
> 
> 
> From: Salvatore Orlando 
> Sent: Tuesday, May 27, 2014 10:29 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
> 
> Too late.
> 
> I just approved the specification.
> I don't think there is any need for reverting the blueprint and just updating 
> the topic in the patch.
> 
> Please have a look at Freescale CI - logs are not accessible at the moment.
> 
> Salvatore
> 
> 
> On 27 May 2014 18:51, 
> trinath.soman...@freescale.com 
> mailto:trinath.soman...@freescale.com>> wrote:
> Hi-
> 
> Sure!. Will change the topic and update you.
> 
> Thanks a lot for the reply and review.
> 
> Your review helps me a lot to proceed further with code.
> 
> Thanking you ..
> 
> -
> Trinath Somanchi
> 
> From: Edgar Magana Perdomo (eperdomo) 
> mailto:eperd...@cisco.com>>
> Sent: Tuesday, May 27, 2014 10:18 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
> 
> My only comment is that the name of the topic should be:
> 
> bp/fsl-sdn-os-mech-driver
> 
> 
> Instead of:
> bp/https
> 
> 
> I guss we can pass this..
> 
> Edgar
> 
> On 5/27/14, 9:23 AM, 
> "trinath.soman...@freescale.com"
> mailto:trinath.soman...@freescale.com>> wrote:
> 
>> Hi Kyle
>>
>> Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>> for Juno1.
>>
>> I have been mailing the reviewer to kindly make some to to review the BP
>> spec.
>>
>> I have code too in place for review along with working CI.
>>
>> The Code for review : https://review.openstack.org/#/c/78092/
>>
>> Kindly please do the needful.
>>
>> --
>> Trinath Somanchi.
>>
>> 
>> From: Kyle Mestery 
>> mailto:mest...@noironetworks.com>>
>> Sent: Tuesday, May 27, 2014 7:44 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [neutron] BPs for Juno-1
>>
>> Hi Neutron developers:
>>
>> I've spent some time cleaning up the BPs for Juno-1, and they are
>> documented at the link below [1]. There are a large number of BPs
>> currently under review right now in neutron-specs. If we land some of
>> those specs this week, it's possible some of these could make it into
>> Juno-1, pending review cycles and such. But I just wanted to highlight
>> that I removed a large number of BPs from targeting Juno-1 now which
>> did not have specifications linked to them nor specifications which
>> were actively under review in neutron-specs.
>>
>> Also, a gentle reminder that the process for submitting specifications
>> to Neutron is documented here [2].
>>
>> Thanks, and please reach out to me if you have any questions!
>>
>> Kyle
>>
>> [1] https://launchpad.net/neutron/+milestone/juno-1
>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

Re: [openstack-dev] [neutron] BPs for Juno-1

On Tue, May 27, 2014 at 12:12 PM, Vinay Yadhav  wrote:
> Hi,
>
> I have been working on the port mirroring blueprint and i was asked to
> submit a neutron spec related to this
> I have drafter the spec and ready to commit it to the
> 'git://git.openstack.org/openstack/neutron-specs' repository for
> review. Since the blueprint for this was old i was asked to submit the spec
> for review. should i also bring the old blueprint to life
> by linking it the spec that i will commit.
>
You can file a BP in launchpad. We're using those to track progress
against milestones for release management reasons. Please see the
instructions here [1]. Once the BP is filed in neutron-specs, reviewed
and approved, we can track it to milestones. But at this point, this
won't make it to Juno-1, given that's 2 weeks away.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Blueprints#Neutron

> We are calling the new spec Tap-as-a-Service
>
> Cheers,
>
> main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}
>
>
> On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery 
> wrote:
>>
>> Hi Neutron developers:
>>
>> I've spent some time cleaning up the BPs for Juno-1, and they are
>> documented at the link below [1]. There are a large number of BPs
>> currently under review right now in neutron-specs. If we land some of
>> those specs this week, it's possible some of these could make it into
>> Juno-1, pending review cycles and such. But I just wanted to highlight
>> that I removed a large number of BPs from targeting Juno-1 now which
>> did not have specifications linked to them nor specifications which
>> were actively under review in neutron-specs.
>>
>> Also, a gentle reminder that the process for submitting specifications
>> to Neutron is documented here [2].
>>
>> Thanks, and please reach out to me if you have any questions!
>>
>> Kyle
>>
>> [1] https://launchpad.net/neutron/+milestone/juno-1
>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Vinay Yadhav

Hi,

I have been working on the port mirroring blueprint and i was asked to
submit a neutron spec related to this
I have drafter the spec and ready to commit it to the '
git://git.openstack.org/openstack/neutron-specs' repository for
review. Since the blueprint for this was old i was asked to submit the spec
for review. should i also bring the old blueprint to life
by linking it the spec that i will commit.

We are calling the new spec Tap-as-a-Service

Cheers,

main(i){putchar((5852758>>((i-1)/2)*8)-!(1&i)*'\r')^89&&main(++i);}


On Tue, May 27, 2014 at 4:14 PM, Kyle Mestery wrote:

> Hi Neutron developers:
>
> I've spent some time cleaning up the BPs for Juno-1, and they are
> documented at the link below [1]. There are a large number of BPs
> currently under review right now in neutron-specs. If we land some of
> those specs this week, it's possible some of these could make it into
> Juno-1, pending review cycles and such. But I just wanted to highlight
> that I removed a large number of BPs from targeting Juno-1 now which
> did not have specifications linked to them nor specifications which
> were actively under review in neutron-specs.
>
> Also, a gentle reminder that the process for submitting specifications
> to Neutron is documented here [2].
>
> Thanks, and please reach out to me if you have any questions!
>
> Kyle
>
> [1] https://launchpad.net/neutron/+milestone/juno-1
> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

On Tue, May 27, 2014 at 12:01 PM, Nader Lahouti  wrote:
> Hi Kyle,
>
 ... But I just wanted to highlight
>
 that I removed a large number of BPs from targeting Juno-1 now which
 did not have specifications linked to them...
>
> Will those BP be reviewed after updating the link to the specification?
>
The BPs will be reviewed per normal, but Juno-1 is 2 weeks out now, so
realistically given review cycles, it's unlikely additional things
(unless small) will land in Juno-1.

Thanks,
Kyle

>
> Thanks,
> Nader.
>
>
>
>
>
> On Tue, May 27, 2014 at 7:14 AM, Kyle Mestery 
> wrote:
>>
>> Hi Neutron developers:
>>
>> I've spent some time cleaning up the BPs for Juno-1, and they are
>> documented at the link below [1]. There are a large number of BPs
>> currently under review right now in neutron-specs. If we land some of
>> those specs this week, it's possible some of these could make it into
>> Juno-1, pending review cycles and such. But I just wanted to highlight
>> that I removed a large number of BPs from targeting Juno-1 now which
>> did not have specifications linked to them nor specifications which
>> were actively under review in neutron-specs.
>>
>> Also, a gentle reminder that the process for submitting specifications
>> to Neutron is documented here [2].
>>
>> Thanks, and please reach out to me if you have any questions!
>>
>> Kyle
>>
>> [1] https://launchpad.net/neutron/+milestone/juno-1
>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Salvatore Orlando

Too late.

I just approved the specification.
I don't think there is any need for reverting the blueprint and just
updating the topic in the patch.

Please have a look at Freescale CI - logs are not accessible at the moment.

Salvatore


On 27 May 2014 18:51, trinath.soman...@freescale.com <
trinath.soman...@freescale.com> wrote:

> Hi-
>
> Sure!. Will change the topic and update you.
>
> Thanks a lot for the reply and review.
>
> Your review helps me a lot to proceed further with code.
>
> Thanking you ..
>
> -
> Trinath Somanchi
> 
> From: Edgar Magana Perdomo (eperdomo) 
> Sent: Tuesday, May 27, 2014 10:18 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron] BPs for Juno-1
>
> My only comment is that the name of the topic should be:
>
> bp/fsl-sdn-os-mech-driver
>
>
> Instead of:
> bp/https
>
>
> I guss we can pass this..
>
> Edgar
>
> On 5/27/14, 9:23 AM, "trinath.soman...@freescale.com"
>  wrote:
>
> >Hi Kyle
> >
> >Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
> >for Juno1.
> >
> >I have been mailing the reviewer to kindly make some to to review the BP
> >spec.
> >
> >I have code too in place for review along with working CI.
> >
> >The Code for review : https://review.openstack.org/#/c/78092/
> >
> >Kindly please do the needful.
> >
> >--
> >Trinath Somanchi.
> >
> >
> >From: Kyle Mestery 
> >Sent: Tuesday, May 27, 2014 7:44 PM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: [openstack-dev] [neutron] BPs for Juno-1
> >
> >Hi Neutron developers:
> >
> >I've spent some time cleaning up the BPs for Juno-1, and they are
> >documented at the link below [1]. There are a large number of BPs
> >currently under review right now in neutron-specs. If we land some of
> >those specs this week, it's possible some of these could make it into
> >Juno-1, pending review cycles and such. But I just wanted to highlight
> >that I removed a large number of BPs from targeting Juno-1 now which
> >did not have specifications linked to them nor specifications which
> >were actively under review in neutron-specs.
> >
> >Also, a gentle reminder that the process for submitting specifications
> >to Neutron is documented here [2].
> >
> >Thanks, and please reach out to me if you have any questions!
> >
> >Kyle
> >
> >[1] https://launchpad.net/neutron/+milestone/juno-1
> >[2] https://wiki.openstack.org/wiki/Blueprints#Neutron
> >
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

Hi-


Thanks a lot Salvatore.


I'm looking into that issue. I'm troubleshooting the same.


Will update this mail chain when its accessible for review.


Thanks a lot for the review Salvatore.


--

Trinath



From: Salvatore Orlando 
Sent: Tuesday, May 27, 2014 10:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

Too late.

I just approved the specification.
I don't think there is any need for reverting the blueprint and just updating 
the topic in the patch.

Please have a look at Freescale CI - logs are not accessible at the moment.

Salvatore


On 27 May 2014 18:51, 
trinath.soman...@freescale.com 
mailto:trinath.soman...@freescale.com>> wrote:
Hi-

Sure!. Will change the topic and update you.

Thanks a lot for the reply and review.

Your review helps me a lot to proceed further with code.

Thanking you ..

-
Trinath Somanchi

From: Edgar Magana Perdomo (eperdomo) 
mailto:eperd...@cisco.com>>
Sent: Tuesday, May 27, 2014 10:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

My only comment is that the name of the topic should be:

bp/fsl-sdn-os-mech-driver


Instead of:
bp/https


I guss we can pass this..

Edgar

On 5/27/14, 9:23 AM, 
"trinath.soman...@freescale.com"
mailto:trinath.soman...@freescale.com>> wrote:

>Hi Kyle
>
>Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>for Juno1.
>
>I have been mailing the reviewer to kindly make some to to review the BP
>spec.
>
>I have code too in place for review along with working CI.
>
>The Code for review : https://review.openstack.org/#/c/78092/
>
>Kindly please do the needful.
>
>--
>Trinath Somanchi.
>
>
>From: Kyle Mestery 
>mailto:mest...@noironetworks.com>>
>Sent: Tuesday, May 27, 2014 7:44 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: [openstack-dev] [neutron] BPs for Juno-1
>
>Hi Neutron developers:
>
>I've spent some time cleaning up the BPs for Juno-1, and they are
>documented at the link below [1]. There are a large number of BPs
>currently under review right now in neutron-specs. If we land some of
>those specs this week, it's possible some of these could make it into
>Juno-1, pending review cycles and such. But I just wanted to highlight
>that I removed a large number of BPs from targeting Juno-1 now which
>did not have specifications linked to them nor specifications which
>were actively under review in neutron-specs.
>
>Also, a gentle reminder that the process for submitting specifications
>to Neutron is documented here [2].
>
>Thanks, and please reach out to me if you have any questions!
>
>Kyle
>
>[1] https://launchpad.net/neutron/+milestone/juno-1
>[2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Nader Lahouti

Hi Kyle,

>>> ... But I just wanted to highlight
>>> that I removed a large number of BPs from targeting Juno-1 now which
>>> did not have specifications linked to them...

Will those BP be reviewed after updating the link to the specification?


Thanks,
Nader.





On Tue, May 27, 2014 at 7:14 AM, Kyle Mestery wrote:

> Hi Neutron developers:
>
> I've spent some time cleaning up the BPs for Juno-1, and they are
> documented at the link below [1]. There are a large number of BPs
> currently under review right now in neutron-specs. If we land some of
> those specs this week, it's possible some of these could make it into
> Juno-1, pending review cycles and such. But I just wanted to highlight
> that I removed a large number of BPs from targeting Juno-1 now which
> did not have specifications linked to them nor specifications which
> were actively under review in neutron-specs.
>
> Also, a gentle reminder that the process for submitting specifications
> to Neutron is documented here [2].
>
> Thanks, and please reach out to me if you have any questions!
>
> Kyle
>
> [1] https://launchpad.net/neutron/+milestone/juno-1
> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] BPs for Juno-1

Hi-

Sure!. Will change the topic and update you.

Thanks a lot for the reply and review.

Your review helps me a lot to proceed further with code.

Thanking you ..

-
Trinath Somanchi

From: Edgar Magana Perdomo (eperdomo) 
Sent: Tuesday, May 27, 2014 10:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] BPs for Juno-1

My only comment is that the name of the topic should be:

bp/fsl-sdn-os-mech-driver


Instead of:
bp/https


I guss we can pass this..

Edgar

On 5/27/14, 9:23 AM, "trinath.soman...@freescale.com"
 wrote:

>Hi Kyle
>
>Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>for Juno1.
>
>I have been mailing the reviewer to kindly make some to to review the BP
>spec.
>
>I have code too in place for review along with working CI.
>
>The Code for review : https://review.openstack.org/#/c/78092/
>
>Kindly please do the needful.
>
>--
>Trinath Somanchi.
>
>
>From: Kyle Mestery 
>Sent: Tuesday, May 27, 2014 7:44 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: [openstack-dev] [neutron] BPs for Juno-1
>
>Hi Neutron developers:
>
>I've spent some time cleaning up the BPs for Juno-1, and they are
>documented at the link below [1]. There are a large number of BPs
>currently under review right now in neutron-specs. If we land some of
>those specs this week, it's possible some of these could make it into
>Juno-1, pending review cycles and such. But I just wanted to highlight
>that I removed a large number of BPs from targeting Juno-1 now which
>did not have specifications linked to them nor specifications which
>were actively under review in neutron-specs.
>
>Also, a gentle reminder that the process for submitting specifications
>to Neutron is documented here [2].
>
>Thanks, and please reach out to me if you have any questions!
>
>Kyle
>
>[1] https://launchpad.net/neutron/+milestone/juno-1
>[2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

Re: [openstack-dev] [neutron] BPs for Juno-1

2014-05-27 Thread Edgar Magana Perdomo (eperdomo)

My only comment is that the name of the topic should be:

bp/fsl-sdn-os-mech-driver


Instead of:
bp/https


I guss we can pass this..

Edgar

On 5/27/14, 9:23 AM, "trinath.soman...@freescale.com"
 wrote:

>Hi Kyle
>
>Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too
>for Juno1.
>
>I have been mailing the reviewer to kindly make some to to review the BP
>spec.
>
>I have code too in place for review along with working CI.
>
>The Code for review : https://review.openstack.org/#/c/78092/
>
>Kindly please do the needful.
>
>--
>Trinath Somanchi.
>
>
>From: Kyle Mestery 
>Sent: Tuesday, May 27, 2014 7:44 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: [openstack-dev] [neutron] BPs for Juno-1
>
>Hi Neutron developers:
>
>I've spent some time cleaning up the BPs for Juno-1, and they are
>documented at the link below [1]. There are a large number of BPs
>currently under review right now in neutron-specs. If we land some of
>those specs this week, it's possible some of these could make it into
>Juno-1, pending review cycles and such. But I just wanted to highlight
>that I removed a large number of BPs from targeting Juno-1 now which
>did not have specifications linked to them nor specifications which
>were actively under review in neutron-specs.
>
>Also, a gentle reminder that the process for submitting specifications
>to Neutron is documented here [2].
>
>Thanks, and please reach out to me if you have any questions!
>
>Kyle
>
>[1] https://launchpad.net/neutron/+milestone/juno-1
>[2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [Neutron][IPv6] Minutes from May 27 2014

2014-05-27 Thread Collins, Sean

http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.html

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

Re: [openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs

2014-05-27 Thread Collins, Sean

I'm going to bump this thread based on some of the discussions we had
today during the IRC meeting.

I also added a comment to a review on the tempest side after our
discussion (I made some adjustments to my comment for context and
clarification)

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

>> The only time that the gateway will be specified
>> in advance for a V6 subnet is if you are using an external device or
>> something not orchestrated by OpenStack.
>>
>> We discussed this today, in the meeting, at 14:24:09
>>
>> http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-05-27-14.01.log.html
>>
>> Basically, if you are going to create a router in Neutron for a v6
>> subnet, we plan on having the router attachment step populate the
>> gateway attribute of the subnet, since we will be wiring it up and
>> will have a LLA for the router.

For now, we are not addressing the problem of multiple routers attached to
different subnets - since we need to do some research on that.

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

Re: [openstack-dev] [MagnetoDB] Bulk load API draft

2014-05-27 Thread Dmitriy Ukhlov

Hi Illia,

Looks good. But I suggest to return all of these fields for positive
request as well as for error request:

"read": "string",
"processed": "string",
"failed": "string",

but leave next fields optional and fill them in case of error response
("failed" > 0) to specify what exactly was happened:

"last_read":
"errors" (maybe not processed will be better)



On Tue, May 27, 2014 at 3:39 PM, Illia Khudoshyn wrote:

> Hi openstackers,
>
> While working on bulk load, I found previously proposed batch-oriented
> asynchronous approach both resource consuming on server side and somewhat
> complicated to use.
> So I tried to outline some more straightforward streaming way of uploading
> data.
>
> By the link below you can found a draft for a new streaming API
> https://wiki.openstack.org/wiki/MagnetoDB/streamingbulkload.
>
> Any feedback is welcome as usual.
>
>
>
> On Wed, May 14, 2014 at 5:04 PM, Illia Khudoshyn 
> wrote:
>
>> Hi openstackers,
>>
>> I'm working on bulk load for MagnetoDB, the facility for inserting large
>> amounts of data, like,  millions of rows, gigabytes of data. Below is the
>> link to draft API description.
>>
>>
>> https://wiki.openstack.org/wiki/MagnetoDB/bulkload#.5BDraft.5D_MagnetoDB_Bulk_Load_workflow_and_API
>>
>> Any feedback is welcome.
>>
>> --
>>
>> Best regards,
>>
>> Illia Khudoshyn,
>> Software Engineer, Mirantis, Inc.
>>
>>
>>
>> 38, Lenina ave. Kharkov, Ukraine
>>
>> www.mirantis.com 
>>
>> www.mirantis.ru
>>
>>
>>
>> Skype: gluke_work
>>
>> ikhudos...@mirantis.com
>>
>
>
>
> --
>
> Best regards,
>
> Illia Khudoshyn,
> Software Engineer, Mirantis, Inc.
>
>
>
> 38, Lenina ave. Kharkov, Ukraine
>
> www.mirantis.com 
>
> www.mirantis.ru
>
>
>
> Skype: gluke_work
>
> ikhudos...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Dmitriy Ukhlov
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-05-27 Thread Armando M.

Hi Mohammad,

Thanks, I understand now. I appreciate that the mapping driver is one way
of doing things and that the design has been familiarized for a while. I
wish I could follow infinite channels but unfortunately the openstack
information overload is astounding and sometimes I fail :) Gerrit is the
channel I strive to follow and this is when I saw the code for the first
time, hence my feedback.

It's worth noting that the PoC design document is (as it should be) very
high level and most of my feedback applies to the implementation decisions
being made. That said, I still have doubts that an ML2 like approach is
really necessary for GP and I welcome inputs to help me change my mind :)

Thanks
Armando
On May 27, 2014 5:04 PM, "Mohammad Banikazemi"  wrote:

> Thanks for the continued interest in discussing Group Policy (GP). I
> believe these discussions with the larger Neutron community can benefit the
> GP work.
>
> GP like any other Neutron extension can have different implementations.
> Our idea has been to have the GP code organized similar to how ML2 and
> mechanism drivers are organized, with the possibility of having different
> drivers for realizing the GP API. One such driver (analogous to an ML2
> mechanism driver I would say) is the mapping driver that was implemented
> for the PoC. I certainly do not see it as the only implementation. The
> mapping driver is just the driver we used for our PoC implementation in
> order to gain experience in developing such a driver. Hope this clarifies
> things a bit.
>
> Please note that for better or worse we have produced several documents
> during the previous cycle. We have tried to collect them on the GP wiki
> page [1]. The latest design document [2] should give a broad view of the GP
> extension and the model being proposed. The PoC document [3] may clarify
> our PoC plans and where the mapping driver stands wrt other pieces of the
> work.  (Please note some parts of the plan as described in the PoC document
> was not implemented.)
>
> Hope my explanation and these documents (and other documents available on
> the GP wiki) are helpful.
>
> Best,
>
> Mohammad
>
> [1] https://wiki.openstack.org/wiki/Neutron/GroupPolicy   <- GP wiki
> page
> [2]
> https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/
><- GP design document
> [3]
> https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/
><- GP PoC document
>
>
> [image: Inactive hide details for "Armando M." ---05/26/2014 09:46:34
> PM---On May 26, 2014 4:27 PM, "Mohammad Banikazemi"  M." ---05/26/2014 09:46:34 PM---On May 26, 2014 4:27 PM, "Mohammad
> Banikazemi"  wrote: >
>
> From: "Armando M." 
> To: "OpenStack Development Mailing List, (not for usage questions)" <
> openstack-dev@lists.openstack.org>,
> Date: 05/26/2014 09:46 PM
> Subject: Re: [openstack-dev] [neutron][group-based-policy] GP mapping
> driver
> --
>
>
>
>
> On May 26, 2014 4:27 PM, "Mohammad Banikazemi" 
> <*m...@us.ibm.com*>
> wrote:
> >
> > Armando,
> >
> > I think there are a couple of things that are being mixed up here, at
> least as I see this conversation :). The mapping driver is simply one way
> of implementing GP. Ideally I would say, you do not need to implement the
> GP in terms of other Neutron abstractions even though you may choose to do
> so. A network controller could realize the connectivities and policies
> defined by GP independent of say networks, and subnets. If we agree on this
> point, then how we organize the code will be different than the case where
> GP is always defined as something on top of current neutron API. In other
> words, we shouldn't organize the overall code for GP based solely on the
> use of the mapping driver.
>
> The mapping driver is embedded in the policy framework that Bob had
> initially proposed. If I understood what you're suggesting correctly, it
> makes very little sense to diverge or come up with a different framework
> alongside the legacy driver later on, otherwise we may end up in the same
> state of the core plugins': monolithic vs ml2-based. Could you clarify?
> >
> > In the mapping driver (aka the legacy driver) for the PoC, GP is
> implemented in terms of other Neutron abstractions. I agree that using
> python-neutronclient for the PoC would be fine and as Bob has mentioned it
> would have been probably the best/easiest way of having the PoC implemented
> in the first place. The calls to python-neutronclient in my understanding
> could be eventually easily replaced with direct calls after refactoring
> which lead me to ask a question concerning the following part of the
> conversation (being copied here again):
>
> Not sure why we keep bringing this refactoring up: my point is that if GP
> were to be implemented the way I'm suggesting the refactoring would have no
> impact on GP...even if it did, replacing remote with direct calls should be
> avoided IMO.
>
> >
> >
> > [Bob:

Re: [openstack-dev] [neutron] BPs for Juno-1

On Tue, May 27, 2014 at 11:23 AM, trinath.soman...@freescale.com
 wrote:
> Hi Kyle
>
> Kindly consider my BP spec (https://review.openstack.org/#/c/88190/)  too for 
> Juno1.
>
> I have been mailing the reviewer to kindly make some to to review the BP spec.
>
> I have code too in place for review along with working CI.
>
> The Code for review : https://review.openstack.org/#/c/78092/
>
If this BP gets approved this week yet, I'll add it into Juno-1
Trinaths. Please work with some Neutron cores to get a second +2 on
this one today/tomorrow.

Thanks!
Kyle

> Kindly please do the needful.
>
> --
> Trinath Somanchi.
>
> 
> From: Kyle Mestery 
> Sent: Tuesday, May 27, 2014 7:44 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron] BPs for Juno-1
>
> Hi Neutron developers:
>
> I've spent some time cleaning up the BPs for Juno-1, and they are
> documented at the link below [1]. There are a large number of BPs
> currently under review right now in neutron-specs. If we land some of
> those specs this week, it's possible some of these could make it into
> Juno-1, pending review cycles and such. But I just wanted to highlight
> that I removed a large number of BPs from targeting Juno-1 now which
> did not have specifications linked to them nor specifications which
> were actively under review in neutron-specs.
>
> Also, a gentle reminder that the process for submitting specifications
> to Neutron is documented here [2].
>
> Thanks, and please reach out to me if you have any questions!
>
> Kyle
>
> [1] https://launchpad.net/neutron/+milestone/juno-1
> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] BPs for Juno-1