Let me preface this by letting you know that I have tested and demoed 2 or 3 handfulls of different methods to deploy, automate, configure and maintain Openstack at a production level. I chose to use Juju for my company's method of Openstack orchestration and have been deep diving how to make this whole thing work for quite some time now. Despite my difficulties along the way(and current) I still feel that configuring, deploying, and maintaining is best done with Juju due to its open, pluggable architecture, and durable framework/environment for managing/adding/creating/destroying cloud based services on almost any and every platform. To that end, after spending some time configuring Openstack's services networking through the the use of juju charm configuration parameters, I can say that I am impressed with the high level of configurability offered at an abstracted level through juju charms. The open, abstracted and highly configurable networking parameters of juju charms I feel can also be harmful to some degree when questions must be answered that one (without immense effort and time) does not readily know the answer to because of the abstractedness or magic of the charm that protects us from the highly undesirable details of openstack configuration(JJ.. I was raised on hand rolled stacks :-). To this I attribute that fact that abstraction has became a limitation.
I'm trying to see if there is a way we (the community) can get some kind of possible configuration mappings between openstack service charms and possible network configurations? I am fully aware of what services talk to one another and by what means when I hand roll a stack because I configure each parameter of each service myself.....but when planning a deployment -- designing and testing networking infrastructure to be placed in a production environment.....lets just say the magic of the charms ....it wears thin quick....I now spend most of my days reading charm code (excellently written and designed might I say), network troubleshooting, openstack service investigations, and trying to create workarounds for things I cannot figure out by the aforementioned methods. <-- Instead of leading my company to a production ready juno stack...I have now been configuring/testing Juju deploys all the way to (almost) kilo...which is actually great because now I will have one less production stack upgrade to do... I feel that myself as well as others will derive great benefit in planning, testing, and maintaining openstack deployments using Juju might we be aided by a simple, highly available "Juju-Openstack service charms network configuration references, information and limitations" <-- might depict what the limitations, possibilities, and reference configurations exist for a few popular openstack network configurations offered by the juju charms, i.e. what services talk over what networks when configuration A,B,C or D is used, separating storage traffic when deploying with juju charms configs, network address space segmentation on a flat network, multi-net configs, how many interfaces, what traffic talks where when.... You get my point (hopefully). I'm not looking for a what, when, where, who, how, why on all of openstack networking........but possibly just a what, when, where, who, how, why on openstack networking using Juju. This is the use case I am describing that would/could be answered by juju given some direction exists for network config: https://www.dropbox.com/s/11e7kjginiofd0d/Screenshot%202015-03-18%2001.37.42.png?dl=0 (nothing to do with mellanox or fuel...just wanted to emphasize the verify networks functionality) EDIT: This sounds more and more like a feature request for the openstack-installer!! Please do not take this the wrong way, I am very thankful for the outstanding software you all create....I only hope this can help make it even better.
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
