last providers to weed out in jclouds 1.6

[Adrian Cole]

Hi, folks.

The following providers were completely dysfunctional as of last tests for system reasons:

stratogen-vcloud-mycloud

synaptic-storage

trystack-nova

https://github.com/jclouds/jclouds.github.com/blob/master/documentation/releasenotes/1.6-tests.md

In all cases, these are "configuration" providers, and don't have specialized code.  In the rare case someone resurrects these services, they can use use the bare "vcloud", "atmos", or "openstack-nova" apis with endpoints assigned.

We should remove them before 1.6.0 final, as we did other dysfunctional providers.  This lowers the build, test, and maintenance debt, but doesn't preclude users from using any of these services using bare apis.  Any suggestions to the contrary?

-A

[Everett Toews]

+1

I volunteer to remove trystack-nova. As you say, it's just a configuration provider. I would be surprised to learn that anyone was using it and will take responsibility if anyone "misses" it.

Everett

--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jclouds-dev...@googlegroups.com.
To post to this group, send email to jclou...@googlegroups.com.
Visit this group at http://groups.google.com/group/jclouds-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ignasi]

+1 to remove them

[Steve Spink]

Hi,

Just noticed the talk about removing StratoGen. If possible we’d like to keep the configuration guides on the site going as we sometimes point people to them.

 

On a more general note, we are one of the more agile vCloud providers so we always run the latest version of vCloud Director (currently v5.1) which jclouds does seem to have problems with. I’m keen to help you guys in any way I can so if you need resources for testing  just let me know.

 

If there are any other ways StratoGen can help then please get in touch.

 

Kind regards,

 

Steve.

[Nirmal Fernando]

On Fri, Apr 26, 2013 at 9:21 PM, Steve Spink <steve...@googlemail.com> wrote:

Hi,

Just noticed the talk about removing StratoGen. If possible we’d like to keep the configuration guides on the site going as we sometimes point people to them.

 

On a more general note, we are one of the more agile vCloud providers so we always run the latest version of vCloud Director (currently v5.1) which jclouds does seem to have problems with. I’m keen to help you guys in any way I can so if you need resources for testing  just let me know.

 

If there are any other ways StratoGen can help then please get in touch.

+1 for keeping StratoGen.

--

Thanks & regards,
Nirmal

Software Engineer- Platform Technologies Team, WSO2 Inc.
Mobile: +94715779733
Blog: http://nirmalfdo.blogspot.com/

[Adrian Cole]

Hi, Steve.

I agree we can keep the config needed to connect to stratogen in the documentation, and even better if you can keep an eye on that.  We already have this for various S3 providers.  Also, keep an eye out when we move to ASF to ensure the docs are reflected.  

WRT your other question, there's a mostly abandoned vcloud-director module in labs that has a volunteer, but little action every couple months or so :)  This is the one that supports vcloud >1.0, but needs some TLC before it can promote out of labs.  I highly suspect someone will dust this off once we are in ASF, but always best to secure coding resource if you have the means to.

hope this helps,

-A

[Adrian Cole]

Nirmal,

I'm happy to keep it, if you clean it up and test it.  If you can't we can't just keep it around as it failed completely last time.  Are you willing to take this on personally?

-A

[Nirmal Fernando]

On Fri, Apr 26, 2013 at 9:43 PM, Adrian Cole <adrian...@gmail.com> wrote:

Nirmal,

I'm happy to keep it, if you clean it up and test it.  If you can't we can't just keep it around as it failed completely last time.  Are you willing to take this on personally?

I'd love to, only concern is time. How long can I have? :-)

[Adrian Cole]

you have until tomorrow night any timezone.  Starting the tests take less time than this email, I promise :)

from a fresh checkout of jclouds, do the following.

cd providers/stratogen-vcloud-mycloud

mvn -Dtest.stratogen-vcloud-mycloud.identity=USER@ORG -Dtest.stratogen-vcloud-mycloud.credential=PASSWORD -Plive clean install

Last time, this failed as the server wasn't running (connection refused errors).  If the tests pass, then you've no action to do.  If the tests fail, verify the endpoint is correct, and if not, run with the additional flag here, replacing with whatever is current: -Dtest.stratogen-vcloud-mycloud.endpoint=https://vcd.stratogen.net/api

