Looks like we don't need this feature, as no one is willing to create a blueprint?
On Mon, Feb 17, 2014 at 12:58 PM, Mike Scherbakov <[email protected]> wrote: > Folks, anyone would volunteer for creating blueprint with a good > description, and summarize our thoughts on this topic in etherpad? > > > On Tue, Jan 21, 2014 at 3:01 AM, Andrew Woodward <[email protected]> wrote: > >> The empty role is needed for both mine and Gleb's use case, It's needed >> to do things like deploy stand-alone swift like we used to in 3.1 >> >> >> On Fri, Jan 17, 2014 at 2:57 PM, Dmitry Borodaenko < >> [email protected]> wrote: >> >>> Mike, >>> >>> According to what Andrew has found out it's even worse: you can't even >>> provision a node without a role, because the partition manager expects >>> Cobbler to provide disk allocation information (ks_spaces) that is >>> generated based on roles assigned to the node and isn't generated at >>> all if no role was assigned. Provisioning would fail at disk >>> partitioning stage. >>> >>> -DmitryB >>> >>> On Fri, Jan 17, 2014 at 2:21 PM, Mike Scherbakov >>> <[email protected]> wrote: >>> > >>> > Now I understand your use case, folks. In current version of Fuel you >>> can >>> > add nodes to the env with a certain roles assigned only. I.e. you can >>> not >>> > have a node in the environment which has no role at all. Then, you can >>> split >>> > your actions into two stages: provisioning of nodes in the env, and >>> you will >>> > get bare operating system installed with minimal Fuel pieces; and >>> > deployment, when roles assigned to servers will be applied. >>> > Gleb's use case is a bit different. He wants to have an environment >>> which >>> > would have N nodes deployed a certain roles and M nodes only bare >>> operating >>> > system. This is not achievable at the moment: when you deploy N nodes >>> with >>> > certain roles, you can't specify that other M nodes do not require any >>> > components on them. You could do it though via CLI, I'm not even sure, >>> but >>> > that would be hacky anyway. >>> > >>> > Gleb, does it sound correct? >>> > >>> > On Jan 17, 2014 9:46 PM, "David Easter" <[email protected]> wrote: >>> >> >>> >> I agree with Mike that this requirement looks to be already >>> implemented >>> >> with the ability separate the provisioning between Cobbler and Puppet >>> (i.e. >>> >> Operating System and OpenStack components). Is there something not >>> >> accomplished through this existing capability? >>> >> >>> >> Thanks, >>> >> >>> >> -Dave Easter >>> >> >>> >> From: Gleb Galkin <[email protected]> >>> >> Organization: Mirantis Inc. >>> >> Date: Thursday, January 16, 2014 at 11:28 PM >>> >> To: <[email protected]> >>> >> Subject: Re: [Fuel-dev] feature request: Empty role >>> >> >>> >> On 17.01.2014 04:05, Mike Scherbakov wrote: >>> >> >>> >> Folks, sorry, but I don't quite get your use cases. We can do >>> separated >>> >> provisioning from CLI (and REST API obviously), and you will get nodes >>> >> without any OpenStack components deployed on them. All nodes will be >>> >> provisioned, and you can proceed with manual deployment after this. >>> >> Now, if you want to deploy some nodes, but not to touch some other >>> >> provisioned, then we can't do it now. Deployment will be applied to >>> all >>> >> nodes, and you can't have node without a role on it now. Is it the >>> case you >>> >> guys talk about? Do I understand right the current implementation? >>> >> >>> >> My point was about provisioning OpenStack nodes and nodes without any >>> >> OpenStack component simultaneously. >>> >> For example I need standart Mirantis OpenStack + Standalone Swift >>> (which >>> >> can't be deployed by Fuel). >>> >> Fuel can't deploy standalone Swift, but it can provision node for >>> further >>> >> manual deployment. >>> >> >>> >> Or I already have deployed cloud and I want to add bunch of nodes >>> without >>> >> OpenStack components. >>> >> This use case is vital too. >>> >> >>> >> Thanks, >>> >> >>> >> On Jan 16, 2014 9:03 PM, "Andrew Woodward" <[email protected]> wrote: >>> >>> >>> >>> I've been thinking about this empty role for a while now, I think its >>> >>> necessary for us to provide until we can handle granular roles >>> better. >>> >>> >>> >>> >>> >>> On Thu, Jan 16, 2014 at 4:07 AM, Evgeniy L <[email protected]> wrote: >>> >>>> >>> >>>> Afaik, it's not so hard to add new (empty) role right now. >>> >>>> >>> >>>> 1. you need to add new role in json file >>> >>>> >>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.json#L19-L39 >>> >>>> >>> >>>> (pay attention that we have different parameters for each OS) >>> >>>> >>> >>>> 2. create default volume partitioning for your role >>> >>>> >>> >>>> >>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.json#L173-L189 >>> >>>> >>> >>>> 3. and then upload fixture back to nailgun (or change them directly >>> in >>> >>>> DB) >>> >>>> >>> >>>> 4. add deployment order >>> >>>> Multinode >>> >>>> >>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L122-L132 >>> >>>> HA >>> >>>> >>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py#L269-L300 >>> >>>> >>> >>>> 5. fix puppet manifests for you role (or just use separate >>> provisioning >>> >>>> to provision without deployment) >>> >>>> >>> >>>> I'm not sure that UI will work correctly, but I think you will be >>> able >>> >>>> to deploy env via CLI. >>> >>>> >>> >>>> >>> >>>> On Thu, Jan 16, 2014 at 3:29 PM, Vladimir Sharshov >>> >>>> <[email protected]> wrote: >>> >>>>> >>> >>>>> If i correctly understand, we can not add nodes to cluster without >>> >>>>> role. This fact block adding nodes with custom user configuration >>> in >>> >>>>> cluster, because when we start deploy, fake roles(without it nodes >>> can not >>> >>>>> be added to cluster) will be applied for this nodes. >>> >>>>> In this case "Basic" or "Empty" role can help users to provision >>> and >>> >>>>> deploy custom nodes in Fuel cluster. Also can be useful ability to >>> change >>> >>>>> roles for nodes after provision but before deploy. >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> On Thu, Jan 16, 2014 at 2:39 PM, Dmitry Ilyin <[email protected] >>> > >>> >>>>> wrote: >>> >>>>>> >>> >>>>>> Yes, basic role would be a good idea. But now our concept of node >>> >>>>>> roles if far from being flexible. >>> >>>>>> We have a project to make deployment process granular and it will >>> make >>> >>>>>> custom roles possible. >>> >>>>>> Then there could be basic empty node and we would be able to add >>> some >>> >>>>>> roles to it >>> >>>>>> or no roles if you would choose so. >>> >>>>>> >>> >>>>>> >>> >>>>>> 2014/1/16 Gleb Galkin <[email protected]> >>> >>>>>>> >>> >>>>>>> Hello people, >>> >>>>>>> >>> >>>>>>> I think we need an "Empty Role" in FUEL. >>> >>>>>>> In case that you need to provision OS and install mcollective >>> without >>> >>>>>>> syncing the manifests and running puppet agent. >>> >>>>>>> >>> >>>>>>> For example I have a project with Swift standalone. And I need to >>> >>>>>>> provision OS to the bunch of nodes for further manual >>> installation. >>> >>>>>>> It looks convenient to have an empty role in this situation. >>> >>>>>>> Please consider it. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -- >>> >>>>>>> Best Regards, >>> >>>>>>> Gleb Galkin >>> >>>>>>> OpenStack Deployment Engineer >>> >>>>>>> >>> >>>>>>> Mirantis Inc. >>> >>>>>>> www.mirantis.com >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> -- >>> >>>>>>> Mailing list: https://launchpad.net/~fuel-dev >>> >>>>>>> Post to : [email protected] >>> >>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>> >>>>>>> More help : https://help.launchpad.net/ListHelp >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> -- >>> >>>>>> Mailing list: https://launchpad.net/~fuel-dev >>> >>>>>> Post to : [email protected] >>> >>>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>> >>>>>> More help : https://help.launchpad.net/ListHelp >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Mailing list: https://launchpad.net/~fuel-dev >>> >>>>> Post to : [email protected] >>> >>>>> Unsubscribe : https://launchpad.net/~fuel-dev >>> >>>>> More help : https://help.launchpad.net/ListHelp >>> >>>>> >>> >>>> >>> >>>> >>> >>>> -- >>> >>>> Mailing list: https://launchpad.net/~fuel-dev >>> >>>> Post to : [email protected] >>> >>>> Unsubscribe : https://launchpad.net/~fuel-dev >>> >>>> More help : https://help.launchpad.net/ListHelp >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> If google has done it, Google did it right! >>> >>> >>> >>> -- >>> >>> Mailing list: https://launchpad.net/~fuel-dev >>> >>> Post to : [email protected] >>> >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> >>> More help : https://help.launchpad.net/ListHelp >>> >>> >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Best Regards, >>> >> Gleb Galkin >>> >> OpenStack Deployment Engineer >>> >> >>> >> Mirantis Inc. >>> >> www.mirantis.com >>> >> >>> >> -- Mailing list: https://launchpad.net/~fuel-dev Post to : >>> >> [email protected] Unsubscribe : >>> https://launchpad.net/~fuel-dev >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> >> -- >>> >> Mailing list: https://launchpad.net/~fuel-dev >>> >> Post to : [email protected] >>> >> Unsubscribe : https://launchpad.net/~fuel-dev >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> > >>> > -- >>> > Mailing list: https://launchpad.net/~fuel-dev >>> > Post to : [email protected] >>> > Unsubscribe : https://launchpad.net/~fuel-dev >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> >>> >>> >>> -- >>> Dmitry Borodaenko >>> >>> -- >>> Mailing list: https://launchpad.net/~fuel-dev >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~fuel-dev >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> -- >> If google has done it, Google did it right! >> > > > > -- > Mike Scherbakov > #mihgen > -- Mike Scherbakov #mihgen
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
