Mailing List Archive: OpenStack: Dev

Removal of VSA Code

Index | Next | Previous | View Threaded

vishvananda at gmail

Mar 14, 2012, 6:54 PM

Post #1 of 16 (41 views)
Permalink

Removal of VSA Code

Apologies if you receive this email twice, I sent the first one from the wrong address.

Hello Everyone,

Last week during the release meeting it was mentioned that the VSA code is not working properly and we should either fix it or remove it. I propose to remove it for the following reasons:

* Lack of documentation -- unclear how to create a vsa image or how the image should function
* Lack of support from vendors -- originally, the hope was other vendors would use the vsa code to create their own virtual storage arrays
* Lack of functional testing -- this is the main reason the code has bitrotted
* Lack of updates from original coders -- Zadara has mentioned a few times that they were going to update the code but it has not happened
* Eases Transition to separate volume project -- This lowers the surface area of the volume code and makes it easier to cleanly separate the volume service to compute

As far as I can tell Zadara is maintaining a fork of the code for their platform, so keeping the code in the public tree doesn't seem necessary. I would be happy to see this code come back in Folsom if we get a stronger commitment to keep it up-to-date, documented, and maintained, and there is a reasonable location for it if the volume and compute code is separate.

If anyone disagrees, please respond ASAP.

Vish

brian.waldon at rackspace

Mar 14, 2012, 8:46 PM

Post #2 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

Related links:
https://bugs.launchpad.net/nova/+bug/954490
https://review.openstack.org/#change,5377

On Mar 14, 2012, at 6:54 PM, Vishvananda Ishaya wrote:

> Apologies if you receive this email twice, I sent the first one from the wrong address.
>
> Hello Everyone,
>
> Last week during the release meeting it was mentioned that the VSA code is not working properly and we should either fix it or remove it. I propose to remove it for the following reasons:
>
> * Lack of documentation -- unclear how to create a vsa image or how the image should function
> * Lack of support from vendors -- originally, the hope was other vendors would use the vsa code to create their own virtual storage arrays
> * Lack of functional testing -- this is the main reason the code has bitrotted
> * Lack of updates from original coders -- Zadara has mentioned a few times that they were going to update the code but it has not happened
> * Eases Transition to separate volume project -- This lowers the surface area of the volume code and makes it easier to cleanly separate the volume service to compute
>
> As far as I can tell Zadara is maintaining a fork of the code for their platform, so keeping the code in the public tree doesn't seem necessary. I would be happy to see this code come back in Folsom if we get a stronger commitment to keep it up-to-date, documented, and maintained, and there is a reasonable location for it if the volume and compute code is separate.
>
> If anyone disagrees, please respond ASAP.
>
> Vish
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

vladimir at zadarastorage

Mar 15, 2012, 8:48 AM

Post #3 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

Hi Vish & All,

We would definitely prefer to leave the code in place and ready to fix any
issues related to it.

We found out that it is extremely hard to work with latest trunk version -
our QA was constantly complaining about different regression scenarios and
we decided to stick with released stable Nova branches and perform merges
either after main releases or major milestones.

The current VSA code in trunk is completely functional & working. We've
done tons of enhancements to it and added new functionality during last
4-5 month. As I mentioned before our plan was to merge it with latest
relatively stable Essex code and to have this code in somewhere at the
beginning of Folsom.

At the same time we understand your concerns - without proper
documentation and related packages (like VSA image & drive discovery
packages) it is very hard to use/test it.
We are ready to collaborate with whoever is interested in order to make
this functionality generic enough. From our side we will try to fix it.

Please let us know what should we do in order to leave it in place.

Thanks,
-Vladimir
Zadara Storage

-----Original Message-----
From: openstack-bounces+vladimir=zadarastorage.com [at] lists
[mailto:openstack-bounces+vladimir=zadarastorage.com [at] lists]
On Behalf Of Vishvananda Ishaya
Sent: Wednesday, March 14, 2012 6:54 PM
To: openstack [at] lists (openstack [at] lists)
Subject: [Openstack] Removal of VSA Code

