fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

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 <mscherbakov@xxxxxxxxxxxx>
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 <xarses@xxxxxxxxx> 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 <
>> dborodaenko@xxxxxxxxxxxx> 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
>>> <mscherbakov@xxxxxxxxxxxx> 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" <deaster@xxxxxxxxxxxx> 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 <ggalkin@xxxxxxxxxxxx>
>>> >> Organization: Mirantis Inc.
>>> >> Date: Thursday, January 16, 2014 at 11:28 PM
>>> >> To: <fuel-dev@xxxxxxxxxxxxxxxxxxx>
>>> >> 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" <xarses@xxxxxxxxx> 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 <eli@xxxxxxxxxxxx> 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
>>> >>>> <vsharshov@xxxxxxxxxxxx> 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 <dilyin@xxxxxxxxxxxx
>>> >
>>> >>>>> 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 <ggalkin@xxxxxxxxxxxx>
>>> >>>>>>>
>>> >>>>>>> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >>>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >>>>>>> More help   : https://help.launchpad.net/ListHelp
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --
>>> >>>>>> Mailing list: https://launchpad.net/~fuel-dev
>>> >>>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >>>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >>>>>> More help   : https://help.launchpad.net/ListHelp
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> --
>>> >>>>> Mailing list: https://launchpad.net/~fuel-dev
>>> >>>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >>>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >>>>> More help   : https://help.launchpad.net/ListHelp
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Mailing list: https://launchpad.net/~fuel-dev
>>> >>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >>>> 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     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >>> 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 :
>>> >> fuel-dev@xxxxxxxxxxxxxxxxxxx Unsubscribe :
>>> https://launchpad.net/~fuel-dev
>>> >> More help : https://help.launchpad.net/ListHelp
>>> >>
>>> >> --
>>> >> Mailing list: https://launchpad.net/~fuel-dev
>>> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> >> Unsubscribe : https://launchpad.net/~fuel-dev
>>> >> More help   : https://help.launchpad.net/ListHelp
>>> >>
>>> >
>>> > --
>>> > Mailing list: https://launchpad.net/~fuel-dev
>>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~fuel-dev
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>>
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> 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