Volume Management - NFS Charm
Hi -- I've been looking to build a persistence story into the NFS charm, and I'm wondering if anyone else has thought of this problem before. I opted to use NFS since it exposes the mount interface, which allows a pretty easy use case from relating charms. I would expect that other file storage charms would use something like this even if the ideas are not quite fleshed out or uniform between charms yet. My ideas are as follows. 1) Expose config settings for cloud volumes in the nfs charm. cloud_credentials: base64 encoded shell script to source containing cloud credentials cloud_storage: pseudo-URL syntax for cloud storage device. E.g., swift://block-storage-id The hook would be smart enough to install the right package, and try to attach and mount the volume after sourcing the credentials file. The disadvantages are the hook is provider-specific, and would need to be expanded for other clouds to be generally useful. 2) A storage subordinate charm. E.g., swift-storage You would add this subordinate to the NFS service, and it would have the smarts to mount the block device at an agreed-upon location. The disadvantages involve waiting on the subordinate before the NFS charm is generally useful. I'm not sure how the mechanics of this would work. I really don't like either of the things I'm proposing, and was wondering what others thought about these ideas. Have you had any brainstorms about it? Have you come up with something better to try out? Please let me know. This seems to be a big missing puzzle piece in practical juju usage right now, and I would love to hear others thoughts (since I may be missing something). Thanks! -- David Britton david.brit...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: openstack hard depency or not
2013/11/17 Maarten Ectors maarten.ect...@canonical.com: Juju works on AWS, hp cloud, azure, etc. and very soon many more. If you use servers via MAAS then you can use containers to put multiple charms on one server. Each container has its own IP address hence different charms can listen to the same port without a conflict. Soon this same functionality will be available on more platforms. Maarten Thanks for answers. My new question is - does it possible to have one state server for all customers? I don't need to spawn sepaate state server for each customer deploy, but want to provide to it some log/pass/key to acces state server and use it. And does it possible to use OpenVZ instead of LXC? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Volume Management - NFS Charm
Sorry -- s/swift/nova-volume/ I have swift on the brain from another issue I'm working on! On Sun, Nov 17, 2013 at 11:17 AM, David Britton david.brit...@canonical.com wrote: Hi -- I've been looking to build a persistence story into the NFS charm, and I'm wondering if anyone else has thought of this problem before. I opted to use NFS since it exposes the mount interface, which allows a pretty easy use case from relating charms. I would expect that other file storage charms would use something like this even if the ideas are not quite fleshed out or uniform between charms yet. My ideas are as follows. 1) Expose config settings for cloud volumes in the nfs charm. cloud_credentials: base64 encoded shell script to source containing cloud credentials cloud_storage: pseudo-URL syntax for cloud storage device. E.g., swift://block-storage-id The hook would be smart enough to install the right package, and try to attach and mount the volume after sourcing the credentials file. The disadvantages are the hook is provider-specific, and would need to be expanded for other clouds to be generally useful. 2) A storage subordinate charm. E.g., swift-storage You would add this subordinate to the NFS service, and it would have the smarts to mount the block device at an agreed-upon location. The disadvantages involve waiting on the subordinate before the NFS charm is generally useful. I'm not sure how the mechanics of this would work. I really don't like either of the things I'm proposing, and was wondering what others thought about these ideas. Have you had any brainstorms about it? Have you come up with something better to try out? Please let me know. This seems to be a big missing puzzle piece in practical juju usage right now, and I would love to hear others thoughts (since I may be missing something). Thanks! -- David Britton david.brit...@canonical.com -- David Britton david.brit...@canonical.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: openstack hard depency or not
On 18/11/13 03:31, Vasiliy Tolstov wrote: My new question is - does it possible to have one state server for all customers? I don't need to spawn sepaate state server for each customer deploy, but want to provide to it some log/pass/key to acces state server and use it. That capability is planned over the next two cycles. And does it possible to use OpenVZ instead of LXC? Not yet, but patches are welcome! Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: openstack hard depency or not
2013/11/18 Mark Shuttleworth m...@ubuntu.com: That capability is planned over the next two cycles. And does it possible to use OpenVZ instead of LXC? Not yet, but patches are welcome! Fine. Next two cycles when they come in =)? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: openstack hard depency or not
2013/11/18 John Arbash Meinel j...@arbash-meinel.com: Given that you can run multiple services on a given machine, is there a strong reason that multiple state servers are a problem for you? (I want to make sure if there is a use case that is a problem our solution actually covers it.) As i see , clients that want wordpress or something else does not want to create unneeded things. After they installs wordpress (for example) they can test it and works with it. After sometime if all goes ok thet want to add load balancer and something new to it. But i don't think that all time they need state server. I think best of all spawn state server on demand. For example user interact with juju with provided keys, my own server (or such thinkg) check incoming key and spawn lxc container with state server and proxy to it (or this can be do it in state server itself). -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru jabber: v...@selfip.ru -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
