[openstack-dev] OpenStack-dev Digest, Vol 26, Issue 50
Israel Ziv
israel.ziv at huawei.com
Tue Jun 17 09:20:10 UTC 2014
Hi Salvatore!
Thanks for your prompt reply.
Can you recommend which approach should we take to enforce inter-tenant security rules?
Also, can you recommend of resources to which we can relate?
Thanks again
Israel
-----Original Message-----
From: openstack-dev-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org]
Sent: Monday, June 16, 2014 10:41 AM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 26, Issue 50
Send OpenStack-dev mailing list submissions to
openstack-dev at lists.openstack.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
openstack-dev-request at lists.openstack.org
You can reach the person managing the list at
openstack-dev-owner at lists.openstack.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."
Today's Topics:
1. Re: [Nova] Nominating Ken'ichi Ohmichi for nova-core (Alex Xu)
2. [Neutron] [FWaaS] [sequritygroup] [Development] (Israel Ziv)
3. Re: [Nova][neutron][NFV] Mid cycle sprints (Gary Kotton)
4. Re: [Nova][neutron][NFV] Mid cycle sprints (Dmitry)
5. Re: [Neutron][Swift][third-party] Most Third Party CI's
failing (Monty Taylor)
6. [Nova] VMware ESX Driver Deprecation (Gary Kotton)
7. Re: [Neutron] [FWaaS] [sequritygroup] [Development]
(Salvatore Orlando)
8. Re: [heat] How to avoid property revalidation? (Clint Byrum)
9. Re: [nova] Distributed locking (Clint Byrum)
10. [Neutron] Starting contributing to project (S?awek Kap?o?ski)
11. Re: [Neutron] Starting contributing to project (Clint Byrum)
12. Re: [Neutron] Implementing new LBaaS API (Salvatore Orlando)
13. Re: [Neutron] REST API - entity level validation
(Salvatore Orlando)
14. Re: [heat] How to avoid property revalidation? (Steve Baker)
15. Re: [Neutron] Implementing new LBaaS API (Brandon Logan)
16. Re: [Neutron][ml2] Tracking the reviews for ML2 related specs
(Mohammad Banikazemi)
17. Re: [TripleO] Reviews - we need your help! (James Polley)
18. [Fuel] Bug squashing day on June, 17 (Mike Scherbakov)
19. Re: [Nova] Nominating Ken'ichi Ohmichi for nova-core (wu jiang)
20. Re: [Nova] Nominating Ken'ichi Ohmichi for nova-core (Dan Prince)
21. How to assign dynamic property to a Data Object via VMware
SDK (Feng Xi Yan)
22. ??: [Nova] Nominating Ken'ichi Ohmichi for nova-core
(Huangtianhua)
23. Re: [Nova] Nominating Ken'ichi Ohmichi for nova-core
(INOUE TOMOKO)
24. Nova-compute stucking at spawning (abhishek jain)
25. Re: [neutron] [third-party] Current status of Neutron 3rd
Party CI and how to move forward (YAMAMOTO Takashi)
26. Re: [nova] Distributed locking (Angus Lees)
27. no tap interface on compute node (abhishek jain)
28. Re: [Neutron] Implementing new LBaaS API (Eugene Nikanorov)
29. Re: [nova] Distributed locking (Jay Pipes)
----------------------------------------------------------------------
Message: 1
Date: Sun, 15 Jun 2014 20:44:36 +0800
From: Alex Xu <xuhj at linux.vnet.ibm.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for
nova-core
Message-ID: <539D9534.4050407 at linux.vnet.ibm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
+1
On 2014?06?14? 06:40, Michael Still wrote:
> Greetings,
>
> I would like to nominate Ken'ichi Ohmichi for the nova-core team.
>
> Ken'ichi has been involved with nova for a long time now. His reviews
> on API changes are excellent, and he's been part of the team that has
> driven the new API work we've seen in recent cycles forward. Ken'ichi
> has also been reviewing other parts of the code base, and I think his
> reviews are detailed and helpful.
>
> Please respond with +1s or any concerns.
>
> References:
>
> https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:open,n,z
>
> https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z
>
> http://www.stackalytics.com/?module=nova-group&user_id=oomichi
>
> As a reminder, we use the voting process outlined at
> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
> core team.
>
> Thanks,
> Michael
>
------------------------------
Message: 2
Date: Sun, 15 Jun 2014 12:55:24 +0000
From: Israel Ziv <israel.ziv at huawei.com>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Neutron] [FWaaS] [sequritygroup]
[Development]
Message-ID:
<904319C41211F347A8AAAEA08219FCBB219D4C9D at szxeml558-mbx.china.huawei.com>
Content-Type: text/plain; charset="us-ascii"
Hi!
Please let me know if I've reached the proper group.
I am going through neutron's code and have a few questions.
1. I understood that
a. 'securitygroups' enables intra-subnet "firewall" and is aimed to allow/deny traffic between tenants.
b. 'FWaaS' enables inter-subnet "firewall" and is aimed to allow/deny traffic within tenant.
c. Did I understand correctly?
2. Does a securitygroup rule generation have effect on the perimeter firewall of the cloud?
Regards
Israel Ziv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/4cd25740/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 15 Jun 2014 13:27:09 +0000
From: Gary Kotton <gkotton at vmware.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints
Message-ID: <CFC379B3.E772%gkotton at vmware.com>
Content-Type: text/plain; charset="iso-8859-1"
On 6/14/14, 1:05 AM, "Anita Kuno" <anteaya at anteaya.info> wrote:
>On 06/13/2014 05:58 PM, Carlos Gon?alves wrote:
>> Let me add to what I've said in my previous email, that Instituto de
>>Telecomunicacoes and Portugal Telecom are also available to host and
>>organize a mid cycle sprint in Lisbon, Portugal.
>>
>> Please let me know who may be interested in participating.
>>
>> Thanks,
>> Carlos Goncalves
>>
>> On 13 Jun 2014, at 10:45, Carlos Gon?alves <mail at cgoncalves.pt> wrote:
>>
>>> Hi,
>>>
>>> I like the idea of arranging a mid cycle for Neutron in Europe
>>>somewhere in July. I was also considering inviting folks from the
>>>OpenStack NFV team to meet up for a F2F kick-off.
>>>
>>> I did not know about the sprint being hosted and organised by eNovance
>>>in Paris until just now. I think it is a great initiative from eNovance
>>>even because it?s not being focused on a specific OpenStack project.
>>>So, I'm interested in participating in this sprint for discussing
>>>Neutron and NFV. Two more people from Instituto de Telecomunicacoes and
>>>Portugal Telecom have shown interested too.
>>>
>>> Neutron and NFV team members, who?s interested in meeting in Paris, or
>>>if not available on the date set by eNovance in other time and place?
>>>
>>> Thanks,
>>> Carlos Goncalves
>>>
>>> On 13 Jun 2014, at 08:42, Sylvain Bauza <sbauza at redhat.com> wrote:
>>>
>>>> Le 12/06/2014 15:32, Gary Kotton a ?crit :
>>>>> Hi,
>>>>> There is the mid cycle sprint in July for Nova and Neutron. Anyone
>>>>>interested in maybe getting one together in Europe/Middle East around
>>>>>the same dates? If people are willing to come to this part of the
>>>>>world I am sure that we can organize a venue for a few days. Anyone
>>>>>interested. If we can get a quorum then I will be happy to try and
>>>>>arrange things.
>>>>> Thanks
>>>>> Gary
>>>>>
>>>>
>>>>
>>>> Hi Gary,
>>>>
>>>> Wouldn't it be more interesting to have a mid-cycle sprint *before*
>>>>the Nova one (which is targeted after juno-2) so that we could discuss
>>>>on some topics and make a status to other folks so that it would allow
>>>>a second run ?
>>>>
>>>> There is already a proposal in Paris for hosting some OpenStack
>>>>sprints, see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
>>>>
>>>> -Sylvain
>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>Neutron already has two sprints scheduled:
>https://wiki.openstack.org/wiki/Sprints
Those sprints are both in the US. It is a very long way to travel. If
there are a group of people that can get together in Europe then it would
be great.
>
>Thanks,
>Anita.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 4
Date: Sun, 15 Jun 2014 16:40:43 +0300
From: Dmitry <meytin at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova][neutron][NFV] Mid cycle sprints
Message-ID:
<CAHmcpO2XOTFWiKyqo7uUQ_K8Ey+eYO9KYca3CKNfG7=RR7f-XQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
+1 for Paris/Lisbon
On Sun, Jun 15, 2014 at 4:27 PM, Gary Kotton <gkotton at vmware.com> wrote:
>
>
> On 6/14/14, 1:05 AM, "Anita Kuno" <anteaya at anteaya.info> wrote:
>
>>On 06/13/2014 05:58 PM, Carlos Gon?alves wrote:
>>> Let me add to what I've said in my previous email, that Instituto de
>>>Telecomunicacoes and Portugal Telecom are also available to host and
>>>organize a mid cycle sprint in Lisbon, Portugal.
>>>
>>> Please let me know who may be interested in participating.
>>>
>>> Thanks,
>>> Carlos Goncalves
>>>
>>> On 13 Jun 2014, at 10:45, Carlos Gon?alves <mail at cgoncalves.pt> wrote:
>>>
>>>> Hi,
>>>>
>>>> I like the idea of arranging a mid cycle for Neutron in Europe
>>>>somewhere in July. I was also considering inviting folks from the
>>>>OpenStack NFV team to meet up for a F2F kick-off.
>>>>
>>>> I did not know about the sprint being hosted and organised by eNovance
>>>>in Paris until just now. I think it is a great initiative from eNovance
>>>>even because it?s not being focused on a specific OpenStack project.
>>>>So, I'm interested in participating in this sprint for discussing
>>>>Neutron and NFV. Two more people from Instituto de Telecomunicacoes and
>>>>Portugal Telecom have shown interested too.
>>>>
>>>> Neutron and NFV team members, who?s interested in meeting in Paris, or
>>>>if not available on the date set by eNovance in other time and place?
>>>>
>>>> Thanks,
>>>> Carlos Goncalves
>>>>
>>>> On 13 Jun 2014, at 08:42, Sylvain Bauza <sbauza at redhat.com> wrote:
>>>>
>>>>> Le 12/06/2014 15:32, Gary Kotton a ?crit :
>>>>>> Hi,
>>>>>> There is the mid cycle sprint in July for Nova and Neutron. Anyone
>>>>>>interested in maybe getting one together in Europe/Middle East around
>>>>>>the same dates? If people are willing to come to this part of the
>>>>>>world I am sure that we can organize a venue for a few days. Anyone
>>>>>>interested. If we can get a quorum then I will be happy to try and
>>>>>>arrange things.
>>>>>> Thanks
>>>>>> Gary
>>>>>>
>>>>>
>>>>>
>>>>> Hi Gary,
>>>>>
>>>>> Wouldn't it be more interesting to have a mid-cycle sprint *before*
>>>>>the Nova one (which is targeted after juno-2) so that we could discuss
>>>>>on some topics and make a status to other folks so that it would allow
>>>>>a second run ?
>>>>>
>>>>> There is already a proposal in Paris for hosting some OpenStack
>>>>>sprints, see https://wiki.openstack.org/wiki/Sprints/ParisJuno2014
>>>>>
>>>>> -Sylvain
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>Neutron already has two sprints scheduled:
>>https://wiki.openstack.org/wiki/Sprints
>
> Those sprints are both in the US. It is a very long way to travel. If
> there are a group of people that can get together in Europe then it would
> be great.
>
>>
>>Thanks,
>>Anita.
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 5
Date: Sun, 15 Jun 2014 07:50:41 -0700
From: Monty Taylor <mordred at inaugust.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][Swift][third-party] Most Third
Party CI's failing
Message-ID: <539DB2C1.5030100 at inaugust.com>
Content-Type: text/plain; charset=ISO-8859-1
On 06/14/2014 09:39 PM, Sukhdev Kapur wrote:
> Oppss...sorry wrong link... please use this
> http://paste.openstack.org/show/84073/.
>
>
> If anybody needs help, please ping me or go to #openstack-infra.
>
The relevant patch has been merged into upstream setuptools and a new
setuptools release, 5.0.2 has been cut.
>
> On Sat, Jun 14, 2014 at 9:34 PM, Sukhdev Kapur <sukhdevkapur at gmail.com>
> wrote:
>
>> Fellow Stackers,
>>
>> I have an update on the issue.
>> Kudos to the Infra folks, a huge thanks to Monty for coming up with patch
>> for this setuptools issue, and Anita for for being on top of this. Please
>> follow the steps in http://paste.openstack.org/show/84076/ to pull this
>> patch on your local systems to get past the issue - until the fix in the
>> upstream is merged.
>>
>> Note that you have to install mercurial to pull this patch.
>>
>> Hope this helps.
>>
>> regards..
>> -Sukhdev
>>
>>
>>
>>
>> On Sat, Jun 14, 2014 at 5:45 PM, Sukhdev Kapur <sukhdevkapur at gmail.com>
>> wrote:
>>
>>> I noticed this afternoon (Saturday PST 1:18pm) that most of the Third
>>> Party test systems started to fail because of the seuptools bug because of
>>> dependency in python-swiftclient. I further noticed that some of the CI's
>>> are voting +1, but, when I look through the logs, they seem to be hitting
>>> this issue as well.
>>>
>>> I have been on #openstack-infra most of the afternoon discussing various
>>> options suggested by folks. Infra folks have confirmed this issue and are
>>> looking for solution. I tried fixes suggested in [1] and [2] below and
>>> removed the setuptools and reinstalled version 3.8. This did not help. I
>>> have opened the bug[3] to track this issue.
>>>
>>> I thought I send out this message in case other CI maintainers are
>>> investigating this issue.
>>>
>>> Please share ideas/thoughts so that we can get the CIs fixed as soon as
>>> possible.
>>>
>>> Thanks
>>> -Sukhdev
>>>
>>>
>>> [1] https://bugs.launchpad.net/python-swiftclient/+bug/1326972
>>> [2] https://mail.python.org/pipermail/distutils-sig/2014-June/024478.html
>>> [3] https://bugs.launchpad.net/python-swiftclient/+bug/1330140
>>>
>>
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
------------------------------
Message: 6
Date: Sun, 15 Jun 2014 15:15:34 +0000
From: Gary Kotton <gkotton at vmware.com>
To: OpenStack List <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Nova] VMware ESX Driver Deprecation
Message-ID: <CFC35BDE.E699%gkotton at vmware.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
In the Icehouse cycle it was decided to deprecate the VMware ESX driver. The motivation for the decision was:
* The driver is not validated by Minesweeper
* It is not clear if there are actually any users of the driver
Prior to jumping into the proposal we should take into account that the current ESX driver does not work with the following branches:
* Master (Juno)
* Icehouse
* Havana
The above are due to VC features that were added over the course of these cycles.
On the VC side the ESX can be added to a cluster and the running VM's will continue to run. The problem is how that are tracked and maintained in the Nova DB.
Option 1: Moving the ESX(s) into a nova managed cluster. This would require the nova DB entry for the instance running on the ESX to be updated to be running on the VC host. If the VC host restarts at point during the above then all of the running instances may be deleted (this is due to the fact that _destroy_evacuated_instances is invoked when a nova compute is started https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L673). This would be disastrous for a running deployment.
If we do decide to go for the above option we can perform a cold migration of the instances from the ESX hosts to the VC hosts. The fact that the same instance will be running on the ESX would require us to have a 'noop' for the migration. This can be done by configuration variables but that will be messy. This option would require code changes.
Option 2: Provide the administrator with tools that will enable a migration of the running VM's.
1. A script that will import OpenStack VM's into the database - the script will detect VM's running on a VC and import them to the database.
2. A scrip that will delete VM's running on a specific host
The admin will use these as follows:
1. Invoke the deletion script for the ESX
2. Add the ESX to a VC
3. Invoke the script for importing the OpenStack VM's into the database
4. Start the nova compute with the VC driver
5. Terminate all Nova computes with the ESX driver
This option requires the addition of the scripts. The advantage is that it does not touch any of the running code and is done out of band. A variant of option 2 would be to have a script that updates the host for the ESX VM's to the VC host.
Due to the fact that the code is not being run at the moment I am in favor of the external scripts as it will be less disruptive and not be on a critical path. Any thoughts or comments?
Thanks
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/da359728/attachment-0001.html>
------------------------------
Message: 7
Date: Sun, 15 Jun 2014 18:25:23 +0200
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] [FWaaS] [sequritygroup]
[Development]
Message-ID:
<CAGR=i3h0VuC3n8Eo9xh4A33Z7sknhv98PR1p_+Dq+DMk1AsrFw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Israel,
please find my answers inline.
I'm not really an expert in this area, but I hope these answers are
helpful, and, hopefully, correct!
Salvatore
On 15 June 2014 14:55, Israel Ziv <israel.ziv at huawei.com> wrote:
> Hi!
>
> Please let me know if I?ve reached the proper group.
>
> I am going through neutron?s code and have a few questions.
>
>
>
> 1. I understood that
>
> a. ?securitygroups? enables intra-subnet ?firewall? and is aimed to
> allow/deny traffic between tenants.
>
This is kind of correct. However, rather than "intra-subnet" I would say
that the firewall rules are enforced at the port level - and they're
obviously not just for allowing or deny traffic among tenants, as they
allow to express a wide variety of rules.
Another thing to note is that security group rules' action always is ALLOW
- and they're enforced on a baseline default DENY ALL policy
> b. ?FWaaS? enables inter-subnet ?firewall? and is aimed to
> allow/deny traffic within tenant.
>
This is correct too, but as before I would point out that the real
difference is that these rules are enforced at the router level. Also the
nature of the rule is different as the associated actions can be either
ALLOW or DENY.
> c. Did I understand correctly?
>
> 2. Does a securitygroup rule generation have effect on the
> perimeter firewall of the cloud?
>
> If by perimeter you mean the 'edge' of cloud, ie: where your router's
gateway ports are plugged, then I would say no. However, I don't remember
whether security group rules are enforced on external networks as well; and
also I'm not sure security groups are the right abstraction in that case.
>
>
> Regards
>
> Israel Ziv
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/30ee1a50/attachment-0001.html>
------------------------------
Message: 8
Date: Sun, 15 Jun 2014 11:26:05 -0700
From: Clint Byrum <clint at fewbar.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [heat] How to avoid property
revalidation?
Message-ID: <1402855754-sup-431 at fewbar.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Steven Hardy's message of 2014-06-15 02:40:14 -0700:
> Hi all,
>
> So, I stumbled accross an issue while fixing up some tests, which is that
> AFAICS since Icehouse we continually revalidate every property every time
> they are accessed:
>
> https://github.com/openstack/heat/blob/stable/havana/heat/engine/properties.py#L716
>
> This means that, for example, we revalidate every property every time an
> event is created:
>
> https://github.com/openstack/heat/blob/stable/havana/heat/engine/event.py#L44
>
> And obviously also every time the property is accessed in the code
> implementing whatever action we're handling, and potentially also before
> the action (e.g the explicit validate before create/update).
>
> This repeated revalidation seems like it could get very expensive - for
> example there are several resources (Instance/Server resources in
> particular) which validate against glance via a custom constraint, so we're
> probably doing at least 6 calls to glance validating the image every
> create. My suspicion is this is one of the reasons for the performance
> regression observed in bug #1324102.
>
> I've been experimenting with some code which implements local caching of
> the validated properties, but according to the tests this introduces some
> problems where the cached value doesn't always match what is expected,
> still investigating why but I guess it's updates where we need to
> re-resolve what is cached during the update.
>
> Does anyone (and in particular Zane and Thomas who I know have deep
> experience in this area) have any ideas on what strategy we might employ to
> reduce this revalidation overhead?
tl;dr: I think we should only validate structure in validate, and leave
runtime validation to preview.
I've been wondering about what we want to achieve with validation
recently. It seems to me that the goal is to assist template authors
in finding obvious issues in structure and content before they cause a
runtime failure. But the error messages are so unhelpful we basically
get this:
http://cdn.memegenerator.net/instances/500x/50964597.jpg
What holds us back from improving that is the complexity of doing
runtime validation.
To me, runtime is more of a 'preview' problem than a validate problem. A
template that validates once should continue to validate on any version
that supports the template format. But a preview will actually want to
measure runtime things and use parameters, and thus is where runtime
concerns belong.
I wonder if we could move validation out of any runtime context, and
remove any attempts to validate runtime things like image names/ids and
such. That would allow us to remove any but pre-action validation calls.
------------------------------
Message: 9
Date: Sun, 15 Jun 2014 11:33:05 -0700
From: Clint Byrum <clint at fewbar.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] Distributed locking
Message-ID: <1402857034-sup-7967 at fewbar.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from Matthew Booth's message of 2014-06-13 01:40:30 -0700:
> On 12/06/14 21:38, Joshua Harlow wrote:
> > So just a few thoughts before going to far down this path,
> >
> > Can we make sure we really really understand the use-case where we think
> > this is needed. I think it's fine that this use-case exists, but I just
> > want to make it very clear to others why its needed and why distributing
> > locking is the only *correct* way.
>
> An example use of this would be side-loading an image from another
> node's image cache rather than fetching it from glance, which would have
> very significant performance benefits in the VMware driver, and possibly
> other places. The copier must take a read lock on the image to prevent
> the owner from ageing it during the copy. Holding a read lock would also
> assure the copier that the image it is copying is complete.
Really? Usually in the unix-inspired world we just open a file and it
stays around until we close it.
------------------------------
Message: 10
Date: Sun, 15 Jun 2014 22:10:56 +0200
From: S?awek Kap?o?ski <slawek at kaplonski.pl>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Neutron] Starting contributing to project
Message-ID: <20140615221056.06b079d0 at laptop>
Content-Type: text/plain; charset=US-ASCII
Hello,
I want to start contributing to neutron project. I found bug which I
want to try fix: https://bugs.launchpad.net/neutron/+bug/1204956 and I
have question about "workflow" in such case. Should I clone neutron
reposiotory from branch master and do changes based on master branch or
maybe should I do my changes starting from any other branch? What
should I do next when I will for example do patch for such bug?
Thanks in advance for any help and explanation about that
--
Best regards
Slawek Kaplonski
slawek at kaplonski.pl
------------------------------
Message: 11
Date: Sun, 15 Jun 2014 14:14:49 -0700
From: Clint Byrum <clint at fewbar.com>
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Starting contributing to
project
Message-ID: <1402866865-sup-4982 at fewbar.com>
Content-Type: text/plain; charset=UTF-8
Excerpts from S?awek Kap?o?ski's message of 2014-06-15 13:10:56 -0700:
> Hello,
>
> I want to start contributing to neutron project. I found bug which I
> want to try fix: https://bugs.launchpad.net/neutron/+bug/1204956 and I
> have question about "workflow" in such case. Should I clone neutron
> reposiotory from branch master and do changes based on master branch or
> maybe should I do my changes starting from any other branch? What
> should I do next when I will for example do patch for such bug?
> Thanks in advance for any help and explanation about that
>
This should explain everything you need to know:
https://wiki.openstack.org/wiki/Gerrit_Workflow
------------------------------
Message: 12
Date: Sun, 15 Jun 2014 23:26:21 +0200
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Message-ID:
<CAGR=i3iBVg6rVyDhJTzhHDwDRYFKmWdc1WJoYPrD0=k8GBF_WA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Regarding the two approaches outlines in the top post, I found out that the
bullet "This is API versioning done the wrong way" appears in both
approaches.
Is this a mistake or intentional?
>From what I gather, the most reasonable approach appears to be starting
with a clean slate, which means having a new API living side by side with
the old one.
I think the naming collision issues should probably be solved using
distinct namespaces for the two API (the old one has /v2/lbaas as a URI
prefix I think, I have hardly any idea about what namespace the new one
should have)
Finally, about deprecation - I see it's been agreed to deprecate the
current API in Juno.
I think this is not the right way of doing things. The limits of the
current API are pretty much universally agreed; on the other hand, it is
generally not advisable to deprecate an old API in favour of the new one at
the first iteration such API is published. My preferred strategy would be
to introduce the new API as experimental in the Juno release, so that in
can be evaluated, apply any feedback and consider for promoting in K - and
contextually deprecate the old API.
As there is quite a radical change between the old and the new model,
keeping the old API indefinitely is a maintenance burden we probably can't
afford, and I would therefore propose complete removal one release cycle
after deprecation. Also - since it seems to me that there is also consensus
regarding having load balancing move away into a separate project so that
it would not be tied anymore to the networking program, the old API is
pretty much just dead weight.
Salvatore
On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com> wrote:
> I spoke to Mark McClain about this yesterday, I'll see if I can get
> him to join the LBaaS team meeting tomorrow so between he and I we can
> close on this with the LBaaS team.
>
> On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle <sleipnir012 at gmail.com>
> wrote:
> > Do we know who has an opinion? If so maybe we can reach out to them
> directly
> > and ask them to comment.
> >
> >
> > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan <
> brandon.logan at rackspace.com>
> > wrote:
> >>
> >> Well we got a few opinions, but not enough understanding of the two
> >> options to make an informed decision. It was requested that the core
> >> reviewers respond to this thread with their opinions.
> >>
> >> Thanks,
> >> Brandon
> >>
> >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:
> >> > Yep, I'd like to know here, too-- as knowing the answer to this
> >> > unblocks implementation work for us.
> >> >
> >> >
> >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan
> >> > <brandon.logan at rackspace.com> wrote:
> >> > Any core neutron people have a chance to give their opinions
> >> > on this
> >> > yet?
> >> >
> >> > Thanks,
> >> > Brandon
> >> >
> >> > On Thu, 2014-06-05 at 15:28 +0000, Buraschi, Andres wrote:
> >> > > Thanks, Kyle. Great.
> >> > >
> >> > > -----Original Message-----
> >> > > From: Kyle Mestery [mailto:mestery at noironetworks.com]
> >> > > Sent: Thursday, June 05, 2014 11:27 AM
> >> > > To: OpenStack Development Mailing List (not for usage
> >> > questions)
> >> > > Subject: Re: [openstack-dev] [Neutron] Implementing new
> >> > LBaaS API
> >> > >
> >> > > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan
> >> > <brandon.logan at rackspace.com> wrote:
> >> > > > Hi Andres,
> >> > > > I've assumed (and we know how assumptions work) that the
> >> > deprecation
> >> > > > would take place in Juno and after a cyle or two it would
> >> > totally be
> >> > > > removed from the code. Even if #1 is the way to go, the
> >> > old /vips
> >> > > > resource would be deprecated in favor of /loadbalancers
> >> > and /listeners.
> >> > > >
> >> > > > I agree #2 is cleaner, but I don't want to start on an
> >> > implementation
> >> > > > (though I kind of already have) that will fail to be
> >> > merged in because
> >> > > > of the strategy. The strategies are pretty different so
> >> > one needs to
> >> > > > be decided on.
> >> > > >
> >> > > > As for where LBaaS is intended to end up, I don't want to
> >> > speak for
> >> > > > Kyle, so this is my understanding; It will end up outside
> >> > of the
> >> > > > Neutron code base but Neutron and LBaaS and other services
> >> > will all
> >> > > > fall under a Networking (or Network) program. That is my
> >> > > > understanding and I could be totally wrong.
> >> > > >
> >> > > That's my understanding as well, I think Brandon worded it
> >> > perfectly.
> >> > >
> >> > > > Thanks,
> >> > > > Brandon
> >> > > >
> >> > > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi, Andres wrote:
> >> > > >> Hi Brandon, hi Kyle!
> >> > > >> I'm a bit confused about the deprecation (btw, thanks for
> >> > sending this Brandon!), as I (wrongly) assumed #1 would be the
> >> > chosen path for the new API implementation. I understand the
> >> > proposal and #2 sounds actually cleaner.
> >> > > >>
> >> > > >> Just out of curiosity, Kyle, where is LBaaS functionality
> >> > intended to end up, if long-term plans are to remove it from
> >> > Neutron?
> >> > > >>
> >> > > >> (Nit question, I must clarify)
> >> > > >>
> >> > > >> Thank you!
> >> > > >> Andres
> >> > > >>
> >> > > >> -----Original Message-----
> >> > > >> From: Brandon Logan [mailto:brandon.logan at RACKSPACE.COM]
> >> > > >> Sent: Wednesday, June 04, 2014 2:18 PM
> >> > > >> To: openstack-dev at lists.openstack.org
> >> > > >> Subject: Re: [openstack-dev] [Neutron] Implementing new
> >> > LBaaS API
> >> > > >>
> >> > > >> Thanks for your feedback Kyle. I will be at that meeting
> >> > on Monday.
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Brandon
> >> > > >>
> >> > > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle Mestery wrote:
> >> > > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon Logan
> >> > > >> > <brandon.logan at rackspace.com> wrote:
> >> > > >> > > This is an LBaaS topic bud I'd like to get some
> >> > Neutron Core
> >> > > >> > > members to give their opinions on this matter so I've
> >> > just
> >> > > >> > > directed this to Neutron proper.
> >> > > >> > >
> >> > > >> > > The design for the new API and object model for LBaaS
> >> > needs to be
> >> > > >> > > locked down before the hackathon in a couple of weeks
> >> > and there
> >> > > >> > > are some questions that need answered. This is
> >> > pretty urgent to
> >> > > >> > > come on to a decision on and to get a clear strategy
> >> > defined so
> >> > > >> > > we can actually do real code during the hackathon
> >> > instead of
> >> > > >> > > wasting some of that valuable time discussing this.
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > Implementation must be backwards compatible
> >> > > >> > >
> >> > > >> > > There are 2 ways that have come up on how to do this:
> >> > > >> > >
> >> > > >> > > 1) New API and object model are created in the same
> >> > extension and
> >> > > >> > > plugin as the old. Any API requests structured for
> >> > the old API
> >> > > >> > > will be translated/adapted to the into the new object
> >> > model.
> >> > > >> > > PROS:
> >> > > >> > > -Only one extension and plugin
> >> > > >> > > -Mostly true backwards compatibility -Do not have to
> >> > rename
> >> > > >> > > unchanged resources and models
> >> > > >> > > CONS:
> >> > > >> > > -May end up being confusing to an end-user.
> >> > > >> > > -Separation of old api and new api is less clear
> >> > -Deprecating and
> >> > > >> > > removing old api and object model will take a bit
> >> > more work -This
> >> > > >> > > is basically API versioning the wrong way
> >> > > >> > >
> >> > > >> > > 2) A new extension and plugin are created for the new
> >> > API and
> >> > > >> > > object model. Each API would live side by side. New
> >> > API would
> >> > > >> > > need to have different names for resources and object
> >> > models from
> >> > > >> > > Old API resources and object models.
> >> > > >> > > PROS:
> >> > > >> > > -Clean demarcation point between old and new -No
> >> > translation
> >> > > >> > > layer needed -Do not need to modify existing API and
> >> > object
> >> > > >> > > model, no new bugs -Drivers do not need to be
> >> > immediately
> >> > > >> > > modified -Easy to deprecate and remove old API and
> >> > object model
> >> > > >> > > later
> >> > > >> > > CONS:
> >> > > >> > > -Separate extensions and object model will be
> >> > confusing to
> >> > > >> > > end-users -Code reuse by copy paste since old
> >> > extension and
> >> > > >> > > plugin will be deprecated and removed.
> >> > > >> > > -This is basically API versioning the wrong way
> >> > > >> > >
> >> > > >> > > Now if #2 is chosen to be feasible and acceptable
> >> > then there are
> >> > > >> > > a number of ways to actually do that. I won't bring
> >> > those up
> >> > > >> > > until a clear decision is made on which strategy
> >> > above is the most acceptable.
> >> > > >> > >
> >> > > >> > Thanks for sending this out Brandon. I'm in favor of
> >> > option #2
> >> > > >> > above, especially considering the long-term plans to
> >> > remove LBaaS
> >> > > >> > from Neutron. That approach will help the eventual end
> >> > goal there.
> >> > > >> > I am also curious on what others think, and to this
> >> > end, I've added
> >> > > >> > this as an agenda item for the team meeting next
> >> > Monday. Brandon,
> >> > > >> > it would be great to get you there for the part of the
> >> > meeting
> >> > > >> > where we'll discuss this.
> >> > > >> >
> >> > > >> > Thanks!
> >> > > >> > Kyle
> >> > > >> >
> >> > > >> > > Thanks,
> >> > > >> > > Brandon
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > _______________________________________________
> >> > > >> > > OpenStack-dev mailing list
> >> > > >> > > OpenStack-dev at lists.openstack.org
> >> > > >> > >
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >> >
> >> > > >> > _______________________________________________
> >> > > >> > OpenStack-dev mailing list
> >> > > >> > OpenStack-dev at lists.openstack.org
> >> > > >> >
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >>
> >> > > >> _______________________________________________
> >> > > >> OpenStack-dev mailing list
> >> > > >> OpenStack-dev at lists.openstack.org
> >> > > >>
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >>
> >> > > >> _______________________________________________
> >> > > >> OpenStack-dev mailing list
> >> > > >> OpenStack-dev at lists.openstack.org
> >> > > >>
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >
> >> > > > _______________________________________________
> >> > > > OpenStack-dev mailing list
> >> > > > OpenStack-dev at lists.openstack.org
> >> > > >
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> > > _______________________________________________
> >> > > OpenStack-dev mailing list
> >> > > OpenStack-dev at lists.openstack.org
> >> > >
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> > > _______________________________________________
> >> > > OpenStack-dev mailing list
> >> > > OpenStack-dev at lists.openstack.org
> >> > >
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> >
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Stephen Balukoff
> >> > Blue Box Group, LLC
> >> > (800)613-4305 x807
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/a69cd7c0/attachment-0001.html>
------------------------------
Message: 13
Date: Sun, 15 Jun 2014 23:36:15 +0200
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] REST API - entity level
validation
Message-ID:
<CAGR=i3iPuTaAsOb_MJC+TnK+Eyz87nXT6hVF9wk0whiMU6=WCQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Avishay,
what you say here is correct.
However, as we are in the process of moving to Pecan as REST API framework
I would probably refrain from adding new features to it at this stage.
Therefore, even if far from ideal, this kind of validation should perhaps
be performed in the DB layer. I think this already happens for several API
resources.
Salvatore
On 5 June 2014 13:01, Avishay Balderman <AvishayB at radware.com> wrote:
> Hi
>
> With the current REST API engine in neutron we can declare attributes
> validations.
>
> We have a rich set of validation functions
> https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py
>
> However we do not have the concept of entity level validation.
>
>
>
> Example:
>
> I have an API ?create-something? and Something is an entity having 2
> attributes:
>
> Something {
>
> Attribute A
>
> Attribute B
>
> }
>
> And according to the business logic A must be greater than B
>
>
>
>
>
> As for today our framework cannot handle this kind of validation and the
> call is going inside a lower layer of neutron and must be validated there.
>
> Example: https://review.openstack.org/#/c/93871/9
>
>
>
> With this we have the validations implemented across multi layers. I think
> we better have the validations in one layer.
>
>
>
> Thanks
>
>
>
> Avishay
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/c9d7b5d2/attachment-0001.html>
------------------------------
Message: 14
Date: Mon, 16 Jun 2014 09:55:38 +1200
From: Steve Baker <sbaker at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [heat] How to avoid property
revalidation?
Message-ID: <539E165A.306 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
On 16/06/14 06:26, Clint Byrum wrote:
> Excerpts from Steven Hardy's message of 2014-06-15 02:40:14 -0700:
>> Hi all,
>>
>> So, I stumbled accross an issue while fixing up some tests, which is that
>> AFAICS since Icehouse we continually revalidate every property every time
>> they are accessed:
>>
>> https://github.com/openstack/heat/blob/stable/havana/heat/engine/properties.py#L716
>>
>> This means that, for example, we revalidate every property every time an
>> event is created:
>>
>> https://github.com/openstack/heat/blob/stable/havana/heat/engine/event.py#L44
>>
>> And obviously also every time the property is accessed in the code
>> implementing whatever action we're handling, and potentially also before
>> the action (e.g the explicit validate before create/update).
>>
>> This repeated revalidation seems like it could get very expensive - for
>> example there are several resources (Instance/Server resources in
>> particular) which validate against glance via a custom constraint, so we're
>> probably doing at least 6 calls to glance validating the image every
>> create. My suspicion is this is one of the reasons for the performance
>> regression observed in bug #1324102.
>>
>> I've been experimenting with some code which implements local caching of
>> the validated properties, but according to the tests this introduces some
>> problems where the cached value doesn't always match what is expected,
>> still investigating why but I guess it's updates where we need to
>> re-resolve what is cached during the update.
>>
>> Does anyone (and in particular Zane and Thomas who I know have deep
>> experience in this area) have any ideas on what strategy we might employ to
>> reduce this revalidation overhead?
> tl;dr: I think we should only validate structure in validate, and leave
> runtime validation to preview.
>
> I've been wondering about what we want to achieve with validation
> recently. It seems to me that the goal is to assist template authors
> in finding obvious issues in structure and content before they cause a
> runtime failure. But the error messages are so unhelpful we basically
> get this:
>
> http://cdn.memegenerator.net/instances/500x/50964597.jpg
>
> What holds us back from improving that is the complexity of doing
> runtime validation.
>
> To me, runtime is more of a 'preview' problem than a validate problem. A
> template that validates once should continue to validate on any version
> that supports the template format. But a preview will actually want to
> measure runtime things and use parameters, and thus is where runtime
> concerns belong.
>
> I wonder if we could move validation out of any runtime context, and
> remove any attempts to validate runtime things like image names/ids and
> such. That would allow us to remove any but pre-action validation calls.
>
Agreed, and parameter validation needs to be included in this too -
especially with custom constraints which can make API calls.
------------------------------
Message: 15
Date: Sun, 15 Jun 2014 22:23:18 +0000
From: Brandon Logan <brandon.logan at RACKSPACE.COM>
To: "openstack-dev at lists.openstack.org"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Message-ID: <1402870998.3179.17.camel at localhost>
Content-Type: text/plain; charset="utf-8"
Thank you Salvatore for your feedback.
Comments in-line.
On Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:
> Regarding the two approaches outlines in the top post, I found out
> that the bullet "This is API versioning done the wrong way" appears in
> both approaches.
> Is this a mistake or intentional?
No it was intentional. In my opinion they are both the wrong way. It
would be best to be able to do a version at the resource layer but we
can't since lbaas is a part of Neutron and its versions is directly tied
to Neutron's. Another possibility is to have the resource look like:
http(s)://neutron.endpoint/v2/lbaas/v2
This looks very odd to me though and sets a bad precedent. That is just
my opinion though. So I wouldn't call this the right way either. Thus,
I do not know of a "right" way to do this other than choosing the right
"alternative" way.
>
>
> From what I gather, the most reasonable approach appears to be
> starting with a clean slate, which means having a new API living side
> by side with the old one.
> I think the naming collision issues should probably be solved using
> distinct namespaces for the two API (the old one has /v2/lbaas as a
> URI prefix I think, I have hardly any idea about what namespace the
> new one should have)
>
I'm in agreement with you as well. The old one has /v2/lb as the prefix.
I figured the new one could be /v2/lbaas which I think works out well.
Another thing to consider that I did not think about in my original
message is that a whole new load balancing agent will have to be created
as well since its code is written with the pool being the root object.
So that should be taken into consideration. So to be perfectly clear,
starting with a clean slate would involve the following:
1. New loadbalancer extension
2. New loadbalancer plugin
3. New lbaas_agentscheduler extension
4. New agent_scheduler plugin.
Also, I don't believe doing this would allow the two to be deployed at
the same time. I believe the setup.cfg file would have to be modified
to point to the new plugins. I could be wrong about that though.
>
> Finally, about deprecation - I see it's been agreed to deprecate the
> current API in Juno.
> I think this is not the right way of doing things. The limits of the
> current API are pretty much universally agreed; on the other hand, it
> is generally not advisable to deprecate an old API in favour of the
> new one at the first iteration such API is published. My preferred
> strategy would be to introduce the new API as experimental in the Juno
> release, so that in can be evaluated, apply any feedback and consider
> for promoting in K - and contextually deprecate the old API.
>
>
> As there is quite a radical change between the old and the new model,
> keeping the old API indefinitely is a maintenance burden we probably
> can't afford, and I would therefore propose complete removal one
> release cycle after deprecation. Also - since it seems to me that
> there is also consensus regarding having load balancing move away into
> a separate project so that it would not be tied anymore to the
> networking program, the old API is pretty much just dead weight.
>
> Salvatore
Good idea on that. I'll bring this up with everyone at the hackathon
this week if it is not already on the table.
Thanks again for your feedback.
Brandon
>
>
> On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com> wrote:
> I spoke to Mark McClain about this yesterday, I'll see if I
> can get
> him to join the LBaaS team meeting tomorrow so between he and
> I we can
> close on this with the LBaaS team.
>
> On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle
> <sleipnir012 at gmail.com> wrote:
> > Do we know who has an opinion? If so maybe we can reach out
> to them directly
> > and ask them to comment.
> >
> >
> > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan
> <brandon.logan at rackspace.com>
> > wrote:
> >>
> >> Well we got a few opinions, but not enough understanding of
> the two
> >> options to make an informed decision. It was requested
> that the core
> >> reviewers respond to this thread with their opinions.
> >>
> >> Thanks,
> >> Brandon
> >>
> >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:
> >> > Yep, I'd like to know here, too-- as knowing the answer
> to this
> >> > unblocks implementation work for us.
> >> >
> >> >
> >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan
> >> > <brandon.logan at rackspace.com> wrote:
> >> > Any core neutron people have a chance to give
> their opinions
> >> > on this
> >> > yet?
> >> >
> >> > Thanks,
> >> > Brandon
> >> >
> >> > On Thu, 2014-06-05 at 15:28 +0000, Buraschi,
> Andres wrote:
> >> > > Thanks, Kyle. Great.
> >> > >
> >> > > -----Original Message-----
> >> > > From: Kyle Mestery
> [mailto:mestery at noironetworks.com]
> >> > > Sent: Thursday, June 05, 2014 11:27 AM
> >> > > To: OpenStack Development Mailing List (not for
> usage
> >> > questions)
> >> > > Subject: Re: [openstack-dev] [Neutron]
> Implementing new
> >> > LBaaS API
> >> > >
> >> > > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan
> >> > <brandon.logan at rackspace.com> wrote:
> >> > > > Hi Andres,
> >> > > > I've assumed (and we know how assumptions
> work) that the
> >> > deprecation
> >> > > > would take place in Juno and after a cyle or
> two it would
> >> > totally be
> >> > > > removed from the code. Even if #1 is the way
> to go, the
> >> > old /vips
> >> > > > resource would be deprecated in favor
> of /loadbalancers
> >> > and /listeners.
> >> > > >
> >> > > > I agree #2 is cleaner, but I don't want to
> start on an
> >> > implementation
> >> > > > (though I kind of already have) that will
> fail to be
> >> > merged in because
> >> > > > of the strategy. The strategies are pretty
> different so
> >> > one needs to
> >> > > > be decided on.
> >> > > >
> >> > > > As for where LBaaS is intended to end up, I
> don't want to
> >> > speak for
> >> > > > Kyle, so this is my understanding; It will
> end up outside
> >> > of the
> >> > > > Neutron code base but Neutron and LBaaS and
> other services
> >> > will all
> >> > > > fall under a Networking (or Network)
> program. That is my
> >> > > > understanding and I could be totally wrong.
> >> > > >
> >> > > That's my understanding as well, I think
> Brandon worded it
> >> > perfectly.
> >> > >
> >> > > > Thanks,
> >> > > > Brandon
> >> > > >
> >> > > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi,
> Andres wrote:
> >> > > >> Hi Brandon, hi Kyle!
> >> > > >> I'm a bit confused about the deprecation
> (btw, thanks for
> >> > sending this Brandon!), as I (wrongly) assumed #1
> would be the
> >> > chosen path for the new API implementation. I
> understand the
> >> > proposal and #2 sounds actually cleaner.
> >> > > >>
> >> > > >> Just out of curiosity, Kyle, where is LBaaS
> functionality
> >> > intended to end up, if long-term plans are to
> remove it from
> >> > Neutron?
> >> > > >>
> >> > > >> (Nit question, I must clarify)
> >> > > >>
> >> > > >> Thank you!
> >> > > >> Andres
> >> > > >>
> >> > > >> -----Original Message-----
> >> > > >> From: Brandon Logan
> [mailto:brandon.logan at RACKSPACE.COM]
> >> > > >> Sent: Wednesday, June 04, 2014 2:18 PM
> >> > > >> To: openstack-dev at lists.openstack.org
> >> > > >> Subject: Re: [openstack-dev] [Neutron]
> Implementing new
> >> > LBaaS API
> >> > > >>
> >> > > >> Thanks for your feedback Kyle. I will be at
> that meeting
> >> > on Monday.
> >> > > >>
> >> > > >> Thanks,
> >> > > >> Brandon
> >> > > >>
> >> > > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle
> Mestery wrote:
> >> > > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon
> Logan
> >> > > >> > <brandon.logan at rackspace.com> wrote:
> >> > > >> > > This is an LBaaS topic bud I'd like to
> get some
> >> > Neutron Core
> >> > > >> > > members to give their opinions on this
> matter so I've
> >> > just
> >> > > >> > > directed this to Neutron proper.
> >> > > >> > >
> >> > > >> > > The design for the new API and object
> model for LBaaS
> >> > needs to be
> >> > > >> > > locked down before the hackathon in a
> couple of weeks
> >> > and there
> >> > > >> > > are some questions that need answered.
> This is
> >> > pretty urgent to
> >> > > >> > > come on to a decision on and to get a
> clear strategy
> >> > defined so
> >> > > >> > > we can actually do real code during the
> hackathon
> >> > instead of
> >> > > >> > > wasting some of that valuable time
> discussing this.
> >> > > >> > >
> >> > > >> > >
> >> > > >> > > Implementation must be backwards
> compatible
> >> > > >> > >
> >> > > >> > > There are 2 ways that have come up on
> how to do this:
> >> > > >> > >
> >> > > >> > > 1) New API and object model are created
> in the same
> >> > extension and
> >> > > >> > > plugin as the old. Any API requests
> structured for
> >> > the old API
> >> > > >> > > will be translated/adapted to the into
> the new object
> >> > model.
> >> > > >> > > PROS:
> >> > > >> > > -Only one extension and plugin
> >> > > >> > > -Mostly true backwards compatibility -Do
> not have to
> >> > rename
> >> > > >> > > unchanged resources and models
> >> > > >> > > CONS:
> >> > > >> > > -May end up being confusing to an
> end-user.
> >> > > >> > > -Separation of old api and new api is
> less clear
> >> > -Deprecating and
> >> > > >> > > removing old api and object model will
> take a bit
> >> > more work -This
> >> > > >> > > is basically API versioning the wrong
> way
> >> > > >> > >
> >> > > >> > > 2) A new extension and plugin are
> created for the new
> >> > API and
> >> > > >> > > object model. Each API would live side
> by side. New
> >> > API would
> >> > > >> > > need to have different names for
> resources and object
> >> > models from
> >> > > >> > > Old API resources and object models.
> >> > > >> > > PROS:
> >> > > >> > > -Clean demarcation point between old and
> new -No
> >> > translation
> >> > > >> > > layer needed -Do not need to modify
> existing API and
> >> > object
> >> > > >> > > model, no new bugs -Drivers do not need
> to be
> >> > immediately
> >> > > >> > > modified -Easy to deprecate and remove
> old API and
> >> > object model
> >> > > >> > > later
> >> > > >> > > CONS:
> >> > > >> > > -Separate extensions and object model
> will be
> >> > confusing to
> >> > > >> > > end-users -Code reuse by copy paste
> since old
> >> > extension and
> >> > > >> > > plugin will be deprecated and removed.
> >> > > >> > > -This is basically API versioning the
> wrong way
> >> > > >> > >
> >> > > >> > > Now if #2 is chosen to be feasible and
> acceptable
> >> > then there are
> >> > > >> > > a number of ways to actually do that. I
> won't bring
> >> > those up
> >> > > >> > > until a clear decision is made on which
> strategy
> >> > above is the most acceptable.
> >> > > >> > >
> >> > > >> > Thanks for sending this out Brandon. I'm
> in favor of
> >> > option #2
> >> > > >> > above, especially considering the
> long-term plans to
> >> > remove LBaaS
> >> > > >> > from Neutron. That approach will help the
> eventual end
> >> > goal there.
> >> > > >> > I am also curious on what others think,
> and to this
> >> > end, I've added
> >> > > >> > this as an agenda item for the team
> meeting next
> >> > Monday. Brandon,
> >> > > >> > it would be great to get you there for the
> part of the
> >> > meeting
> >> > > >> > where we'll discuss this.
> >> > > >> >
> >> > > >> > Thanks!
> >> > > >> > Kyle
> >> > > >> >
> >> > > >> > > Thanks,
> >> > > >> > > Brandon
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> >> > > >> > >
> _______________________________________________
> >> > > >> > > OpenStack-dev mailing list
> >> > > >> > > OpenStack-dev at lists.openstack.org
> >> > > >> > >
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >> >
> >> > > >> >
> _______________________________________________
> >> > > >> > OpenStack-dev mailing list
> >> > > >> > OpenStack-dev at lists.openstack.org
> >> > > >> >
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >>
> >> > > >>
> _______________________________________________
> >> > > >> OpenStack-dev mailing list
> >> > > >> OpenStack-dev at lists.openstack.org
> >> > > >>
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >>
> >> > > >>
> _______________________________________________
> >> > > >> OpenStack-dev mailing list
> >> > > >> OpenStack-dev at lists.openstack.org
> >> > > >>
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > > >
> >> > > >
> _______________________________________________
> >> > > > OpenStack-dev mailing list
> >> > > > OpenStack-dev at lists.openstack.org
> >> > > >
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> > > _______________________________________________
> >> > > OpenStack-dev mailing list
> >> > > OpenStack-dev at lists.openstack.org
> >> > >
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> > >
> >> > > _______________________________________________
> >> > > OpenStack-dev mailing list
> >> > > OpenStack-dev at lists.openstack.org
> >> > >
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> >
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Stephen Balukoff
> >> > Blue Box Group, LLC
> >> > (800)613-4305 x807
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 16
Date: Sun, 15 Jun 2014 22:03:41 -0400
From: Mohammad Banikazemi <mb at us.ibm.com>
To: Irena Berezovsky <irenab at mellanox.com>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][ml2] Tracking the reviews for
ML2 related specs
Message-ID:
<OFBBE558A2.C28669B1-ON85257CF9.0008CEB0-85257CF9.000B529C at us.ibm.com>
Content-Type: text/plain; charset="us-ascii"
Hi Irena,
The "R" columns are for non-core subgroup reviews and the "C" columns are
for the core reviewers.
As of now, we only have specs listed/tracked in this wiki. Expanding the
wiki to include the code was briefly discussed last week. One option that
comes to mind is expanding the table for merged specs (the second table in
the wiki page) for tracking the reviews of the code. I have updated that
table and you and others can update the row for your specs and we can
discuss during the ML2 meeting and see if others see this as helpful. I
think considering the limited number of specs/code being tracked this may
be helpful as long as the code owners keep the table up to date.
Best,
Mohammad
From: Irena Berezovsky <irenab at mellanox.com>
To: Mohammad Banikazemi/Watson/IBM at IBMUS,
Cc: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: 06/15/2014 12:51 AM
Subject: RE: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2
related specs
Hi Mohammad,
Thank you for sharing the links.
Can you please elaborate on columns of the table in [1]. Is [R] supposed to
be for spec review and [C] for code review?
If this correct, would it be possible to add [C] columns for already merged
specs that still have the code under review?
Thanks a lot,
Irena
From: Mohammad Banikazemi [mailto:mb at us.ibm.com]
Sent: Friday, June 13, 2014 8:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2
related specs
In order to make the review process a bit easier (without duplicating too
much data and without creating too much overhead), we have created a wiki
to keep track of the ML2 related specs for the Juno cycle [1]. The idea is
to organize the people who participate in the ML2 subgroup activities and
get the related specs reviewed as much as possible in the subgroup before
asking the broader community to review. (There is of course nothing that
prevents others from reviewing these specs as soon as they are available
for review.) If you have any ML2 related spec under review or being
planned, you may want to update the wiki [1] accordingly.
We will see if this will be useful or not. If you have any comments or
suggestions please post here or bring them to the IRC weekly meetings [2].
Best,
Mohammad
[1] https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
[2] https://wiki.openstack.org/wiki/Meetings/ML2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/5c701534/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140615/5c701534/attachment-0001.gif>
------------------------------
Message: 17
Date: Mon, 16 Jun 2014 12:11:45 +1000
From: James Polley <jp at jamezpolley.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [TripleO] Reviews - we need your help!
Message-ID:
<CAPtRfUFFd-=U-9csdK1BL_tL7K49_1iqz1OdfOewLWw9ONHSVQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Tomas and Matthew
I've updated https://wiki.openstack.org/wiki/TripleO#Review_team to have a
link to the new dashboard.
On Fri, Jun 13, 2014 at 5:20 PM, Macdonald-Wallace, Matthew <
matthew.macdonald-wallace at hp.com> wrote:
> Thanks Tomas,
>
> http://bit.ly/1lsg3SH now contains the missing projects and has been
> re-ordered slightly so that you see outdated reviews first then the
> Jenkins/-1 stuff.
>
> Cheers,
>
> Matt
>
> > -----Original Message-----
> > From: Tomas Sedovic [mailto:tsedovic at redhat.com]
> > Sent: 12 June 2014 19:03
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [TripleO] Reviews - we need your help!
> >
> > On 12/06/14 16:02, Macdonald-Wallace, Matthew wrote:
> > > FWIW, I've tried to make a useful dashboard for this using Sean
> > > Dague's gerrit-dash-creator [0].
> > >
> > >
> > >
> > > Short URL is http://bit.ly/1l4DLFS long url is:
> > >
> > >
> > >
> > >
> > https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack
> > %2Ftripleo-incubator+OR+project%3Aopenstack%2Ftripleo-image-
> > elements+OR+project%3Aopenstack%2Ftripleo-heat-
> > templates+OR+project%3Aopenstack%2Ftripleo-
> > specs+OR+project%3Aopenstack%2Fos-apply-
> > config+OR+project%3Aopenstack%2Fos-collect-
> > config+OR+project%3Aopenstack%2Fos-refresh-
> > config+OR+project%3Aopenstack%2Fdiskimage-
> > builder%29+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-
> > 1+label%3AVerified%3E%3D1%252cjenkins+NOT+label%3ACode-
> > Review%3E%3D-
> > 2%252cself+branch%3Amaster+status%3Aopen&title=TripleO+Reviews&Your+a
> > re+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%
> > 3Aself&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode-
> > Review%3C%3D-
> > 1+limit%3A100&Changes+with+no+code+review+in+the+last+48hrs=NOT+label
> > %3ACode-
> > Review%3C%3D2+age%3A48h&Changes+with+no+code+review+in+the+last+5+
> > days=NOT+label%3ACode-
> > Review%3C%3D2+age%3A5d&Changes+with+no+code+review+in+the+last+7+d
> > ays=NOT+label%3ACode-Review%!
> > 3C%3D2+age
> > %3A7d&Some+adjustment+required+%28-1+only%29=label%3ACode-
> > Review%3D-1+NOT+label%3ACode-Review%3D-
> > 2+limit%3A100&Dead+Specs+%28-2%29=label%3ACode-Review%3C%3D-2
> > >
> > >
> > >
> > > I'll add it to my fork and submit a PR if people think it useful.
> >
> > I was about to mention this, too. The gerrit-dash-creator is fantastic.
> >
> > This one is missing the Tuskar-related projects (openstack/tuskar,
> > openstack/tuskar-ui and openstack/python-tuskarclient) and also
> openstack/os-
> > cloud-config, though.
> >
> >
> > >
> > >
> > >
> > > Matt
> > >
> > >
> > >
> > > [0] https://github.com/sdague/gerrit-dash-creator
> > >
> > >
> > >
> > > *From:*James Polley [mailto:jp at jamezpolley.com]
> > > *Sent:* 12 June 2014 06:08
> > > *To:* OpenStack Development Mailing List (not for usage questions)
> > > *Subject:* [openstack-dev] [TripleO] Reviews - we need your help!
> > >
> > >
> > >
> > > During yesterday's IRC meeting, we realized that our review stats are
> > > starting to slip again.
> > >
> > > Just after summit, our stats were starting to improve. In the
> > > 2014-05-20 meeting, the TripleO "Stats since the last revision
> > > without -1 or -2"[1] looked like this:
> > >
> > > 1rd quartile wait time: 1 days, 1 hours, 11 minutes
> > >
> > > Median wait time: 6 days, 9 hours, 49 minutes
> > >
> > > 3rd quartile wait time: 13 days, 5 hours, 46 minutes
> > >
> > >
> > >
> > > As of yesterdays meeting, we have:
> > >
> > > 1rd quartile wait time: 4 days, 23 hours, 19 minutes
> > >
> > > Median wait time: 7 days, 22 hours, 8 minutes
> > >
> > > 3rd quartile wait time: 13 days, 19 hours, 17 minutes
> > >
> > >
> > >
> > > This really hurts our velocity, and is especially hard on people
> > > making their first commit, as it can take them almost a full work week
> > > before they even get their first feedback.
> > >
> > > To get things moving, we need everyone to make a special effort to do
> > > a few reviews every day. It would be most helpful if you can look for
> > > older reviews without a -1 or -2 and help those reviews get over the
> line.
> > >
> > > If you find reviews that are just waiting for a simple fix - typo or
> > > syntax fixes, simple code fixes, or a simple rebase - it would be even
> > > more helpful if you could take a few minutes to make those patches,
> > > rather than just leaving the review waiting for the attention of the
> > > original submitter.
> > >
> > > Please keep in mind that these stats are based on all of our projects,
> > > not just tripleo-incubator. To save you heading to the wiki, here's a
> > > handy link that shows you all open code reviews in all our projects:
> > >
> > > bit.ly/1hQco1N <http://bit.ly/1hQco1N>
> > >
> > > If you'd prefer the long version:
> > > https://review.openstack.org/#/q/status:open+%28project:openstack/trip
> > > leo-incubator+OR+project:openstack/tuskar+OR+project:openstack/tuskar-
> > > ui+OR+project:openstack-infra/tripleo-ci+OR+project:openstack/os-apply
> > > -config+OR+project:openstack/os-collect-config+OR+project:openstack/os
> > > -refresh-config+OR+project:openstack/os-cloud-config+OR+project:openst
> > > ack/tripleo-image-elements+OR+project:openstack/tripleo-heat-templates
> > > +OR+project:openstack/diskimage-builder+OR+project:openstack/python-tu
> > > skarclient+OR+project:openstack/tripleo-specs%29,n,z
> > > <https://review.openstack.org/#/q/status:open+%28project:openstack/tri
> > > pleo-incubator+OR+project:openstack/tuskar+OR+project:openstack/tuskar
> > > -ui+OR+project:openstack-infra/tripleo-ci+OR+project:openstack/os-appl
> > > y-config+OR+project:openstack/os-collect-config+OR+project:openstack/o
> > > s-refr>
> > >
> > >
> > > https://wiki.openstack.org/wiki/TripleO#Bug_Triage has links to
> > > reviews for individual projects as well as more information about how
> > > we triage bugs.
> > >
> > > [1] http://www.nemebean.com/reviewstats/tripleo-open.html
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/07e2304b/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 16 Jun 2014 06:16:25 +0400
From: Mike Scherbakov <mscherbakov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Fuel] Bug squashing day on June, 17
Message-ID:
<CAKYN3rMGaTHXuf5trCMZ-OaQ7h4E_FHd-4dJNHoOURXBjYaBTA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Fuelers,
as we discussed during last IRC meeting
<http://eavesdrop.openstack.org/meetings/fuel/2014/fuel.2014-06-12-16.01.html>,
I'm scheduling bug squashing day on Tuesday, June 17th.
I'd like to propose the following order of bugs processing:
1. Confirm / triage bugs in New status
<https://bugs.launchpad.net/fuel/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search>,
assigning them to yourself to avoid the situation when a few people work on
same bug
2. Review bugs in Incomplete status
<https://bugs.launchpad.net/fuel/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search>,
move them to Confirmed / Triaged or close as Invalid.
3. Follow https://wiki.openstack.org/wiki/BugTriage for the rest (this
is MUST read for those who have not done it yet)
When we are more or less done with triaging, we can start proposing fixes
for bugs. I suggest to extensively use #fuel-dev IRC for synchronization,
and while someone fixes some bugs - the other one can participate in review
of fixes. Don't hesitate to ask for code reviews.
Regards,
--
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/54f02abb/attachment-0001.html>
------------------------------
Message: 19
Date: Mon, 16 Jun 2014 10:24:41 +0800
From: wu jiang <wingwj at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for
nova-core
Message-ID:
<CAEfJYtSW5x61jdd_gS+HD-Z5DgDqdVqugpH295LfkLekVThvyQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
+1. I got lots of helpful assistance from him. :)
On Sun, Jun 15, 2014 at 8:44 PM, Alex Xu <xuhj at linux.vnet.ibm.com> wrote:
> +1
>
>
> On 2014?06?14? 06:40, Michael Still wrote:
>
>> Greetings,
>>
>> I would like to nominate Ken'ichi Ohmichi for the nova-core team.
>>
>> Ken'ichi has been involved with nova for a long time now. His reviews
>> on API changes are excellent, and he's been part of the team that has
>> driven the new API work we've seen in recent cycles forward. Ken'ichi
>> has also been reviewing other parts of the code base, and I think his
>> reviews are detailed and helpful.
>>
>> Please respond with +1s or any concerns.
>>
>> References:
>>
>> https://review.openstack.org/#/q/owner:ken1ohmichi%
>> 2540gmail.com+status:open,n,z
>>
>> https://review.openstack.org/#/q/reviewer:ken1ohmichi%
>> 2540gmail.com,n,z
>>
>> http://www.stackalytics.com/?module=nova-group&user_id=oomichi
>>
>> As a reminder, we use the voting process outlined at
>> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
>> core team.
>>
>> Thanks,
>> Michael
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/17cf0c21/attachment-0001.html>
------------------------------
Message: 20
Date: Sun, 15 Jun 2014 22:32:19 -0400
From: Dan Prince <dprince at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for
nova-core
Message-ID: <1402885939.17042.0.camel at dovetail.localdomain>
Content-Type: text/plain; charset="UTF-8"
On Sat, 2014-06-14 at 08:40 +1000, Michael Still wrote:
> Greetings,
>
> I would like to nominate Ken'ichi Ohmichi for the nova-core team.
>
> Ken'ichi has been involved with nova for a long time now. His reviews
> on API changes are excellent, and he's been part of the team that has
> driven the new API work we've seen in recent cycles forward. Ken'ichi
> has also been reviewing other parts of the code base, and I think his
> reviews are detailed and helpful.
>
> Please respond with +1s or any concerns.
+1
>
> References:
>
> https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:open,n,z
>
> https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z
>
> http://www.stackalytics.com/?module=nova-group&user_id=oomichi
>
> As a reminder, we use the voting process outlined at
> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
> core team.
>
> Thanks,
> Michael
>
------------------------------
Message: 21
Date: Mon, 16 Jun 2014 11:48:27 +0800 (CST)
From: "Feng Xi Yan" <yfx_at_ibm at 163.com>
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] How to assign dynamic property to a Data
Object via VMware SDK
Message-ID: <494a07b1.be4e.146a2ca55af.Coremail.yfx_at_ibm at 163.com>
Content-Type: text/plain; charset="gbk"
Hi, Fellows,
Anyone familiar with VMWARE SDK?
I am now trying to cerate a network(or a dv port group) in vcenter via VMware SDK.
When I create a dvpg, I need to set vlan to config spec's defaultPortConfig(Type DO:DVPortSetting), but vlan is a dynamic property of DO:DVPortSetting.
I tried to directly assign a VmwareDistributedVirtualSwitchVlanIdSpec MOR to defaultPortConfig.vlan property, but the task failed with error:
"oslo.vmware.exceptions.VimException: Exception in CreateDVPortgroup_Task.
Cause: Type not found: 'vlan'"
I thought this is not the right way.
Anybody has any clues?
Here is sample code I tried:
client_factory = self._session.vim.client.factory
config_spec = client_factory.create('ns0:DVPortgroupConfigSpec')
port_config_spec = client_factory.create('ns0:DVPortSetting')
vlan_spec = client_factory.create('ns0:VmwareDistributedVirtualSwitchVlanIdSpec')
vlan_spec.vlanId = 100
vlan_spec.inherited = 'True'
port_config_spec.vlan = vlan_spec
config_spec.name = 'test_21'
config_spec.description = 'test'
config_spec.numPorts = '100'
config_spec.autoExpand = 'True'
config_spec.type = 'earlyBinding'
config_spec.defaultPortConfig = port_config_spec
dvs = vmware_util.get_dvs(self._session, CONF.VMWARE.dvswitch)
pg_create_task = self._session.invoke_api(self._session.vim,
"CreateDVPortgroup_Task",
dvs, spec=config_spec)
result = self._session.wait_for_task(pg_create_task)
dvpg = result.result
print(dvpg)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/5a6c0a61/attachment-0001.html>
------------------------------
Message: 22
Date: Mon, 16 Jun 2014 03:56:33 +0000
From: Huangtianhua <huangtianhua at huawei.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] ??: [Nova] Nominating Ken'ichi Ohmichi for
nova-core
Message-ID:
<E07566D89ECB9F43A509FE8A276ADDED3FFE65DF at SZXEMA510-MBX.china.huawei.com>
Content-Type: text/plain; charset="gb2312"
+1, congratulation:)
-----????-----
???: Michael Still [mailto:mikal at stillhq.com]
????: 2014?6?14? 6:41
???: OpenStack Development Mailing List
??: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for nova-core
Greetings,
I would like to nominate Ken'ichi Ohmichi for the nova-core team.
Ken'ichi has been involved with nova for a long time now. His reviews on API changes are excellent, and he's been part of the team that has driven the new API work we've seen in recent cycles forward. Ken'ichi has also been reviewing other parts of the code base, and I think his reviews are detailed and helpful.
Please respond with +1s or any concerns.
References:
https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:open,n,z
https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z
http://www.stackalytics.com/?module=nova-group&user_id=oomichi
As a reminder, we use the voting process outlined at https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our core team.
Thanks,
Michael
--
Rackspace Australia
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
------------------------------
Message: 23
Date: Mon, 16 Jun 2014 13:05:54 +0900
From: INOUE TOMOKO <inoue.tomoko at lab.ntt.co.jp>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Nova] Nominating Ken'ichi Ohmichi for
nova-core
Message-ID: <539E6D22.2080202 at lab.ntt.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
+1 !!! :-)
(2014/06/14 7:40), Michael Still wrote:
> Greetings,
>
> I would like to nominate Ken'ichi Ohmichi for the nova-core team.
>
> Ken'ichi has been involved with nova for a long time now. His reviews
> on API changes are excellent, and he's been part of the team that has
> driven the new API work we've seen in recent cycles forward. Ken'ichi
> has also been reviewing other parts of the code base, and I think his
> reviews are detailed and helpful.
>
> Please respond with +1s or any concerns.
>
> References:
>
> https://review.openstack.org/#/q/owner:ken1ohmichi%2540gmail.com+status:open,n,z
>
> https://review.openstack.org/#/q/reviewer:ken1ohmichi%2540gmail.com,n,z
>
> http://www.stackalytics.com/?module=nova-group&user_id=oomichi
>
> As a reminder, we use the voting process outlined at
> https://wiki.openstack.org/wiki/Nova/CoreTeam to add members to our
> core team.
>
> Thanks,
> Michael
>
--
Tomoko Inoue
NTT Software Innovation Center / NTT Secure Platform Laboratories
e-mail: inoue.tomoko at lab.ntt.co.jp
Telephone: +81 422 59 3496
3-9-11, Midori-Cho, Musashino-shi, Tokyo 180-8585, Japan
------------------------------
Message: 24
Date: Mon, 16 Jun 2014 10:30:58 +0530
From: abhishek jain <ashujain9727 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>, "Richard W.M. Jones"
<rjones at redhat.com>
Subject: [openstack-dev] Nova-compute stucking at spawning
Message-ID:
<CA+9-Lvu9YxmaH3qMwv17CCSau2XXjVRU2+XWBq9Qqx0GD48Lyg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I have installed openstack using devstack.I'm able to boot VM from
openstack cloud on the controller node.When I'm trying to boot VM on the
compute node,it is stucking at spawning state.The logs of the nova-compute
on the controller node is almost the same as that of of the nova-compute on
the compute node except one difference i.e the
', '/usr/bin/tee: /sys/class/net/tapd836ffc38-f2/brport/hairpin_mode: No
such file or directory\n')
2014-06-13 09:45:17.314 DEBUG nova.virt.libvirt.driver
[req-5abd5544-03a6-4046-99
267-65912a4ce477 admin admin] [instance:
46c68bd3-455b-4997-a9a0-8bd04de3da51] II
nstance is running spawn /opt/stack/nova/nova/virt/libvirt/driver.py:2092^M
It is not able to get any tap directry in /sys/class/net path.
Please help regarding this .
Thanks
Abhishek Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/1154ff03/attachment-0001.html>
------------------------------
Message: 25
Date: Mon, 16 Jun 2014 14:07:05 +0900 (JST)
From: yamamoto at valinux.co.jp (YAMAMOTO Takashi)
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [third-party] Current status of
Neutron 3rd Party CI and how to move forward
Message-ID: <20140616050705.820E371A12 at kuma.localdomain>
Content-Type: Text/Plain; charset=us-ascii
hi,
> My initial analysis of Neutron 3rd Party CI is here [1]. This was
> somewhat correlated with information from DriverLog [2], which was
> helpful to put this together.
i updated the etherpad for ofagent.
currently a single CI system is running tests for both of ofagent and ryu.
is it ok?
YAMAMOTO Takashi
------------------------------
Message: 26
Date: Mon, 16 Jun 2014 15:40:57 +1000
From: Angus Lees <guslees at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [nova] Distributed locking
Message-ID: <1680518.L3mdUvXxqU at hounddog>
Content-Type: text/plain; charset="us-ascii"
On Fri, 13 Jun 2014 09:40:30 AM Matthew Booth wrote:
> On 12/06/14 21:38, Joshua Harlow wrote:
> > So just a few thoughts before going to far down this path,
> >
> > Can we make sure we really really understand the use-case where we think
> > this is needed. I think it's fine that this use-case exists, but I just
> > want to make it very clear to others why its needed and why distributing
> > locking is the only *correct* way.
>
> An example use of this would be side-loading an image from another
> node's image cache rather than fetching it from glance, which would have
> very significant performance benefits in the VMware driver, and possibly
> other places. The copier must take a read lock on the image to prevent
> the owner from ageing it during the copy. Holding a read lock would also
> assure the copier that the image it is copying is complete.
For this particular example, taking a lock every time seems expensive. An
alternative would be to just try to read from another node, and if the result
wasn't complete+valid for whatever reason then fallback to reading from
glance.
> > * What happens when a node goes down that owns the lock, how does the
> > software react to this?
>
> This can be well defined according to the behaviour of the backend. For
> example, it is well defined in zookeeper when a node's session expires.
> If the lock holder is no longer a valid node, it would be fenced before
> deleting its lock, allowing other nodes to continue.
>
> Without fencing it would not be possible to safely continue in this case.
So I'm sorry for explaining myself poorly in my earlier post. I think you've
just described waiting for the lock to expire before another node can take it,
which is just a regular lock behaviour. What additional steps do you want
Fence() to perform at this point?
(I can see if the resource provider had some form of fencing, then it could do
all sorts of additional things - but I gather your original use case is
exactly where that *isn't* an option)
"If the lock was allowed to go stale and not released cleanly, then we should
forcibly reboot the stale instance before allowing the lock to be held again"
shouldn't be too hard to add.
- Is this just rebooting the instance sufficient for similar situations or would
we need configurable "actions"?
- Which bot do we trust to issue the reboot command?
>From the locking service pov, I can think of several ways to implement this,
so we probably want to export a high-level operation and allow the details to
vary to suit the underlying locking implementation.
--
- Gus
------------------------------
Message: 27
Date: Mon, 16 Jun 2014 11:31:50 +0530
From: abhishek jain <ashujain9727 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] no tap interface on compute node
Message-ID:
<CA+9-LvuRBTJDLGkR_Z15ZDSOmF=kew2txpmpxwRe7xHC5Q2RtQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi
I'm not able to get tap interface up on compute node when I boot VM from
controller node onto compute node.
Please help regarding this.
Thanks
Abhishek Jain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/2842faa5/attachment-0001.html>
------------------------------
Message: 28
Date: Mon, 16 Jun 2014 11:27:36 +0400
From: Eugene Nikanorov <enikanorov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] Implementing new LBaaS API
Message-ID:
<CAJfiwOR42qnmP1TbPdBA0LevsmjW5ju=ziKOp-wp8LxNcKSRLQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Salvatore,
> Also - since it seems to me that there is also consensus regarding having
load balancing move away into a separate project
To me it seems that there was no such a consensus; core team members were
advocating keeping lbaas within neutron.
Thanks,
Eugene.
On Mon, Jun 16, 2014 at 2:23 AM, Brandon Logan <brandon.logan at rackspace.com>
wrote:
> Thank you Salvatore for your feedback.
>
> Comments in-line.
>
> On Sun, 2014-06-15 at 23:26 +0200, Salvatore Orlando wrote:
> > Regarding the two approaches outlines in the top post, I found out
> > that the bullet "This is API versioning done the wrong way" appears in
> > both approaches.
> > Is this a mistake or intentional?
>
> No it was intentional. In my opinion they are both the wrong way. It
> would be best to be able to do a version at the resource layer but we
> can't since lbaas is a part of Neutron and its versions is directly tied
> to Neutron's. Another possibility is to have the resource look like:
>
> http(s)://neutron.endpoint/v2/lbaas/v2
>
> This looks very odd to me though and sets a bad precedent. That is just
> my opinion though. So I wouldn't call this the right way either. Thus,
> I do not know of a "right" way to do this other than choosing the right
> "alternative" way.
>
> >
> >
> > From what I gather, the most reasonable approach appears to be
> > starting with a clean slate, which means having a new API living side
> > by side with the old one.
> > I think the naming collision issues should probably be solved using
> > distinct namespaces for the two API (the old one has /v2/lbaas as a
> > URI prefix I think, I have hardly any idea about what namespace the
> > new one should have)
> >
>
> I'm in agreement with you as well. The old one has /v2/lb as the prefix.
> I figured the new one could be /v2/lbaas which I think works out well.
>
> Another thing to consider that I did not think about in my original
> message is that a whole new load balancing agent will have to be created
> as well since its code is written with the pool being the root object.
> So that should be taken into consideration. So to be perfectly clear,
> starting with a clean slate would involve the following:
>
> 1. New loadbalancer extension
> 2. New loadbalancer plugin
> 3. New lbaas_agentscheduler extension
> 4. New agent_scheduler plugin.
>
> Also, I don't believe doing this would allow the two to be deployed at
> the same time. I believe the setup.cfg file would have to be modified
> to point to the new plugins. I could be wrong about that though.
>
> >
> > Finally, about deprecation - I see it's been agreed to deprecate the
> > current API in Juno.
> > I think this is not the right way of doing things. The limits of the
> > current API are pretty much universally agreed; on the other hand, it
> > is generally not advisable to deprecate an old API in favour of the
> > new one at the first iteration such API is published. My preferred
> > strategy would be to introduce the new API as experimental in the Juno
> > release, so that in can be evaluated, apply any feedback and consider
> > for promoting in K - and contextually deprecate the old API.
> >
> >
> > As there is quite a radical change between the old and the new model,
> > keeping the old API indefinitely is a maintenance burden we probably
> > can't afford, and I would therefore propose complete removal one
> > release cycle after deprecation. Also - since it seems to me that
> > there is also consensus regarding having load balancing move away into
> > a separate project so that it would not be tied anymore to the
> > networking program, the old API is pretty much just dead weight.
> >
> > Salvatore
>
> Good idea on that. I'll bring this up with everyone at the hackathon
> this week if it is not already on the table.
>
> Thanks again for your feedback.
>
> Brandon
> >
> >
> > On 11 June 2014 18:01, Kyle Mestery <mestery at noironetworks.com> wrote:
> > I spoke to Mark McClain about this yesterday, I'll see if I
> > can get
> > him to join the LBaaS team meeting tomorrow so between he and
> > I we can
> > close on this with the LBaaS team.
> >
> > On Wed, Jun 11, 2014 at 10:57 AM, Susanne Balle
> > <sleipnir012 at gmail.com> wrote:
> > > Do we know who has an opinion? If so maybe we can reach out
> > to them directly
> > > and ask them to comment.
> > >
> > >
> > > On Tue, Jun 10, 2014 at 6:44 PM, Brandon Logan
> > <brandon.logan at rackspace.com>
> > > wrote:
> > >>
> > >> Well we got a few opinions, but not enough understanding of
> > the two
> > >> options to make an informed decision. It was requested
> > that the core
> > >> reviewers respond to this thread with their opinions.
> > >>
> > >> Thanks,
> > >> Brandon
> > >>
> > >> On Tue, 2014-06-10 at 13:22 -0700, Stephen Balukoff wrote:
> > >> > Yep, I'd like to know here, too-- as knowing the answer
> > to this
> > >> > unblocks implementation work for us.
> > >> >
> > >> >
> > >> > On Tue, Jun 10, 2014 at 12:38 PM, Brandon Logan
> > >> > <brandon.logan at rackspace.com> wrote:
> > >> > Any core neutron people have a chance to give
> > their opinions
> > >> > on this
> > >> > yet?
> > >> >
> > >> > Thanks,
> > >> > Brandon
> > >> >
> > >> > On Thu, 2014-06-05 at 15:28 +0000, Buraschi,
> > Andres wrote:
> > >> > > Thanks, Kyle. Great.
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: Kyle Mestery
> > [mailto:mestery at noironetworks.com]
> > >> > > Sent: Thursday, June 05, 2014 11:27 AM
> > >> > > To: OpenStack Development Mailing List (not for
> > usage
> > >> > questions)
> > >> > > Subject: Re: [openstack-dev] [Neutron]
> > Implementing new
> > >> > LBaaS API
> > >> > >
> > >> > > On Wed, Jun 4, 2014 at 4:27 PM, Brandon Logan
> > >> > <brandon.logan at rackspace.com> wrote:
> > >> > > > Hi Andres,
> > >> > > > I've assumed (and we know how assumptions
> > work) that the
> > >> > deprecation
> > >> > > > would take place in Juno and after a cyle or
> > two it would
> > >> > totally be
> > >> > > > removed from the code. Even if #1 is the way
> > to go, the
> > >> > old /vips
> > >> > > > resource would be deprecated in favor
> > of /loadbalancers
> > >> > and /listeners.
> > >> > > >
> > >> > > > I agree #2 is cleaner, but I don't want to
> > start on an
> > >> > implementation
> > >> > > > (though I kind of already have) that will
> > fail to be
> > >> > merged in because
> > >> > > > of the strategy. The strategies are pretty
> > different so
> > >> > one needs to
> > >> > > > be decided on.
> > >> > > >
> > >> > > > As for where LBaaS is intended to end up, I
> > don't want to
> > >> > speak for
> > >> > > > Kyle, so this is my understanding; It will
> > end up outside
> > >> > of the
> > >> > > > Neutron code base but Neutron and LBaaS and
> > other services
> > >> > will all
> > >> > > > fall under a Networking (or Network)
> > program. That is my
> > >> > > > understanding and I could be totally wrong.
> > >> > > >
> > >> > > That's my understanding as well, I think
> > Brandon worded it
> > >> > perfectly.
> > >> > >
> > >> > > > Thanks,
> > >> > > > Brandon
> > >> > > >
> > >> > > > On Wed, 2014-06-04 at 20:30 +0000, Buraschi,
> > Andres wrote:
> > >> > > >> Hi Brandon, hi Kyle!
> > >> > > >> I'm a bit confused about the deprecation
> > (btw, thanks for
> > >> > sending this Brandon!), as I (wrongly) assumed #1
> > would be the
> > >> > chosen path for the new API implementation. I
> > understand the
> > >> > proposal and #2 sounds actually cleaner.
> > >> > > >>
> > >> > > >> Just out of curiosity, Kyle, where is LBaaS
> > functionality
> > >> > intended to end up, if long-term plans are to
> > remove it from
> > >> > Neutron?
> > >> > > >>
> > >> > > >> (Nit question, I must clarify)
> > >> > > >>
> > >> > > >> Thank you!
> > >> > > >> Andres
> > >> > > >>
> > >> > > >> -----Original Message-----
> > >> > > >> From: Brandon Logan
> > [mailto:brandon.logan at RACKSPACE.COM]
> > >> > > >> Sent: Wednesday, June 04, 2014 2:18 PM
> > >> > > >> To: openstack-dev at lists.openstack.org
> > >> > > >> Subject: Re: [openstack-dev] [Neutron]
> > Implementing new
> > >> > LBaaS API
> > >> > > >>
> > >> > > >> Thanks for your feedback Kyle. I will be at
> > that meeting
> > >> > on Monday.
> > >> > > >>
> > >> > > >> Thanks,
> > >> > > >> Brandon
> > >> > > >>
> > >> > > >> On Wed, 2014-06-04 at 11:54 -0500, Kyle
> > Mestery wrote:
> > >> > > >> > On Tue, Jun 3, 2014 at 3:01 PM, Brandon
> > Logan
> > >> > > >> > <brandon.logan at rackspace.com> wrote:
> > >> > > >> > > This is an LBaaS topic bud I'd like to
> > get some
> > >> > Neutron Core
> > >> > > >> > > members to give their opinions on this
> > matter so I've
> > >> > just
> > >> > > >> > > directed this to Neutron proper.
> > >> > > >> > >
> > >> > > >> > > The design for the new API and object
> > model for LBaaS
> > >> > needs to be
> > >> > > >> > > locked down before the hackathon in a
> > couple of weeks
> > >> > and there
> > >> > > >> > > are some questions that need answered.
> > This is
> > >> > pretty urgent to
> > >> > > >> > > come on to a decision on and to get a
> > clear strategy
> > >> > defined so
> > >> > > >> > > we can actually do real code during the
> > hackathon
> > >> > instead of
> > >> > > >> > > wasting some of that valuable time
> > discussing this.
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > > Implementation must be backwards
> > compatible
> > >> > > >> > >
> > >> > > >> > > There are 2 ways that have come up on
> > how to do this:
> > >> > > >> > >
> > >> > > >> > > 1) New API and object model are created
> > in the same
> > >> > extension and
> > >> > > >> > > plugin as the old. Any API requests
> > structured for
> > >> > the old API
> > >> > > >> > > will be translated/adapted to the into
> > the new object
> > >> > model.
> > >> > > >> > > PROS:
> > >> > > >> > > -Only one extension and plugin
> > >> > > >> > > -Mostly true backwards compatibility -Do
> > not have to
> > >> > rename
> > >> > > >> > > unchanged resources and models
> > >> > > >> > > CONS:
> > >> > > >> > > -May end up being confusing to an
> > end-user.
> > >> > > >> > > -Separation of old api and new api is
> > less clear
> > >> > -Deprecating and
> > >> > > >> > > removing old api and object model will
> > take a bit
> > >> > more work -This
> > >> > > >> > > is basically API versioning the wrong
> > way
> > >> > > >> > >
> > >> > > >> > > 2) A new extension and plugin are
> > created for the new
> > >> > API and
> > >> > > >> > > object model. Each API would live side
> > by side. New
> > >> > API would
> > >> > > >> > > need to have different names for
> > resources and object
> > >> > models from
> > >> > > >> > > Old API resources and object models.
> > >> > > >> > > PROS:
> > >> > > >> > > -Clean demarcation point between old and
> > new -No
> > >> > translation
> > >> > > >> > > layer needed -Do not need to modify
> > existing API and
> > >> > object
> > >> > > >> > > model, no new bugs -Drivers do not need
> > to be
> > >> > immediately
> > >> > > >> > > modified -Easy to deprecate and remove
> > old API and
> > >> > object model
> > >> > > >> > > later
> > >> > > >> > > CONS:
> > >> > > >> > > -Separate extensions and object model
> > will be
> > >> > confusing to
> > >> > > >> > > end-users -Code reuse by copy paste
> > since old
> > >> > extension and
> > >> > > >> > > plugin will be deprecated and removed.
> > >> > > >> > > -This is basically API versioning the
> > wrong way
> > >> > > >> > >
> > >> > > >> > > Now if #2 is chosen to be feasible and
> > acceptable
> > >> > then there are
> > >> > > >> > > a number of ways to actually do that. I
> > won't bring
> > >> > those up
> > >> > > >> > > until a clear decision is made on which
> > strategy
> > >> > above is the most acceptable.
> > >> > > >> > >
> > >> > > >> > Thanks for sending this out Brandon. I'm
> > in favor of
> > >> > option #2
> > >> > > >> > above, especially considering the
> > long-term plans to
> > >> > remove LBaaS
> > >> > > >> > from Neutron. That approach will help the
> > eventual end
> > >> > goal there.
> > >> > > >> > I am also curious on what others think,
> > and to this
> > >> > end, I've added
> > >> > > >> > this as an agenda item for the team
> > meeting next
> > >> > Monday. Brandon,
> > >> > > >> > it would be great to get you there for the
> > part of the
> > >> > meeting
> > >> > > >> > where we'll discuss this.
> > >> > > >> >
> > >> > > >> > Thanks!
> > >> > > >> > Kyle
> > >> > > >> >
> > >> > > >> > > Thanks,
> > >> > > >> > > Brandon
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > >> > > >> > >
> > _______________________________________________
> > >> > > >> > > OpenStack-dev mailing list
> > >> > > >> > > OpenStack-dev at lists.openstack.org
> > >> > > >> > >
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > > >> >
> > >> > > >> >
> > _______________________________________________
> > >> > > >> > OpenStack-dev mailing list
> > >> > > >> > OpenStack-dev at lists.openstack.org
> > >> > > >> >
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > > >>
> > >> > > >>
> > _______________________________________________
> > >> > > >> OpenStack-dev mailing list
> > >> > > >> OpenStack-dev at lists.openstack.org
> > >> > > >>
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > > >>
> > >> > > >>
> > _______________________________________________
> > >> > > >> OpenStack-dev mailing list
> > >> > > >> OpenStack-dev at lists.openstack.org
> > >> > > >>
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > > >
> > >> > > >
> > _______________________________________________
> > >> > > > OpenStack-dev mailing list
> > >> > > > OpenStack-dev at lists.openstack.org
> > >> > > >
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > >
> > >> > > _______________________________________________
> > >> > > OpenStack-dev mailing list
> > >> > > OpenStack-dev at lists.openstack.org
> > >> > >
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> > >
> > >> > > _______________________________________________
> > >> > > OpenStack-dev mailing list
> > >> > > OpenStack-dev at lists.openstack.org
> > >> > >
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> >
> > >> > _______________________________________________
> > >> > OpenStack-dev mailing list
> > >> > OpenStack-dev at lists.openstack.org
> > >> >
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Stephen Balukoff
> > >> > Blue Box Group, LLC
> > >> > (800)613-4305 x807
> > >> > _______________________________________________
> > >> > OpenStack-dev mailing list
> > >> > OpenStack-dev at lists.openstack.org
> > >> >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >> _______________________________________________
> > >> OpenStack-dev mailing list
> > >> OpenStack-dev at lists.openstack.org
> > >>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140616/37adee29/attachment-0001.html>
------------------------------
Message: 29
Date: Mon, 16 Jun 2014 03:41:17 -0400
From: Jay Pipes <jaypipes at gmail.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [nova] Distributed locking
Message-ID: <539E9F9D.2020803 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/13/2014 05:01 AM, Julien Danjou wrote:
> On Thu, Jun 12 2014, Jay Pipes wrote:
>
>> This is news to me. When was this decided and where can I read about
>> it?
>
> Originally https://wiki.openstack.org/wiki/Oslo/blueprints/service-sync
> has been proposed, presented and accepted back at the Icehouse summit in
> HKG. That's what led to tooz creation and development since then.
Thanks, Julien, that's a helpful link. Appreciated!
Best,
-jay
------------------------------
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
End of OpenStack-dev Digest, Vol 26, Issue 50
*********************************************
More information about the OpenStack-dev
mailing list