Apologies if you receive this email twice, I sent the first one from the
wrong address.

Hello Everyone,

Last week during the release meeting it was mentioned that the VSA code is
not working properly and we should either fix it or remove it. I propose
to remove it for the following reasons:

* Lack of documentation -- unclear how to create a vsa image or how the
image should function
* Lack of support from vendors -- originally, the hope was other vendors
would use the vsa code to create their own virtual storage arrays
* Lack of functional testing -- this is the main reason the code has
bitrotted
* Lack of updates from original coders -- Zadara has mentioned a few times
that they were going to update the code but it has not happened
* Eases Transition to separate volume project -- This lowers the surface
area of the volume code and makes it easier to cleanly separate the volume
service to compute

As far as I can tell Zadara is maintaining a fork of the code for their
platform, so keeping the code in the public tree doesn't seem necessary.
I would be happy to see this code come back in Folsom if we get a stronger
commitment to keep it up-to-date, documented, and maintained, and there is
a reasonable location for it if the volume and compute code is separate.

If anyone disagrees, please respond ASAP.

Vish
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

vishvananda at gmail

Mar 15, 2012, 8:56 AM

Post #4 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

Vladimir,

Are you sure the code in trunk is working? Investigation by one of the community members showed that it was broken. If you are planning on merging your new code in, perhaps it is better to do it all at once? FYI, nova-volume is going to be split into its own service during folsom, and based on the fact that vsa uses both compute and volume, it might be best to actually move it into its own project as well.

This will keep separation of concerns and allow you to maintain it more directly in the public. I still think the best approach for now is to pull it and bring back the fully functional version in Folsom. No one is using it in its current state.

Vish

On Mar 15, 2012, at 8:48 AM, Vladimir Popovski wrote:

> Hi Vish & All,
>
> We would definitely prefer to leave the code in place and ready to fix any
> issues related to it.
>
> We found out that it is extremely hard to work with latest trunk version -
> our QA was constantly complaining about different regression scenarios and
> we decided to stick with released stable Nova branches and perform merges
> either after main releases or major milestones.
>
> The current VSA code in trunk is completely functional & working. We've
> done tons of enhancements to it and added new functionality during last
> 4-5 month. As I mentioned before our plan was to merge it with latest
> relatively stable Essex code and to have this code in somewhere at the
> beginning of Folsom.
>
> At the same time we understand your concerns - without proper
> documentation and related packages (like VSA image & drive discovery
> packages) it is very hard to use/test it.
> We are ready to collaborate with whoever is interested in order to make
> this functionality generic enough. From our side we will try to fix it.
>
> Please let us know what should we do in order to leave it in place.
>
> Thanks,
> -Vladimir
> Zadara Storage
>
>
> -----Original Message-----
> From: openstack-bounces+vladimir=zadarastorage.com [at] lists
> [mailto:openstack-bounces+vladimir=zadarastorage.com [at] lists]
> On Behalf Of Vishvananda Ishaya
> Sent: Wednesday, March 14, 2012 6:54 PM
> To: openstack [at] lists (openstack [at] lists)
> Subject: [Openstack] Removal of VSA Code
>
> Apologies if you receive this email twice, I sent the first one from the
> wrong address.
>
> Hello Everyone,
>
> Last week during the release meeting it was mentioned that the VSA code is
> not working properly and we should either fix it or remove it. I propose
> to remove it for the following reasons:
>
> * Lack of documentation -- unclear how to create a vsa image or how the
> image should function
> * Lack of support from vendors -- originally, the hope was other vendors
> would use the vsa code to create their own virtual storage arrays
> * Lack of functional testing -- this is the main reason the code has
> bitrotted
> * Lack of updates from original coders -- Zadara has mentioned a few times
> that they were going to update the code but it has not happened
> * Eases Transition to separate volume project -- This lowers the surface
> area of the volume code and makes it easier to cleanly separate the volume
> service to compute
>
> As far as I can tell Zadara is maintaining a fork of the code for their
> platform, so keeping the code in the public tree doesn't seem necessary.
> I would be happy to see this code come back in Folsom if we get a stronger
> commitment to keep it up-to-date, documented, and maintained, and there is
> a reasonable location for it if the volume and compute code is separate.
>
> If anyone disagrees, please respond ASAP.
>
> Vish
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

