Re: [openstack-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?
Aleksandr, i don't have time to check more precisely. But what you're saying means that we support multi-rack Ceph deployments. Which is very good. Thank you. On Thu, Dec 24, 2015 at 12:48 PM, Aleksey Kasatkin <akasat...@mirantis.com> wrote: > + Konstantin > > > Aleksey Kasatkin > > > On Wed, Dec 23, 2015 at 7:38 PM, Aleksandr Didenko <adide...@mirantis.com> > wrote: > >> Hi, >> >> just finished deployment of multirack env with ceph and external LB (not >> a standard multi-rack deployment scheme, actually, but still): >> >> http://paste.openstack.org/show/482610/ >> >> As you can see it works just fine in multirack. >> >> Also, we're running 'deploy_ceph_ha_nodegroups' system test as a part of >> 'thread_7' group in our swarm tests, so ceph in multirack is covered with >> automated tests as well. >> >> Regards, >> Alex >> >> On Wed, Dec 23, 2015 at 5:29 PM, Roman Sokolkov <rsokol...@mirantis.com> >> wrote: >> >>> + Konstantin and Alex >>> >>> Can someone give a quick highlight on that question? >>> >>> On Tue, Dec 22, 2015 at 8:17 PM, Roman Sokolkov <rsokol...@mirantis.com> >>> wrote: >>> >>>> Folks, >>>> >>>> multirack is going to be a part of MOS 8.0. >>>> >>>> But i can not find any info about Ceph? >>>> >>>> Technically Ceph supports Multiple L3 networks [1]. >>>> >>>> [1] - >>>> http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings >>>> >>>> -- >>>> Roman Sokolkov, >>>> Deployment Engineer, >>>> Mirantis, Inc. >>>> Skype rsokolkov, >>>> rsokol...@mirantis.com >>>> >>> >>> >>> >>> -- >>> Roman Sokolkov, >>> Deployment Engineer, >>> Mirantis, Inc. >>> Skype rsokolkov, >>> rsokol...@mirantis.com >>> >> >> >> __ >> 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 >> >> > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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][Multirack] Are we going to support Ceph Multirack deployments?
+ Konstantin and Alex Can someone give a quick highlight on that question? On Tue, Dec 22, 2015 at 8:17 PM, Roman Sokolkov <rsokol...@mirantis.com> wrote: > Folks, > > multirack is going to be a part of MOS 8.0. > > But i can not find any info about Ceph? > > Technically Ceph supports Multiple L3 networks [1]. > > [1] - > http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings > > -- > Roman Sokolkov, > Deployment Engineer, > Mirantis, Inc. > Skype rsokolkov, > rsokol...@mirantis.com > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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-dev] [Fuel][Multirack] Are we going to support Ceph Multirack deployments?
Folks, multirack is going to be a part of MOS 8.0. But i can not find any info about Ceph? Technically Ceph supports Multiple L3 networks [1]. [1] - http://docs.ceph.com/docs/hammer/rados/configuration/network-config-ref/#network-config-settings -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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] Configuration management for Fuel 7.0
Dmitry, Q1. Yes. > where do you plan to actually perform settings manipulation? It was one of the critical blockers. Most of the settings are baked inside fuel-library. Your feature [1] partially fixes this BTW. Which is good. Partially, because only limited number of tasks has defined overrides. > scheduled basis run nailgun-cm-agent Currently i see better way. nailgun-cm-agent (or whatever) should just check system status (i.e. puppet apply --noop) and report back. User will decide apply changes or not. Q2. Yes, i did. One more use case covered. Please see first table in [2]. Q4. Agree. Here is the bug [3] Q3,Q5, Q6 Good. [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change [2] https://docs.google.com/document/d/1bVVZJR73pBWB_WbfOzC-fh84pVsi20v4n3rvn38F4OI/edit (limited access) [3] https://bugs.launchpad.net/fuel/+bug/1525872 On Mon, Dec 14, 2015 at 4:39 AM, Dmitriy Novakovskiy < dnovakovs...@mirantis.com> wrote: > Roman, > > Thanks a lot for the feedback. We'll be planning improvements for [1] in > upcoming 9.0 cycle, so your input and this discussion are very helpful and > much appreciated. > > In overall, the concept for nailgun-cm-agent looks interesting, but I > think you'll face some problems with it: > - idempotency of puppet modules > - lack of exposed parameters (fuel-lib hacking) > - speed of re-runs of configuration mgmt (that we're already working on in > 8.0) > > Now, my comments and questions. > > *1) nailgun-cm-agent concept* > Q1. Do I understand correctly that the planned UX is: > - Allow user to change configuration as dictated by Fuel (btw, where do > you plan to actually perform settings manipulation? Directly in Puppet > modules/manifests?) > - On scheduled basis run nailgun-cm-agent and let it bring overall system > state to be consistent with latest changes > ? > > *2) "Advanced settings" [1] feature feedback* > Q2. Please share the details about 13 real world tasks that you used for > testing. Have you had a chance to test this same list against [1], as you > did with fuel-cm-agent approach? I need to know what from real world is > doable and what not with current state of [1] > Q3. "It allows just apply, not track changes" - that's true, 8.0 has > first MVP of this feature in place, and we don't yet have much tracking > capability (other than looking at logs in DB, when what config change yaml > was uploaded). We will be improving it in 9.0 cycle > Q4. "Moreover works weird, if multiple changes uploaded, applying not the > latest, but initial config change." - can you please share the detailed > example? I'm not sure I understood it, but so far sounds like a bug that > needs to be fixed. > Q5. "Just limited number[1] of resources/tasks has support." - this is > the limitation of what configs are shipped out of the box. When 8.0 is > released, we'll have a documented way to add support for any OpenStack > config file that Fuel tasks can reach > Q6. "Can we start moving all (non orchestrating) data into CMDB? yaml > under git or any existing solution." We're now discussing major > refactoring effort to be done in Fuel to integrate with Solar and solve > some of the long standing > > [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change > > On Fri, Dec 11, 2015 at 6:21 PM, Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> Oleg, >> >> thanks. I've tried it [1], looks like it works. >> >> - GOOD. "override_resource" resource. Like "back door" into puppet >> modules. >> - BAD. It allows just apply, not track changes. Moreover works weird, >> if multiple changes uploaded, applying not the latest, but initial >> config change. >> - BAD. Just limited number[1] of resources/tasks has support. >> >> BTW, my feeling that we should NOT develop this approach in the same way. >> >> I'm not an expert, but as long-term >> - Can we start moving all (non orchestrating) data into CMDB? yaml under >> git >> or any existing solution. >> - Can we track nodes state? For example, start by cron all puppet tasks >> with --noop option >> and check puppet state. Then if "out of sync" node start blinking YELLOW >> and user >> can push button, if needed. >> >> Thanks >> >> [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change >> [2] http://paste.openstack.org/show/481677/ >> >> On Fri, Dec 11, 2015 at 4:34 PM, Oleg Gelbukh <ogelb...@mirantis.com> >> wrote: >> >>> Roman, >>> >>> Changing arbitrary parameters supported by respective Puppet manifests >>> for OpenStack
Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0
Oleg, thanks. I've tried it [1], looks like it works. - GOOD. "override_resource" resource. Like "back door" into puppet modules. - BAD. It allows just apply, not track changes. Moreover works weird, if multiple changes uploaded, applying not the latest, but initial config change. - BAD. Just limited number[1] of resources/tasks has support. BTW, my feeling that we should NOT develop this approach in the same way. I'm not an expert, but as long-term - Can we start moving all (non orchestrating) data into CMDB? yaml under git or any existing solution. - Can we track nodes state? For example, start by cron all puppet tasks with --noop option and check puppet state. Then if "out of sync" node start blinking YELLOW and user can push button, if needed. Thanks [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change [2] http://paste.openstack.org/show/481677/ On Fri, Dec 11, 2015 at 4:34 PM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > Roman, > > Changing arbitrary parameters supported by respective Puppet manifests for > OpenStack services is implemented in this blueprint [1]. It is being landed > in release 8.0. > > [1] https://blueprints.launchpad.net/fuel/+spec/openstack-config-change > > -- > Best regards, > Oleg Gelbukh > > On Thu, Dec 3, 2015 at 5:28 PM, Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> Folks, >> >> little bit more research done in regards #2 usability. >> >> I've selected 13 real-world tasks from customer (i.e. update flag X in >> nova.conf): >> - 6/13 require fuel-library patching (or is #2 unusable) >> - 3/13 are OK and can be done with #2 >> - 4/13 can be done with some limitations. >> >> If needed i'll provide details. >> >> Rough statistics is that *only ~20-25% of use cases can be done with #2*. >> >> Let me give a very popular use case that will fail with #2. Assume we'r >> executing whole task graph every two hours. >> We want to change nova.conf "DEFAULT/amqp_durable_queues" from False to >> True. >> >> There is no parameter in hiera for "amqp_durable_queues". We have two >> solutions here (both are bad): >> 1) Redefine "DEFAULT/amqp_durable_queues" = True in plugin task. What >> will happen on the node. amqp_durable_queues will continue changing value >> between True and False on every execution. We shouldn't do it this way. >> 2) Patch fuel-library. Value for amqp_durable_queues should be taken from >> hiera. This is also one way ticket. >> >> Thanks >> >> >> >> >> >> On Thu, Dec 3, 2015 at 11:28 AM, Oleg Gelbukh <ogelb...@mirantis.com> >> wrote: >> >>> Roman, >>> >>> Thank you. This is great research. >>> >>> Could we have a conversation to discuss this? I'm especially interested >>> in idempotency problems of the fuel-library modules and the common way to >>> provide serialised data to the deployment. >>> >>> -- >>> Best regards, >>> Oleg Gelbukh >>> Mirantis Inc >>> >>> >>> On Tue, Dec 1, 2015 at 6:38 PM, Roman Sokolkov <rsokol...@mirantis.com> >>> wrote: >>> >>>> Hello, folks. >>>> >>>> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ >>>> nodes >>>> will be near impossible to support. Customer always wants to change >>>> something. >>>> >>>> In our opinion, there are two major approaches for CM: >>>> >>>> #1 Independent CM (Puppet master, Chef, Ansible, whatever) >>>> #2 Fuel-based CM >>>> >>>> Solution for #2 >>>> -- >>>> >>>> Fuel has all info about configuration. So we've tried to >>>> unlock "Settings" [0] and push "deploy" button. >>>> >>>> Major findings: >>>> >>>> * Task idem-potency. Looks like most of the tasks are idempotent. >>>> We've skipped 3 tasks on controller and were able to get NO downtime >>>> for Horizon and "nova list". BTW deeper QA required. >>>> >>>> * Standard changes. Operator can change parameters via WebUI, CLI or >>>> API. >>>> For example, i was able to deploy Sahara. Unfortunately there is not >>>> foolproof. >>>> I mean some changes can lead to broken cloud... >>>> >>>> * Non-standard changes. Any other changes can be done with plugins. >>>> We can modify plugin tasks and scripts (all
Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0
Hi there, one small step into this direction. I've checked how idempotent controller's tasks. As result bugs below were reported: https://bugs.launchpad.net/fuel/+bug/1524759 NEW https://bugs.launchpad.net/fuel/+bug/1524747 NEW https://bugs.launchpad.net/fuel/+bug/1524731 NEW https://bugs.launchpad.net/fuel/+bug/1524727 NEW https://bugs.launchpad.net/fuel/+bug/1524724 NEW https://bugs.launchpad.net/fuel/+bug/1524719 NEW https://bugs.launchpad.net/fuel/+bug/1524713 NEW https://bugs.launchpad.net/fuel/+bug/1524687 NEW https://bugs.launchpad.net/fuel/+bug/1524630 NEW https://bugs.launchpad.net/fuel/+bug/1524327 CONFIRMED https://bugs.launchpad.net/fuel/+bug/1522857 IN PROGRESS If it's interesting i can go thru other roles and tasks? Please let me know. Thanks On Thu, Dec 3, 2015 at 10:33 PM, Yuriy Taraday <yorik@gmail.com> wrote: > Hi, Roman. > > On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> I've selected 13 real-world tasks from customer (i.e. update flag X in >> nova.conf): >> - 6/13 require fuel-library patching (or is #2 unusable) >> - 3/13 are OK and can be done with #2 >> - 4/13 can be done with some limitations. >> >> If needed i'll provide details. >> >> Rough statistics is that *only ~20-25% of use cases can be done with #2*. >> >> Let me give a very popular use case that will fail with #2. Assume we'r >> executing whole task graph every two hours. >> We want to change nova.conf "DEFAULT/amqp_durable_queues" from False to >> True. >> >> There is no parameter in hiera for "amqp_durable_queues". We have two >> solutions here (both are bad): >> 1) Redefine "DEFAULT/amqp_durable_queues" = True in plugin task. What >> will happen on the node. amqp_durable_queues will continue changing value >> between True and False on every execution. We shouldn't do it this way. >> 2) Patch fuel-library. Value for amqp_durable_queues should be taken from >> hiera. This is also one way ticket. >> > > You are describing one of use cases we want to cover in future with Config > Service. If we store all configuration variables consumed by all deployment > tasks in the service, one will be able to change (override) the value in > the same service and let deployment tasks apply config changes on nodes. > > This would require support from the deployment side (source of all config > values will become a service, not static file) and from Nailgun (all data > should be stored in the service). In the future this approach will allow us > to clarify which value goes where and to define new values and override old > ones in a clearly manageable fashion. > > Config Service would also allow us to use data defined outside of Nailgun > to feed values into deployment tasks, such as external CM services (e.g. > Puppet Master). > > ______ > 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 > > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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] Configuration management for Fuel 7.0
Folks, little bit more research done in regards #2 usability. I've selected 13 real-world tasks from customer (i.e. update flag X in nova.conf): - 6/13 require fuel-library patching (or is #2 unusable) - 3/13 are OK and can be done with #2 - 4/13 can be done with some limitations. If needed i'll provide details. Rough statistics is that *only ~20-25% of use cases can be done with #2*. Let me give a very popular use case that will fail with #2. Assume we'r executing whole task graph every two hours. We want to change nova.conf "DEFAULT/amqp_durable_queues" from False to True. There is no parameter in hiera for "amqp_durable_queues". We have two solutions here (both are bad): 1) Redefine "DEFAULT/amqp_durable_queues" = True in plugin task. What will happen on the node. amqp_durable_queues will continue changing value between True and False on every execution. We shouldn't do it this way. 2) Patch fuel-library. Value for amqp_durable_queues should be taken from hiera. This is also one way ticket. Thanks On Thu, Dec 3, 2015 at 11:28 AM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > Roman, > > Thank you. This is great research. > > Could we have a conversation to discuss this? I'm especially interested in > idempotency problems of the fuel-library modules and the common way to > provide serialised data to the deployment. > > -- > Best regards, > Oleg Gelbukh > Mirantis Inc > > > On Tue, Dec 1, 2015 at 6:38 PM, Roman Sokolkov <rsokol...@mirantis.com> > wrote: > >> Hello, folks. >> >> We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes >> will be near impossible to support. Customer always wants to change >> something. >> >> In our opinion, there are two major approaches for CM: >> >> #1 Independent CM (Puppet master, Chef, Ansible, whatever) >> #2 Fuel-based CM >> >> Solution for #2 >> -- >> >> Fuel has all info about configuration. So we've tried to >> unlock "Settings" [0] and push "deploy" button. >> >> Major findings: >> >> * Task idem-potency. Looks like most of the tasks are idempotent. >> We've skipped 3 tasks on controller and were able to get NO downtime >> for Horizon and "nova list". BTW deeper QA required. >> >> * Standard changes. Operator can change parameters via WebUI, CLI or API. >> For example, i was able to deploy Sahara. Unfortunately there is not >> foolproof. >> I mean some changes can lead to broken cloud... >> >> * Non-standard changes. Any other changes can be done with plugins. >> We can modify plugin tasks and scripts (all except UI flags). And then >> just >> do "--update" + "--sync". BTW, we can change UI for particular env via API >> by modifying "clusters/X/attributes". >> >> Conclusion >> -- >> >> - This works (We have service under cron that runs tasks) [1] >> - NOT ready for production (in current state) >> - This requires much deeper testing >> >> >> I want to hear thoughts about approach above? >> What is the current status/plans for CM? I saw this discussion [2] >> >> References >> -- >> >> [0] >> https://github.com/rsokolkov/fuel-web/commit/366daaa2eb874c8e54c2d39be475223937cd317d >> [1] >> https://docs.google.com/presentation/d/12kkh1hu4ZrY9S6XXsY_HWaesFwESfxbl5czUwde8isM/edit#slide=id.p >> [2] https://etherpad.openstack.org/p/lcm-use-cases >> >> -- >> Roman Sokolkov, >> Deployment Engineer, >> Mirantis, Inc. >> Skype rsokolkov, >> rsokol...@mirantis.com >> >> ______ >> 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 > > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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-dev] [Fuel] Configuration management for Fuel 7.0
Hello, folks. We need any kind of CM for Fuel 7.0. Otherwise new project with 800+ nodes will be near impossible to support. Customer always wants to change something. In our opinion, there are two major approaches for CM: #1 Independent CM (Puppet master, Chef, Ansible, whatever) #2 Fuel-based CM Solution for #2 -- Fuel has all info about configuration. So we've tried to unlock "Settings" [0] and push "deploy" button. Major findings: * Task idem-potency. Looks like most of the tasks are idempotent. We've skipped 3 tasks on controller and were able to get NO downtime for Horizon and "nova list". BTW deeper QA required. * Standard changes. Operator can change parameters via WebUI, CLI or API. For example, i was able to deploy Sahara. Unfortunately there is not foolproof. I mean some changes can lead to broken cloud... * Non-standard changes. Any other changes can be done with plugins. We can modify plugin tasks and scripts (all except UI flags). And then just do "--update" + "--sync". BTW, we can change UI for particular env via API by modifying "clusters/X/attributes". Conclusion -- - This works (We have service under cron that runs tasks) [1] - NOT ready for production (in current state) - This requires much deeper testing I want to hear thoughts about approach above? What is the current status/plans for CM? I saw this discussion [2] References -- [0] https://github.com/rsokolkov/fuel-web/commit/366daaa2eb874c8e54c2d39be475223937cd317d [1] https://docs.google.com/presentation/d/12kkh1hu4ZrY9S6XXsY_HWaesFwESfxbl5czUwde8isM/edit#slide=id.p [2] https://etherpad.openstack.org/p/lcm-use-cases -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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] FW: [Fuel] 8.0 Region name support / Multi-DC
Sheena, thanks. I agree with Chris full Multi-DC it's different scale task. For now Services just need +1 tiny step from Fuel/Product in favor supporting current Multi-DC deployments architectures. (i.e. shared Keystone) Andrew, Ruslan, Mike, i've created tiny blueprint https://blueprints.launchpad.net/fuel/+spec/expose-region-name-to-ui We just need to expose already existing functionality to UI. Can someone pickup this blueprint? And/Or reassign to appropriate team. Thanks On Fri, Oct 2, 2015 at 7:41 PM, Sheena Gregson <sgreg...@mirantis.com> wrote: > Forwarding since Chris isn’t subscribed. > > > > *From:* Chris Clason [mailto:ccla...@mirantis.com] > *Sent:* Friday, October 02, 2015 6:30 PM > *To:* Sheena Gregson <sgreg...@mirantis.com>; OpenStack Development > Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC > > > > We are doing some technology evaluations with the intent of publishing > reference architectures at various scale points (500, 1500, 2000 etc). Part > of this work will be to determine how to best partition the nodes in to > regions based on scale limits of OpenStack components and workload > characteristics. The work we are doing increased in scope significantly, so > the first RA will be coming at the end of Q1 or early Q2. > > > > We do plan on using some components of Fuel for our testing but the main > purpose is path finding. The work we do will eventually make it into Fuel, > but we are going to run in front of it a bit. > > > > On Fri, Oct 2, 2015 at 9:19 AM Sheena Gregson <sgreg...@mirantis.com> > wrote: > > Plans for multi-DC: my understanding is that we are working on developing > a whitepaper in Q4 that will provide a possible OpenStack multi-DC > configuration, but I do not know whether or not we intend to include Fuel > in the scope of this work (my guess would be no). Chris – I copied you in > case you wanted to comment here. > > > > Regarding specifying region names in UI, is it possible to specify region > names in API? And (apologies for my ignorance on this one) what is the > relative equivalence to environments in Fuel (e.g. 1 environment : many > regions, 1 environment == 1 region)? > > > > *From:* Roman Sokolkov [mailto:rsokol...@mirantis.com] > *Sent:* Friday, October 02, 2015 5:26 PM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC > > > > Folks, > > > > i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC > support. > > > > My ask is about tiny(but useful) feature: give user ability to *specify > Region name in UI.* > > > > Region name is already in every puppet module, so we just need to add this > to UI. > > > > Do we have smth already? > > > > More general question: What are our plans in regards Multi-DC? > > > > Thanks > > > > -- > > Roman Sokolkov, > > Deployment Engineer, > > Mirantis, Inc. > Skype rsokolkov, > rsokol...@mirantis.com > > -- > > Chris Clason > > Director of Architecture > > ccla...@mirantis.com > > Mobile: +1.408.409.0295 > > __ > 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 > > -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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-dev] [Fuel] 8.0 Region name support / Multi-DC
Folks, i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC support. My ask is about tiny(but useful) feature: give user ability to *specify Region name in UI.* Region name is already in every puppet module, so we just need to add this to UI. Do we have smth already? More general question: What are our plans in regards Multi-DC? Thanks -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com __ 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-dev] [Fuel][RabbitMQ] nova-compute stuck for a while (AMQP)
Bogdan, thank you. On Thu, May 8, 2014 at 6:22 AM, Bogdan Dobrelya bdobre...@mirantis.comwrote: On 05/06/2014 10:42 PM, Roman Sokolkov wrote: Hello, fuelers. I'm using Fuel 4.1A + Havana in HA mode. I permanently observe (on other deployments also) issue with stuck nova-compute service. But i think problem is more fundamental and relates to HA RabbitMQ and OpenStack AMQP driver implementation. Symptoms: * Random nova-compute from time to time marked as XXX for a while. * I see that service itself works properly. In logs i see that it sends status updates to conductor. But actually nothing is sent. * netstat shows that all connections to/from rabbit ESTABLISHED * rabbitmqctl shows that compute.node-x queue synced to all slaves. * nothing has been broken before, i mean rabbitmq cluster, etc. Axe style solution: * /etc/init.d/openstack-nova-compute restart So here i've found a lot of interesting stuff (and solutions): https://bugs.launchpad.net/oslo.messaging/+bug/856764 My questions are: * Are there any thoughts particular for Fuel to solve/workaround this issue? * Any fast solution for this in 4.1? Like adjust TCP keep-alive timeouts? I submitted an issue for Fuel https://bugs.launchpad.net/fuel/+bug/1317488 and assigned it to Fuel hardening team. Feel free to update it as appropriate. -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com mailto:rsokol...@mirantis.com -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fuel
Tizy, Selinux is disabled on all nodes under Fuel. https://github.com/stackforge/fuel-library/blob/stable/4.0/deployment/puppet/cobbler/templates/kickstart/centos.ks.erb#L32 You could check it by getenforce command. It should report Disabled. So you could simply pass all steps related to Selinux. Thank you. On Tue, May 6, 2014 at 12:51 AM, Tizy Ninan tizy.e...@gmail.com wrote: Hi We are trying to integrate the openstack setup with the Microsoft Active Directory(LDAP server). As per openstack documentation, http://docs.openstack.org/admin-guide-cloud/content/configuring-keystone-for-ldap-backend.html in order to integrate with an LDAP server, an SELinux Boolean variable ‘authlogin_nsswitch_use_ldap’ needs to be set. We tried setting the variable using the following command. $ setsebool –P authlogin_nsswitch_use_ldap 1 It returned a message stating SElinux is disabled. We changed the status of SElinux to permissive mode and tried setting the boolean variable, but it returned a message stating ‘record not found in the database’. We also tried retrieving all the boolean variables by using the following command $getsebool –a It listed out all the boolean variables, but there was no variable named ‘authlogin_nsswitch_use_ldap’ in the list. In order to add the variable we needed semanage. When executing the ‘semanage’ command it returned ‘command not found’. To install semanage we tried installing policycoreutils-python. It showed no package policycoreutils-python available. We are using Mirantis Fuel v4.0. We have an openstack Havana deployment on CentOS 6.4 and nova-network network service. Can you please help us on why the SELinux boolean variable (authlogin_nsswitch_use_ldap) is not available. Is it because the CentOS image provided by the Fuel master node does not provide the SELinux settings? Is there any alternative ways to set this boolean variable? Kindly help us to resolve this issue. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Roman Sokolkov, Deployment Engineer, Mirantis, Inc. Skype rsokolkov, rsokol...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
