Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
Hi, Ok, looks like everybody agree that we should implement similar approach for plugins. But I'm not sure if we should implicitly assume that primary is set if there is only 'controller', in this case we won't be able to run some tasks on controllers only. Thanks, On Thu, Jan 29, 2015 at 1:05 AM, Andrew Woodward xar...@gmail.com wrote: On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 for having primary-controller role in terms of deployment. Yes, we need to continue to be able to differentiate the difference between the first node in a set of roles, and all the others. For controllers we have logic around how the services start, and if we attempt to create resources. This allows the deployment to run more smoothly. For mongo the logic is used to setup the primary vs backup data nodes. For plugins I would expect to continue to see this kind of need and would need to be able to expose a similar logic when adding roles / tasks I'm however not sure that we need to do this with some kind of role, this could simply be some parameter that we then use to set the conditional that we use to apply primary logic already. Alternately, this could cause the inclusion of 'primary' or 'first node' tasks that would do these specific work with out the presence of the conditional to run this testing In our tasks user should be able to run specific task on primary-controller. But I agree that it can be tricky because after the cluster is deployed, we cannot say who is really primary, is there a case when it's important to know who is really primary after deployment is done? for mongo, its important to find out who is currently the primary prior to deployment starting (which may not have been the primary that the deployment started with) So it may be special in it's case. for controller, its irrelevant as long as it's not set to a newly added node (a node with a lower node.id will cause this and create problems) Also I would like to mention that in plugins user currently can write 'roles': ['controller'], which means that the task will be applied on 'controller' and 'primary-controller' nodes. Plugin developer can get this information from astute.yaml file. But I'm curious if we should change this behaviour for plugins (with backward compatibility of course)? writing roles: ['controller'] should apply to all controllers as expected, with the addition of roles: ['primary-controller'] only applying to the primary controller. Thanks, On Wed, Jan 28, 2015 at 1:07 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, we definitely need such separation on orchestration layer. Is it possible to have significantly different sets of tasks for controller and primary-controller? Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and controlled by conditionals inside the manifest. So when we split our tasks into smaller ones, we may want/need to separate them for primary and secondary controllers. I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework Sergii, we still need this separation on the orchestration layer and, as you know, our deployment process is based on it. Currently we already have separate task groups for primary and secondary controller roles. So it will be up to the task developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task. -- Regards, Aleksandr Didenko On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long time). Lets say we have task A that is mapped to primary-controller and B that is mapped to secondary controller, task B requires task A. If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers. And how in such case deployment code will know that it should not execute commands in task A for secondary controllers and in task B on primary ? On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long time). Lets say we have task A that is mapped to primary-controller and B that is mapped to secondary controller, task B requires task A. If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers. And how in such case deployment code will know that it should not execute commands in task A for secondary controllers and in task B on primary ? On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, *But with introduction of plugins and granular deployment, in my opinion, we need to be able* *to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not.* I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hello all, You may know that for deployment configuration we are serializing additional prefix for controller role (primary), with the goal of deployment order control (primary-controller always should be deployed before secondaries) and some condiions in fuel-library code. However, we cannot guarantee that primary controller will be always the same node, because it is not business of nailgun to control elections of primary. Essentially user should not rely on nailgun information to find primary, but we need to persist node elected as primary in first deployment to resolve orchestration issues (when new node added to cluster we should not mark it as primary). So we called primary-controller - internal role, which means that it is not exposed to users (or external developers). But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not. Is it possible to have significantly different sets of tasks for controller and primary-controller? And same goes for mongo, and i think we had primary for swift also. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
Hi, *But with introduction of plugins and granular deployment, in my opinion, we need to be able* *to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not.* I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hello all, You may know that for deployment configuration we are serializing additional prefix for controller role (primary), with the goal of deployment order control (primary-controller always should be deployed before secondaries) and some condiions in fuel-library code. However, we cannot guarantee that primary controller will be always the same node, because it is not business of nailgun to control elections of primary. Essentially user should not rely on nailgun information to find primary, but we need to persist node elected as primary in first deployment to resolve orchestration issues (when new node added to cluster we should not mark it as primary). So we called primary-controller - internal role, which means that it is not exposed to users (or external developers). But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not. Is it possible to have significantly different sets of tasks for controller and primary-controller? And same goes for mongo, and i think we had primary for swift also. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
Hi, we definitely need such separation on orchestration layer. Is it possible to have significantly different sets of tasks for controller and primary-controller? Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and controlled by conditionals inside the manifest. So when we split our tasks into smaller ones, we may want/need to separate them for primary and secondary controllers. I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework Sergii, we still need this separation on the orchestration layer and, as you know, our deployment process is based on it. Currently we already have separate task groups for primary and secondary controller roles. So it will be up to the task developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task. -- Regards, Aleksandr Didenko On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long time). Lets say we have task A that is mapped to primary-controller and B that is mapped to secondary controller, task B requires task A. If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers. And how in such case deployment code will know that it should not execute commands in task A for secondary controllers and in task B on primary ? On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, *But with introduction of plugins and granular deployment, in my opinion, we need to be able* *to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not.* I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hello all, You may know that for deployment configuration we are serializing additional prefix for controller role (primary), with the goal of deployment order control (primary-controller always should be deployed before secondaries) and some condiions in fuel-library code. However, we cannot guarantee that primary controller will be always the same node, because it is not business of nailgun to control elections of primary. Essentially user should not rely on nailgun information to find primary, but we need to persist node elected as primary in first deployment to resolve orchestration issues (when new node added to cluster we should not mark it as primary). So we called primary-controller - internal role, which means that it is not exposed to users (or external developers). But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not. Is it possible to have significantly different sets of tasks for controller and primary-controller? And same goes for mongo, and i think we had primary for swift also. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
Hi, +1 for having primary-controller role in terms of deployment. In our tasks user should be able to run specific task on primary-controller. But I agree that it can be tricky because after the cluster is deployed, we cannot say who is really primary, is there a case when it's important to know who is really primary after deployment is done? Also I would like to mention that in plugins user currently can write 'roles': ['controller'], which means that the task will be applied on 'controller' and 'primary-controller' nodes. Plugin developer can get this information from astute.yaml file. But I'm curious if we should change this behaviour for plugins (with backward compatibility of course)? Thanks, On Wed, Jan 28, 2015 at 1:07 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, we definitely need such separation on orchestration layer. Is it possible to have significantly different sets of tasks for controller and primary-controller? Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and controlled by conditionals inside the manifest. So when we split our tasks into smaller ones, we may want/need to separate them for primary and secondary controllers. I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework Sergii, we still need this separation on the orchestration layer and, as you know, our deployment process is based on it. Currently we already have separate task groups for primary and secondary controller roles. So it will be up to the task developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task. -- Regards, Aleksandr Didenko On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long time). Lets say we have task A that is mapped to primary-controller and B that is mapped to secondary controller, task B requires task A. If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers. And how in such case deployment code will know that it should not execute commands in task A for secondary controllers and in task B on primary ? On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, *But with introduction of plugins and granular deployment, in my opinion, we need to be able* *to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not.* I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hello all, You may know that for deployment configuration we are serializing additional prefix for controller role (primary), with the goal of deployment order control (primary-controller always should be deployed before secondaries) and some condiions in fuel-library code. However, we cannot guarantee that primary controller will be always the same node, because it is not business of nailgun to control elections of primary. Essentially user should not rely on nailgun information to find primary, but we need to persist node elected as primary in first deployment to resolve orchestration issues (when new node added to cluster we should not mark it as primary). So we called primary-controller - internal role, which means that it is not exposed to users (or external developers). But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not. Is it possible to have significantly different sets of tasks for controller and primary-controller? And same goes for mongo, and i think we had primary for swift also. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
Also I would like to mention that in plugins user currently can write 'roles': ['controller'], which means that the task will be applied on 'controller' and 'primary-controller' nodes. Plugin developer can get this information from astute.yaml file. But I'm curious if we should change this behaviour for plugins (with backward compatibility of course)? In my opinion we should make interface for task description identical for plugins and for library, and if this separation makes sense for library, there will be cases when it will be expected by plugin developer as well. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Plugins][Orchestration] Unclear handling of primary-controler and controller roles
On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 for having primary-controller role in terms of deployment. Yes, we need to continue to be able to differentiate the difference between the first node in a set of roles, and all the others. For controllers we have logic around how the services start, and if we attempt to create resources. This allows the deployment to run more smoothly. For mongo the logic is used to setup the primary vs backup data nodes. For plugins I would expect to continue to see this kind of need and would need to be able to expose a similar logic when adding roles / tasks I'm however not sure that we need to do this with some kind of role, this could simply be some parameter that we then use to set the conditional that we use to apply primary logic already. Alternately, this could cause the inclusion of 'primary' or 'first node' tasks that would do these specific work with out the presence of the conditional to run this testing In our tasks user should be able to run specific task on primary-controller. But I agree that it can be tricky because after the cluster is deployed, we cannot say who is really primary, is there a case when it's important to know who is really primary after deployment is done? for mongo, its important to find out who is currently the primary prior to deployment starting (which may not have been the primary that the deployment started with) So it may be special in it's case. for controller, its irrelevant as long as it's not set to a newly added node (a node with a lower node.id will cause this and create problems) Also I would like to mention that in plugins user currently can write 'roles': ['controller'], which means that the task will be applied on 'controller' and 'primary-controller' nodes. Plugin developer can get this information from astute.yaml file. But I'm curious if we should change this behaviour for plugins (with backward compatibility of course)? writing roles: ['controller'] should apply to all controllers as expected, with the addition of roles: ['primary-controller'] only applying to the primary controller. Thanks, On Wed, Jan 28, 2015 at 1:07 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, we definitely need such separation on orchestration layer. Is it possible to have significantly different sets of tasks for controller and primary-controller? Right now we already do different things on primary and secondary controllers, but it's all conducted in the same manifest and controlled by conditionals inside the manifest. So when we split our tasks into smaller ones, we may want/need to separate them for primary and secondary controllers. I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework Sergii, we still need this separation on the orchestration layer and, as you know, our deployment process is based on it. Currently we already have separate task groups for primary and secondary controller roles. So it will be up to the task developer how to handle some particular task for different roles: developer can write 2 different tasks (one for 'primary-controller' and the other one for 'controller'), or he can write the same task for both groups and handle differences inside the task. -- Regards, Aleksandr Didenko On Wed, Jan 28, 2015 at 11:25 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: But without this separation on orchestration layer, we are unable to differentiate between nodes. What i mean is - we need to run subset of tasks on primary first and then on all others, and we are using role as mapper to node identities (and this mechanism was hardcoded in nailgun for a long time). Lets say we have task A that is mapped to primary-controller and B that is mapped to secondary controller, task B requires task A. If there is no primary in mapping - we will execute task A on all controllers and then task B on all controllers. And how in such case deployment code will know that it should not execute commands in task A for secondary controllers and in task B on primary ? On Wed, Jan 28, 2015 at 10:44 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, But with introduction of plugins and granular deployment, in my opinion, we need to be able to specify that task should run specifically on primary, or on secondaries. Alternative to this approach would be - always run task on all controllers, and let task itself to verify that it is executed on primary or not. I wouldn't differentiate tasks for primary and other controllers. Primary-controller logic should be controlled by task itself. That will allow to have elegant and tiny task framework ... -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jan 27, 2015 at 11:35 PM, Dmitriy Shulyak dshul...@mirantis.com