vladimir at zadarastorage

Mar 15, 2012, 9:02 AM

Post #5 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

Hi Vish,

I was not aware of any issue with VSA code in diablo/stable (or at least
major issues).
Of course, we've done tons of changes to it lately and probably there were
some bugs that were fixed later, but I'm sure this particular code is
fully functional.

We will need to look closer on planned separation of volume & compute code
and understand what will be the best place for our VSA code. Probably we
can discuss it during summit.

From my previous experience with merges - it will be way easier (at least
for us) to provide an upgrade for the code rather than to push a
completely new code.

Thanks,
-Vladimir

-----Original Message-----
From: Vishvananda Ishaya [mailto:vishvananda [at] gmail]
Sent: Thursday, March 15, 2012 8:57 AM
To: Vladimir Popovski
Cc: openstack [at] lists
Subject: Re: [Openstack] Removal of VSA Code

Vladimir,

Are you sure the code in trunk is working? Investigation by one of the
community members showed that it was broken. If you are planning on
merging your new code in, perhaps it is better to do it all at once? FYI,
nova-volume is going to be split into its own service during folsom, and
based on the fact that vsa uses both compute and volume, it might be best
to actually move it into its own project as well.

This will keep separation of concerns and allow you to maintain it more
directly in the public. I still think the best approach for now is to pull
it and bring back the fully functional version in Folsom. No one is using
it in its current state.

Vish

On Mar 15, 2012, at 8:48 AM, Vladimir Popovski wrote:

> Hi Vish & All,
>
> We would definitely prefer to leave the code in place and ready to fix
> any issues related to it.
>
> We found out that it is extremely hard to work with latest trunk
> version - our QA was constantly complaining about different regression
> scenarios and we decided to stick with released stable Nova branches
> and perform merges either after main releases or major milestones.
>
> The current VSA code in trunk is completely functional & working.
> We've done tons of enhancements to it and added new functionality
> during last
> 4-5 month. As I mentioned before our plan was to merge it with latest
> relatively stable Essex code and to have this code in somewhere at the
> beginning of Folsom.
>
> At the same time we understand your concerns - without proper
> documentation and related packages (like VSA image & drive discovery
> packages) it is very hard to use/test it.
> We are ready to collaborate with whoever is interested in order to
> make this functionality generic enough. From our side we will try to fix
it.
>
> Please let us know what should we do in order to leave it in place.
>
> Thanks,
> -Vladimir
> Zadara Storage
>
>
> -----Original Message-----
> From: openstack-bounces+vladimir=zadarastorage.com [at] lists
> [mailto:openstack-bounces+vladimir=zadarastorage.com [at] lists
> et]
> On Behalf Of Vishvananda Ishaya
> Sent: Wednesday, March 14, 2012 6:54 PM
> To: openstack [at] lists (openstack [at] lists)
> Subject: [Openstack] Removal of VSA Code
>
> Apologies if you receive this email twice, I sent the first one from
> the wrong address.
>
> Hello Everyone,
>
> Last week during the release meeting it was mentioned that the VSA
> code is not working properly and we should either fix it or remove it.
> I propose to remove it for the following reasons:
>
> * Lack of documentation -- unclear how to create a vsa image or how
> the image should function
> * Lack of support from vendors -- originally, the hope was other
> vendors would use the vsa code to create their own virtual storage
> arrays
> * Lack of functional testing -- this is the main reason the code has
> bitrotted
> * Lack of updates from original coders -- Zadara has mentioned a few
> times that they were going to update the code but it has not happened
> * Eases Transition to separate volume project -- This lowers the
> surface area of the volume code and makes it easier to cleanly
> separate the volume service to compute
>
> As far as I can tell Zadara is maintaining a fork of the code for
> their platform, so keeping the code in the public tree doesn't seem
necessary.
> I would be happy to see this code come back in Folsom if we get a
> stronger commitment to keep it up-to-date, documented, and maintained,
> and there is a reasonable location for it if the volume and compute code
is separate.
>
> If anyone disagrees, please respond ASAP.
>
> Vish
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

