Re: Questions about the integration of the Outscale cloud provider into juju-core
The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote : Two things: 1.) There's no inheritance in Go (though you can still reuse functionality in a number of ways). 2.) Juju is open source. There's no reason why the Outscale provider can't use the ec2 implementation from an external repo. Hello, I saw that names of the types defined by the ec2 implementation where not capitalized. So I conclude that they are not exported. How can I reuse the most of EC2 bits in the outscale provider ? Best regards Benoît Being in core grants the provider code no special benefits other than ensuring that the code gets compiled and tested with the rest of the code. If we start having providers external to core, we'd work more carefully to keep the provider interface stable, or at least backwards compatible. On Wed, May 7, 2014 at 1:01 PM, Benoît Canet benoit.ca...@irqsave.netwrote: The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote : There seems to be no compelling reason why we can't distribute more than just juju and jujud. However, I don't think there's anything to gain by splitting out the providers we already have in core. Adding code that enables pluggable providers seems like a no-brainer to let people provide their own interface for their own cloud (whether it's a private cloud or simply one of the public ones we don't yet support). Would not it be better for the Outscale provider to be in core so it can inherit from the EC2 driver and only implement the differences ? Best regards Benoît Yes, the manual provider sort of works now, but it is so incredibly *manual *that I hesitate to even call it a solution for all but the most limited of use cases. On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. Oh. I think we already have this problem. Windows users cannot backup, restore or generate metadata because they only have the juju CLI binary installed. OSX users may have the current plugins since juju was built by brew, but I have not tested they work. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. Oh. I think we already have this problem. Windows users cannot backup, restore or generate metadata because they only have the juju CLI binary installed. OSX users may have the current plugins since juju was built by brew, but I have not tested they work. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
There seems to be no compelling reason why we can't distribute more than just juju and jujud. However, I don't think there's anything to gain by splitting out the providers we already have in core. Adding code that enables pluggable providers seems like a no-brainer to let people provide their own interface for their own cloud (whether it's a private cloud or simply one of the public ones we don't yet support). Yes, the manual provider sort of works now, but it is so incredibly *manual *that I hesitate to even call it a solution for all but the most limited of use cases. On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. Oh. I think we already have this problem. Windows users cannot backup, restore or generate metadata because they only have the juju CLI binary installed. OSX users may have the current plugins since juju was built by brew, but I have not tested they work. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote : There seems to be no compelling reason why we can't distribute more than just juju and jujud. However, I don't think there's anything to gain by splitting out the providers we already have in core. Adding code that enables pluggable providers seems like a no-brainer to let people provide their own interface for their own cloud (whether it's a private cloud or simply one of the public ones we don't yet support). Would not it be better for the Outscale provider to be in core so it can inherit from the EC2 driver and only implement the differences ? Best regards Benoît Yes, the manual provider sort of works now, but it is so incredibly *manual *that I hesitate to even call it a solution for all but the most limited of use cases. On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. Oh. I think we already have this problem. Windows users cannot backup, restore or generate metadata because they only have the juju CLI binary installed. OSX users may have the current plugins since juju was built by brew, but I have not tested they work. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
We certainly welcome more provider implementations to be part of core. We've been working with a couple of other people in doing just that (Joyent support was recently contributed by them, and there are a few others being worked on today). Most of the provider implementations we have today are split into 2 code bases. 1 provides the basic exposure of a cloud (goamz for EC2, goose for Openstack, gomaasapi for MaaS), and then the actual Provider implementation binds our Juju interface into calls to the provider. If Outscale really does look like EC2, then it could certainly share the goamz library at the least. If you want it to be if you have Juju, you can control an Outscale environment then you certainly would want to have the code in core. We don't yet have a way to have an external provider that looks the same as everything else. Kapil has done some interesting work in providing a plugin that looks a lot like the rest, but in the end it does still have to re-implement some of the commands (so you run 'juju PROVIDER command', instead of just 'juju command'). As for details on implementation, I would probably look to have another provider/outscale directory that would be the actual implementation of the bits we need. Where possible, you could pull out shared implementations from the provider/ec2 implementation, but because of things like not having s3 storage you'd probably be better off with a fully different provider. John =:- On Wed, May 7, 2014 at 9:23 PM, Benoît Canet benoit.ca...@irqsave.netwrote: The Wednesday 07 May 2014 à 13:11:14 (-0400), Nate Finch wrote : Two things: 1.) There's no inheritance in Go (though you can still reuse functionality in a number of ways). 2.) Juju is open source. There's no reason why the Outscale provider can't use the ec2 implementation from an external repo. Being in core grants the provider code no special benefits other than ensuring that the code gets compiled and tested with the rest of the code. If we start having providers external to core, we'd work more carefully to keep the provider interface stable, or at least backwards compatible. Aside from my fears of bitrot would an external provider be properly packaged into Ubuntu ? (I really want the support to be as official as possible) Best regards Benoît On Wed, May 7, 2014 at 1:01 PM, Benoît Canet benoit.ca...@irqsave.net wrote: The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote : There seems to be no compelling reason why we can't distribute more than just juju and jujud. However, I don't think there's anything to gain by splitting out the providers we already have in core. Adding code that enables pluggable providers seems like a no-brainer to let people provide their own interface for their own cloud (whether it's a private cloud or simply one of the public ones we don't yet support). Would not it be better for the Outscale provider to be in core so it can inherit from the EC2 driver and only implement the differences ? Best regards Benoît Yes, the manual provider sort of works now, but it is so incredibly *manual *that I hesitate to even call it a solution for all but the most limited of use cases. On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins andrew.wilk...@canonical.com wrote: A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. Oh. I think we already have this problem. Windows users cannot backup, restore or generate metadata because they only have the juju CLI binary installed. OSX users may have the current plugins since juju was built by brew, but I have not tested they work. -- Curtis Hovey Canonical Cloud Development and Operations http://launchpad.net/~sinzui -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com
Re: Questions about the integration of the Outscale cloud provider into juju-core
Yeah, unfortunately the remote provider and hence local provider improvements that I wanted has been bumped for this cycle. It is possible that some work will be done to improve the writing of providers but it will be slow and a non-primary task. With regard to local storage, yes, this cycle (next six months) one of the main tasks is to remove the need for cloud local storage. This is on my list of things, and needs some more thought and breakdown for the non-charm bits. We use local storage for a few extra cache points: bootstrap notification, api end points, tool caching, as well as keeping the charms. One thing that you can use to get started, is to do what the local and manual provider use, which is an http storage worker. Effectively the bootstrap node acts as a storage provider and is just backed by the local file system. A big caveat here is that this means it is not highly available - however it would allow the provider to work, and as we move the local storage requirements, the provider could change too, just as we will for the local and manual providers. Cheers, Tim On 07/05/14 05:59, Nate Finch wrote: Yeah, using a command line application to talk to a provider seems like the best way to go. That's the usual way to make things pluggable in Go, and fits our use cases quite well. It's definitely something I think we should do, but I'm not sure it's that high on the priority list right now. On Tue, May 6, 2014 at 12:36 AM, John Meinel j...@arbash-meinel.com mailto:j...@arbash-meinel.com wrote: I'll also note that Tim had some good ideas about how to change the Local provider to be more consistent with other providers. (Essentially creating a separate process that could implement a Remote Provider sort of interface.) That could allow bringing up more 'pluggable' providers that just talk the same language as the 'local' one would. I personally would prefer if we used a command line interface (call this process with these arguments to start an instance), even if the local one would use the command line to make RPC/socket calls to another process. (If you think about it, all of them are just sending requests to some other long-lived process over a socket, but I'd rather not have to run a full service for every system we want to interact with.) John =:- On Tue, May 6, 2014 at 8:33 AM, John Meinel j...@arbash-meinel.com mailto:j...@arbash-meinel.com wrote: There is work being done this cycle to switch from using storage from the Provider to instead using our own internal storage. I don't know that the work will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage internally. John =:- On Tue, May 6, 2014 at 8:24 AM, Benoît Canet benoit.ca...@irqsave.net mailto:benoit.ca...@irqsave.net wrote: The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.net mailto:benoit.ca...@irqsave.netwrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com mailto:Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju --
Re: Questions about the integration of the Outscale cloud provider into juju-core
The Wednesday 07 May 2014 à 10:38:44 (+1200), Tim Penhey wrote : Yeah, unfortunately the remote provider and hence local provider improvements that I wanted has been bumped for this cycle. It is possible that some work will be done to improve the writing of providers but it will be slow and a non-primary task. With regard to local storage, yes, this cycle (next six months) one of the main tasks is to remove the need for cloud local storage. This is on my list of things, and needs some more thought and breakdown for the non-charm bits. We use local storage for a few extra cache points: bootstrap notification, api end points, tool caching, as well as keeping the charms. One thing that you can use to get started, is to do what the local and manual provider use, which is an http storage worker. Effectively the bootstrap node acts as a storage provider and is just backed by the local file system. A big caveat here is that this means it is not highly available - however it would allow the provider to work, and as we move the local storage requirements, the provider could change too, just as we will for the local and manual providers. Would this be mergeable ? Do you have code urls talking about the http storage worker (both server and client) ? Best regards Benoît Cheers, Tim On 07/05/14 05:59, Nate Finch wrote: Yeah, using a command line application to talk to a provider seems like the best way to go. That's the usual way to make things pluggable in Go, and fits our use cases quite well. It's definitely something I think we should do, but I'm not sure it's that high on the priority list right now. On Tue, May 6, 2014 at 12:36 AM, John Meinel j...@arbash-meinel.com mailto:j...@arbash-meinel.com wrote: I'll also note that Tim had some good ideas about how to change the Local provider to be more consistent with other providers. (Essentially creating a separate process that could implement a Remote Provider sort of interface.) That could allow bringing up more 'pluggable' providers that just talk the same language as the 'local' one would. I personally would prefer if we used a command line interface (call this process with these arguments to start an instance), even if the local one would use the command line to make RPC/socket calls to another process. (If you think about it, all of them are just sending requests to some other long-lived process over a socket, but I'd rather not have to run a full service for every system we want to interact with.) John =:- On Tue, May 6, 2014 at 8:33 AM, John Meinel j...@arbash-meinel.com mailto:j...@arbash-meinel.com wrote: There is work being done this cycle to switch from using storage from the Provider to instead using our own internal storage. I don't know that the work will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage internally. John =:- On Tue, May 6, 2014 at 8:24 AM, Benoît Canet benoit.ca...@irqsave.net mailto:benoit.ca...@irqsave.net wrote: The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.net mailto:benoit.ca...@irqsave.netwrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards
Re: Questions about the integration of the Outscale cloud provider into juju-core
On Tue, May 6, 2014 at 12:36 PM, John Meinel j...@arbash-meinel.com wrote: I'll also note that Tim had some good ideas about how to change the Local provider to be more consistent with other providers. (Essentially creating a separate process that could implement a Remote Provider sort of interface.) That could allow bringing up more 'pluggable' providers that just talk the same language as the 'local' one would. I personally would prefer if we used a command line interface (call this process with these arguments to start an instance), even if the local one would use the command line to make RPC/socket calls to another process. (If you think about it, all of them are just sending requests to some other long-lived process over a socket, but I'd rather not have to run a full service for every system we want to interact with.) John =:- A bit tangential now, but... Plugin-style was originally how I thought it would best work, but that requires distribution with both jujud *and* the juju CLI. That sounds like a nightmare to me. OTOH, having a remote service means you can just point the CLI and jujud at that remote service with nothing to distribute. It does mean having a service, which brings its own set of issues. Of course, the two approaches are not mutually exclusive. As you say, you could easily provide a plugin that talks to a remote service. On Tue, May 6, 2014 at 8:33 AM, John Meinel j...@arbash-meinel.com wrote: There is work being done this cycle to switch from using storage from the Provider to instead using our own internal storage. I don't know that the work will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage internally. John =:- On Tue, May 6, 2014 at 8:24 AM, Benoît Canet benoit.ca...@irqsave.netwrote: The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.netwrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
I'd probably start here: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/ This can give you an idea on how the ec2 implementation is done On Mon, May 5, 2014 at 10:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- [ Adam Stokes ] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
Taking the opportunity about this topic, what about making this pluggable, like providers plugins, not into the core? Sebas. 2014-05-05 18:44 GMT-03:00 Adam Stokes adam.sto...@ubuntu.com: I'd probably start here: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/ This can give you an idea on how the ec2 implementation is done On Mon, May 5, 2014 at 10:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- [ Adam Stokes ] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
its come up before (rpc providers, shell script providers) but it doesn't quite fit with the upgrade and distribution model in juju-core and go atm. it is possible to layer on top of manual provider using a client side plugin to effectively automate machine creation for a given provider, i've published digital ocean and softlayer providers using that mechanism, it has some caveats compared to a native provider, but its still useful and functional. cheers, Kapil On Mon, May 5, 2014 at 6:12 PM, Sebastian sebas5...@gmail.com wrote: Taking the opportunity about this topic, what about making this pluggable, like providers plugins, not into the core? Sebas. 2014-05-05 18:44 GMT-03:00 Adam Stokes adam.sto...@ubuntu.com: I'd probably start here: http://bazaar.launchpad.net/~go-bot/juju-core/trunk/files/head:/provider/ This can give you an idea on how the ec2 implementation is done On Mon, May 5, 2014 at 10:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- [ Adam Stokes ] -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.netwrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
There is work being done this cycle to switch from using storage from the Provider to instead using our own internal storage. I don't know that the work will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage internally. John =:- On Tue, May 6, 2014 at 8:24 AM, Benoît Canet benoit.ca...@irqsave.netwrote: The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Questions about the integration of the Outscale cloud provider into juju-core
I'll also note that Tim had some good ideas about how to change the Local provider to be more consistent with other providers. (Essentially creating a separate process that could implement a Remote Provider sort of interface.) That could allow bringing up more 'pluggable' providers that just talk the same language as the 'local' one would. I personally would prefer if we used a command line interface (call this process with these arguments to start an instance), even if the local one would use the command line to make RPC/socket calls to another process. (If you think about it, all of them are just sending requests to some other long-lived process over a socket, but I'd rather not have to run a full service for every system we want to interact with.) John =:- On Tue, May 6, 2014 at 8:33 AM, John Meinel j...@arbash-meinel.com wrote: There is work being done this cycle to switch from using storage from the Provider to instead using our own internal storage. I don't know that the work will be done for another few months, though. I believe Tim Penhey is going to be leading up that work as part of exposing Resources for charms to consume. I'm sure he'd be happy to coordinate with someone who wants to work on moving us over to having storage internally. John =:- On Tue, May 6, 2014 at 8:24 AM, Benoît Canet benoit.ca...@irqsave.netwrote: The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote : from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix its a little unclear if outscale implements object storage compatible with s3. if so then support in core would probably amount to making the ec2/s3 api endpoint url pluggable in the core code, along with userdata support and cloudinit and compatible os images in outscale cloud. From what I know Outscale implement only EC2 compute: no object storage. How could we work around this ? Best regards Benoît cheers, Kapil On Mon, May 5, 2014 at 11:56 AM, Benoît Canet benoit.ca...@irqsave.net wrote: Hello, I am a developper planning to add the support for the Outscale cloud into juju-core. The Outscale cloud implement most of the EC2 API. Does the Juju maintainer have some guidance on how the support should be written ? Best regards Benoît Canet Nodalink -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