If it is only an endpoint fail, that's a stupid easy pull request.  Can you report back on this?

-A

[Nirmal Fernando]

Let me give a try.

[Andrew Gaul]

I use synaptic-storage and it works for me.  However I am happy to use the generic atmos provider instead.

[Adrian Cole]

Ok.  Thanks for your support.  Ill remove this provider as even though it works in your tests it doesn't pass jclouds tests while other atmos providers do.  

In general, I hope folks understand my attempt to be objective and efficient with our time spent on maintenance and release testing.

Best,

-A

[Andrew Gaul]

Works for me.  The power-to-weight ratio of these configuration-only providers seems low: 601 lines of code to drive one endpoint!

On Friday, April 26, 2013 10:46:54 AM UTC-7, Adrian Cole wrote:

Ok.  Thanks for your support.  Ill remove this provider as even though it works in your tests it doesn't pass jclouds tests while other atmos providers do.  

In general, I hope folks understand my attempt to be objective and efficient with our time spent on maintenance and release testing.

Best,

-A

On Friday, April 26, 2013, Andrew Gaul wrote:

I use synaptic-storage and it works for me.  However I am happy to use the generic atmos provider instead.

On Friday, April 26, 2013 7:17:54 AM UTC-7, Adrian Cole wrote:

Hi, folks.

The following providers were completely dysfunctional as of last tests for system reasons:

stratogen-vcloud-mycloud

synaptic-storage

trystack-nova

https://github.com/jclouds/jclouds.github.com/blob/master/documentation/releasenotes/1.6-tests.md

In all cases, these are "configuration" providers, and don't have specialized code.  In the rare case someone resurrects these services, they can use use the bare "vcloud", "atmos", or "openstack-nova" apis with endpoints assigned.

We should remove them before 1.6.0 final, as we did other dysfunctional providers.  This lowers the build, test, and maintenance debt, but doesn't preclude users from using any of these services using bare apis.  Any suggestions to the contrary?

-A

--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jclouds-dev+unsubscribe@googlegroups.com.

[Adrian Cole]

Yep. Not only that, but a constant stream of maintenance and time lost analyzing test reports or checking on or unlocking accounts etc.  I'd say that best providers tend to be ones like rackspace who staff jclouds, and best after that are ones like elastichosts who consistently pass with few if any regressions over time.  

Synaptic has always been bottom of the barrel with no-one in the ATT ecosystem helping or even giving us an account and on too of that consistently poor test results.  It isn't an intentional thing, as it is possible no one knows, but regardless, providers like these are dead weight.

To unsubscribe from this group and stop receiving emails from it, send an email to jclouds-dev...@googlegroups.com.

[Adrian Cole]

OK, I don't think the following will be something you can work out, Nirmal.  Either there's a firewall now, or the server is no longer reachable:

$ telnet vcd.stratogen.net 443

Trying 109.233.49.135...

telnet: connect to address 109.233.49.135: Connection refused

telnet: Unable to connect to remote host

We need to be able to test the providers that are published in jclouds from any IP address.  This one hasn't worked in at least a couple months without any complaints, so I'm going to make a call to remove it.

Here are the only 2 parameters specific to stratogen:

when connecting with the "vcloud" api, specify whatever the replacement for https://vcd.stratogen.net/api is.

when creating vms, use VCloudTemplateOptions.ipAddressAllocationMode(IpAddressAllocationMode.POOL)

<general commentary>

As we get to ASF, I'd advise we hesitiate in general about making specialized providers for off-the-shelf products such as vcloud or atmos.  We should focus on configuration guides, which is a much more scalable idea, and more likely to be maintained by folks regardless of Java expertise.

</general commentary>

-A

[Nirmal Fernando]

Faced the same issue Adrian!

Ok, I agree, to remove specialized providers, as long as it is not necessary.

Sent via my mobile
-- Nirmal --

[Adrian Cole]

Cool.  thanks for validating it, Nirmal.

-A

[Steve Spink]

The correct address for the UK cloud is mycloud.stratogen.net 443.

 

Steve.

 

-A

 

Error! Filename not specified.