brian.waldon at rackspace

Mar 15, 2012, 9:36 AM

Post #6 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

I would like to add that the complete lack of documentation makes the VSA code unusable. I have no idea where to get started with it. The following bug has been open and assigned for the past 6+ months: https://bugs.launchpad.net/nova/+bug/835099. The fact that you are maintaining a fork of Nova with your own enhancements also reinforces the idea that VSA should not live within the Nova codebase. We are also in our release-candidate phase, so any major code 'enhancements' should *not* be landing.

Brian

On Mar 15, 2012, at 8:56 AM, Vishvananda Ishaya wrote:

> Vladimir,
>
> Are you sure the code in trunk is working? Investigation by one of the community members showed that it was broken. If you are planning on merging your new code in, perhaps it is better to do it all at once? FYI, nova-volume is going to be split into its own service during folsom, and based on the fact that vsa uses both compute and volume, it might be best to actually move it into its own project as well.
>
> This will keep separation of concerns and allow you to maintain it more directly in the public. I still think the best approach for now is to pull it and bring back the fully functional version in Folsom. No one is using it in its current state.
>
> Vish
>
> On Mar 15, 2012, at 8:48 AM, Vladimir Popovski wrote:
>
>> Hi Vish & All,
>>
>> We would definitely prefer to leave the code in place and ready to fix any
>> issues related to it.
>>
>> We found out that it is extremely hard to work with latest trunk version -
>> our QA was constantly complaining about different regression scenarios and
>> we decided to stick with released stable Nova branches and perform merges
>> either after main releases or major milestones.
>>
>> The current VSA code in trunk is completely functional & working. We've
>> done tons of enhancements to it and added new functionality during last
>> 4-5 month. As I mentioned before our plan was to merge it with latest
>> relatively stable Essex code and to have this code in somewhere at the
>> beginning of Folsom.
>>
>> At the same time we understand your concerns - without proper
>> documentation and related packages (like VSA image & drive discovery
>> packages) it is very hard to use/test it.
>> We are ready to collaborate with whoever is interested in order to make
>> this functionality generic enough. From our side we will try to fix it.
>>
>> Please let us know what should we do in order to leave it in place.
>>
>> Thanks,
>> -Vladimir
>> Zadara Storage
>>
>>
>> -----Original Message-----
>> From: openstack-bounces+vladimir=zadarastorage.com [at] lists
>> [mailto:openstack-bounces+vladimir=zadarastorage.com [at] lists]
>> On Behalf Of Vishvananda Ishaya
>> Sent: Wednesday, March 14, 2012 6:54 PM
>> To: openstack [at] lists (openstack [at] lists)
>> Subject: [Openstack] Removal of VSA Code
>>
>> Apologies if you receive this email twice, I sent the first one from the
>> wrong address.
>>
>> Hello Everyone,
>>
>> Last week during the release meeting it was mentioned that the VSA code is
>> not working properly and we should either fix it or remove it. I propose
>> to remove it for the following reasons:
>>
>> * Lack of documentation -- unclear how to create a vsa image or how the
>> image should function
>> * Lack of support from vendors -- originally, the hope was other vendors
>> would use the vsa code to create their own virtual storage arrays
>> * Lack of functional testing -- this is the main reason the code has
>> bitrotted
>> * Lack of updates from original coders -- Zadara has mentioned a few times
>> that they were going to update the code but it has not happened
>> * Eases Transition to separate volume project -- This lowers the surface
>> area of the volume code and makes it easier to cleanly separate the volume
>> service to compute
>>
>> As far as I can tell Zadara is maintaining a fork of the code for their
>> platform, so keeping the code in the public tree doesn't seem necessary.
>> I would be happy to see this code come back in Folsom if we get a stronger
>> commitment to keep it up-to-date, documented, and maintained, and there is
>> a reasonable location for it if the volume and compute code is separate.
>>
>> If anyone disagrees, please respond ASAP.
>>
>> Vish
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

kevin.mitchell at rackspace

Mar 15, 2012, 9:53 AM

Post #7 of 16 (41 views)
Permalink

Re: Removal of VSA Code [In reply to]

On Thu, 2012-03-15 at 09:02 -0700, Vladimir Popovski wrote:
> I was not aware of any issue with VSA code in diablo/stable (or at least
> major issues).

I'll point out that the code we're concerned about is the code in trunk,
not the code in diablo/stable. There have been substantial changes to
the code since diablo was released, which has resulted in bitrot in the
VSA code and the attendant breakages to which Vish is referring.
--
Kevin L. Mitchell <kevin.mitchell [at] rackspace>

thierry at openstack

Mar 15, 2012, 9:57 AM

Post #8 of 16 (41 views)
Permalink

Re: Removal of VSA Code [In reply to]

Brian Waldon wrote:
> I would like to add that the complete lack of documentation makes the
> VSA code unusable. I have no idea where to get started with it. The
> following bug has been open and assigned for the past 6+
> months: https://bugs.launchpad.net/nova/+bug/835099. The fact that you
> are maintaining a fork of Nova with your own enhancements also
> reinforces the idea that VSA should not live within the Nova codebase.
> We are also in our release-candidate phase, so any major code
> 'enhancements' should *not* be landing.

+1: it was a bit late to realize that it's not working/not documented,
and it's definitely too late to fix it.

I will add that we should make sure that in Folsom it gets easy to build
a volume plugin without needing changes to core code, so that
maintaining them off-tree is easier.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

ghe.rivero at stackops

Mar 15, 2012, 10:08 AM

Post #9 of 16 (44 views)
Permalink

Re: Removal of VSA Code [In reply to]

I think is time (after essex release) to rethink the way plugins are
integrated into "mainline code". This problem, an outdated plugin, it's not
new (Hyper-V), and with the increasing numbers of them (storage like
Zadara, Nexenta... network with Nicira, BigSwitch, Citrix...) we need a
policy to deal with this. From the vendor point of view, it's not easy to
follow the development release cycle that OpenStack has now days, with so
many changes day after day. Maybe plugins should be out of OpenStack code,
and let vendors to publish them after the release.

Ghe Rivero

On Thu, Mar 15, 2012 at 5:53 PM, Kevin L. Mitchell <
kevin.mitchell [at] rackspace> wrote:

> On Thu, 2012-03-15 at 09:02 -0700, Vladimir Popovski wrote:
> > I was not aware of any issue with VSA code in diablo/stable (or at least
> > major issues).
>
> I'll point out that the code we're concerned about is the code in trunk,
> not the code in diablo/stable. There have been substantial changes to
> the code since diablo was released, which has resulted in bitrot in the
> VSA code and the attendant breakages to which Vish is referring.
> --
> Kevin L. Mitchell <kevin.mitchell [at] rackspace>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

--
Ghe Rivero
*OpenStack & Distribution Engineer
**www.stackops.com | * ghe.rivero [at] stackops <diego.parrilla [at] stackops>
** | +34 625 63 45 23 | skype:ghe.rivero*
* <http://www.stackops.com/>
*

*

******************** ADVERTENCIA LEGAL ********************
Le informamos, como destinatario de este mensaje, que el correo electr�nico
y las comunicaciones por medio de Internet no permiten asegurar ni
garantizar la confidencialidad de los mensajes transmitidos, as� como
tampoco su integridad o su correcta recepci�n, por lo que STACKOPS
TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias.
Si no consintiese en la utilizaci�n del correo electr�nico o de las
comunicaciones v�a Internet le rogamos nos lo comunique y ponga en nuestro
conocimiento de manera inmediata. Este mensaje va dirigido, de manera
exclusiva, a su destinatario y contiene informaci�n confidencial y sujeta
al secreto profesional, cuya divulgaci�n no est� permitida por la ley. En
caso de haber recibido este mensaje por error, le rogamos que, de forma
inmediata, nos lo comunique mediante correo electr�nico remitido a nuestra
atenci�n y proceda a su eliminaci�n, as� como a la de cualquier documento
adjunto al mismo. Asimismo, le comunicamos que la distribuci�n, copia o
utilizaci�n de este mensaje, o de cualquier documento adjunto al mismo,
cualquiera que fuera su finalidad, est�n prohibidas por la ley.

***************** PRIVILEGED AND CONFIDENTIAL ****************
We hereby inform you, as addressee of this message, that e-mail and
Internet do not guarantee the confidentiality, nor the completeness or
proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L.
does not assume any liability for those circumstances. Should you not agree
to the use of e-mail or to communications via Internet, you are kindly
requested to notify us immediately. This message is intended exclusively
for the person to whom it is addressed and contains privileged and
confidential information protected from disclosure by law. If you are not
the addressee indicated in this message, you should immediately delete it
and any attachments and notify the sender by reply e-mail. In such case,
you are hereby notified that any dissemination, distribution, copying or
use of this message or any attachments, for any purpose, is strictly
prohibited by law.

vladimir at zadarastorage

Mar 15, 2012, 10:09 AM

Post #10 of 16 (41 views)
Permalink

Re: Removal of VSA Code [In reply to]

If there is anything broken in Essex due to this code, please let me know
and we will take a look/fix it.

The main reason why we would like to have it in place - to make developers
aware that there is somebody relying on particular functionality and/or
particular function/module. Otherwise we will be in a constant merge
conflict and every time we will need to manually review almost any change
that is applied to the trunk and check if it anyhow affects/breaks it.

Thanks,
-Vladimir

-----Original Message-----
From: Kevin L. Mitchell [mailto:kevin.mitchell [at] rackspace]
Sent: Thursday, March 15, 2012 9:53 AM
To: Vladimir Popovski
Cc: Vishvananda Ishaya; openstack [at] lists
Subject: Re: [Openstack] Removal of VSA Code

On Thu, 2012-03-15 at 09:02 -0700, Vladimir Popovski wrote:
> I was not aware of any issue with VSA code in diablo/stable (or at
> least major issues).

I'll point out that the code we're concerned about is the code in trunk, not
the code in diablo/stable. There have been substantial changes to the code
since diablo was released, which has resulted in bitrot in the VSA code and
the attendant breakages to which Vish is referring.
--
Kevin L. Mitchell <kevin.mitchell [at] rackspace>

vishvananda at gmail

Mar 15, 2012, 10:33 AM

Post #11 of 16 (43 views)
Permalink

Re: Removal of VSA Code [In reply to]

On Mar 15, 2012, at 10:08 AM, Ghe Rivero wrote:

> I think is time (after essex release) to rethink the way plugins are integrated into "mainline code". This problem, an outdated plugin, it's not new (Hyper-V), and with the increasing numbers of them (storage like Zadara, Nexenta... network with Nicira, BigSwitch, Citrix...) we need a policy to deal with this. From the vendor point of view, it's not easy to follow the development release cycle that OpenStack has now days, with so many changes day after day. Maybe plugins should be out of OpenStack code, and let vendors to publish them after the release.

+1

We are going to discuss a plan at the summit for making this easier.

vishvananda at gmail

Mar 15, 2012, 10:40 AM

Post #12 of 16 (41 views)
Permalink

Re: Removal of VSA Code [In reply to]

On Mar 15, 2012, at 8:48 AM, Vladimir Popovski wrote:

> Hi Vish & All,
>
> We would definitely prefer to leave the code in place and ready to fix any
> issues related to it.
>
> We found out that it is extremely hard to work with latest trunk version -
> our QA was constantly complaining about different regression scenarios and
> we decided to stick with released stable Nova branches and perform merges
> either after main releases or major milestones.

I think this decision led to the current problem. You guys are the only ones testing/using the code and you are testing against stable/diablo. There is no way for the current code to be maintained in this case. If we ship the code that is in trunk now, it is broken with essex. The only way for that not to occur in the future is if the authors of the code maintain responsibility for it keeping up with trunk. The time to try to fix this for essex was during e-4, not the last few days of the release candidate.

I think our best bet is still to pull it and merge it back in folsom if you guys are willing to keep up with trunk. I still think it is better for you guys to ship separately since no one will be using the vanilla essex code anyway. I'm willing to leave the db code and migrations in if that makes shipping separately easier for you. Ultimately I really feel that vsa should be its own (potentially incubated) project.

Vish

annegentle at justwriteclick

Mar 15, 2012, 11:16 AM

Post #13 of 16 (42 views)
Permalink

Re: Removal of VSA Code [In reply to]

Without install and config docs it is too difficult to ask testers to try it.

My docs request of this particular volume extension was in the diablo release but is still needed in Essex. Let's start with a docs merge request before asking people to test it.

Let me know if you need an orientation to doc tools, the merge process itself is just like the code.

Warmly,
Anne Gentle
Content Stacker
anne [at] openstack

On Mar 15, 2012, at 12:09 PM, Vladimir Popovski <vladimir [at] zadarastorage> wrote:

> If there is anything broken in Essex due to this code, please let me know
> and we will take a look/fix it.
>
> The main reason why we would like to have it in place - to make developers
> aware that there is somebody relying on particular functionality and/or
> particular function/module. Otherwise we will be in a constant merge
> conflict and every time we will need to manually review almost any change
> that is applied to the trunk and check if it anyhow affects/breaks it.
>
> Thanks,
> -Vladimir
>
>
> -----Original Message-----
> From: Kevin L. Mitchell [mailto:kevin.mitchell [at] rackspace]
> Sent: Thursday, March 15, 2012 9:53 AM
> To: Vladimir Popovski
> Cc: Vishvananda Ishaya; openstack [at] lists
> Subject: Re: [Openstack] Removal of VSA Code
>
> On Thu, 2012-03-15 at 09:02 -0700, Vladimir Popovski wrote:
>> I was not aware of any issue with VSA code in diablo/stable (or at
>> least major issues).
>
> I'll point out that the code we're concerned about is the code in trunk, not
> the code in diablo/stable. There have been substantial changes to the code
> since diablo was released, which has resulted in bitrot in the VSA code and
> the attendant breakages to which Vish is referring.
> --
> Kevin L. Mitchell <kevin.mitchell [at] rackspace>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

john.griffith at solidfire

Mar 15, 2012, 11:21 AM

Post #14 of 16 (44 views)
Permalink

Re: Removal of VSA Code [In reply to]

On a sort of side note, I was sort of surprised that given all the
discussion on volumes, VSA etc in IRC and on email lately that there
were ZERO attendees in the weekly meeting today.

So, maybe just a reminder, there is a weekly volume meeting in
openstack-meeting on Thursdays at 18:00 (UTC). Also the meetings page
is updated and open for folks to add topics.

John

On Thu, Mar 15, 2012 at 11:33 AM, Vishvananda Ishaya
<vishvananda [at] gmail> wrote:
>
> On Mar 15, 2012, at 10:08 AM, Ghe Rivero wrote:
>
>> I think is time (after essex release) to rethink the way plugins are integrated into "mainline code". This problem, an outdated plugin, it's not new �(Hyper-V), and with the increasing numbers of them (storage like Zadara, Nexenta... network with Nicira, BigSwitch, Citrix...) we need a policy to deal with this. From the vendor point of view, it's not easy to follow the development release cycle that OpenStack has now days, with so many changes day after day. Maybe plugins should be out of OpenStack code, and let vendors to publish them after the release.
>
> +1
>
> We are going to discuss a plan at the summit for making this easier.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to � � : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help � : https://help.launchpad.net/ListHelp

cbehrens at codestud

Mar 15, 2012, 11:32 AM

Post #15 of 16 (43 views)
Permalink

Re: Removal of VSA Code [In reply to]

+1

I'd like to see a way for plugins to be able to modify the DB schema. There's no easy way for a plugin to be able to add a column to a core nova table, for instance.

In any case, I'm +1 on removing the vsa code for Essex.

On Mar 15, 2012, at 10:08 AM, Ghe Rivero wrote:

> I think is time (after essex release) to rethink the way plugins are integrated into "mainline code". This problem, an outdated plugin, it's not new (Hyper-V), and with the increasing numbers of them (storage like Zadara, Nexenta... network with Nicira, BigSwitch, Citrix...) we need a policy to deal with this. From the vendor point of view, it's not easy to follow the development release cycle that OpenStack has now days, with so many changes day after day. Maybe plugins should be out of OpenStack code, and let vendors to publish them after the release.
>
> Ghe Rivero
>
> On Thu, Mar 15, 2012 at 5:53 PM, Kevin L. Mitchell <kevin.mitchell [at] rackspace> wrote:
> On Thu, 2012-03-15 at 09:02 -0700, Vladimir Popovski wrote:
> > I was not aware of any issue with VSA code in diablo/stable (or at least
> > major issues).
>
> I'll point out that the code we're concerned about is the code in trunk,
> not the code in diablo/stable. There have been substantial changes to
> the code since diablo was released, which has resulted in bitrot in the
> VSA code and the attendant breakages to which Vish is referring.
> --
> Kevin L. Mitchell <kevin.mitchell [at] rackspace>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> --
> Ghe Rivero
> OpenStack & Distribution Engineer
> www.stackops.com | ghe.rivero [at] stackops | +34 625 63 45 23 | skype:ghe.rivero
>
>
> ******************** ADVERTENCIA LEGAL ********************
> Le informamos, como destinatario de este mensaje, que el correo electr�nico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, as� como tampoco su integridad o su correcta recepci�n, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilizaci�n del correo electr�nico o de las comunicaciones v�a Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene informaci�n confidencial y sujeta al secreto profesional, cuya divulgaci�n no est� permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electr�nico remitido a nuestra atenci�n y proceda a su eliminaci�n, as� como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribuci�n, copia o utilizaci�n de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, est�n prohibidas por la ley.
>
> ***************** PRIVILEGED AND CONFIDENTIAL ****************
> We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp

Caitlin.Bestler at nexenta

Mar 15, 2012, 12:25 PM

Post #16 of 16 (43 views)
Permalink

Re: Removal of VSA Code [In reply to]

Ghe Rivero wrote:

� I think is time (after essex release) to rethink the way plugins are integrated into "mainline code". This problem,
an outdated plugin, it's not new (Hyper-V), and with the increasing numbers of them (storage like Zadara, Nexenta...
network with Nicira, BigSwitch, Citrix...) we need a policy to deal with this. From the vendor point of view, it's not
easy to follow the development release cycle that OpenStack has now days, with so many changes day after day.
Maybe plugins should be out of OpenStack code, and let vendors to publish them after the release.

The code that enables the plugin obviously needs to be part of the core code, but I agree that plugins are best packaged separately,
and optionally distributed separately.

A clean plugin has known dependencies on Python and the plug-in API itself. But if neither of those change, the implanter of a plug-in
should benefit from knowing that they don't have to track every release cycle of OpenStack.

The cloud does not need a monolithically compiled kernel.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads