[openstack-dev] [tc][fuel] Making Fuel a hosted project
Folks, I sent a reply a couple of days ago, but somehow it got lost. The original message goes below Folks It is essentially true that Fuel is no longer being developed as almost 99% of people have left the project and are working on something else. May be, in the future, when the dust settles, we can resume working on it, but the probability is not so high as of now. I would like to thank everyone who worked on the project - contributors, reviewers, core-reviewers, ex-PTLs Alex Shtokolov, Vladimir Kozhukalov and Dmitry Borodaenko - it was a pleasure to work with you guys. Also, I would like to thank puppet-openstack project team as we worked together on many things really effectively and wish them good luck as well. Special Kudos to Jay and Dims as they helped as a lot on governance and community side. I hope, we will work some day together again. At the same time, I would like to mention that Fuel is still being actively used and some bugs are still being fixed, so I would suggest, if that is possible, that we keep the github repository available for a while, so that those guys can still access the repositories. Having that said, I do not have any other objections on making Fuel Hosted project. Yours Faithfully Vladimir Kuklin email: ag...@aglar.ru email(alt.): aglaren...@gmail.com mob.: +79267023968 mob.: (when in EU) +393497028541 mob.: (when in US) +19293122331 skype: kuklinvv telegram __ 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] Weekly meeting April 20th is cancelled
Fuelers Agenda is empty for today, so the meeting is cancelled. __ 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] Weekly meeting April 13th is cancelled
Fuelers Agenda is empty for today, so the meeting is cancelled. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Weekly meeting April 6th is cancelled
Fuelers Agenda is empty for today, so the meeting is cancelled. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Stable/newton Temporary Code Freeze
Fuelers As for preparing for 10.1 release of Fuel, there is a temporary code freeze for stable/newton branch until further announcement. Please do not merge any code except the one with +2 from me. I will write a separate email when the freeze is lifted. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Weekly meeting March 23th is cancelled
Agenda is empty for today, so I am calling the meeting as cancelled. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Weekly meeting March 16th is cancelled
Agenda is empty for today except for review requests, so I am calliing the meeting as cancelled. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [release][tripleo][fuel][kolla][ansible] Ocata Release countdown for R+2 Week, 6-10 March
Doug I have proposed the change for Fuel RC2 [0], but it has W-1 set as I am waiting for the final tests result. If everything goes alright, I will check the Worfklow off and this RC2 can be the cut as the release. [0] https://review.openstack.org/#/c/442775/ On Tue, Mar 7, 2017 at 3:39 AM, Jeffrey Zhang wrote: > Sorry for late. But Kolla project need a new release candidate. I will > push it today. > > On Tue, Mar 7, 2017 at 6:27 AM, Doug Hellmann > wrote: > >> Excerpts from Doug Hellmann's message of 2017-03-06 11:00:15 -0500: >> > Excerpts from Doug Hellmann's message of 2017-03-02 18:24:12 -0500: >> > > >> > > Release Tasks >> > > - >> > > >> > > Liaisons for cycle-trailing projects should prepare their final >> > > release candidate tags by Monday 6 March. The release team will >> > > prepare a patch showing the final release versions on Wednesday 7 >> > > March, and PTLs and liaisons for affected projects should +1. We >> > > will then approve the final releases on Thursday 8 March. >> > >> > We have 13 cycle-trailing deliverables without final releases for Ocata. >> > All have at least one release candidate, so if no new release candidates >> > are proposed *today* I will prepare a patch using these versions as the >> > final and we will approve that early Wednesday. >> > >> > If you know that you need a new release candidate, please speak up now. >> > >> > If you know that you do not need a new release candidate, please also >> > let me know that. >> > >> > Thanks! >> > Doug >> > >> > $ list-deliverables --series ocata --missing-final -v >> > fuel fuel 11.0.0.0rc1 other >> cycle-trailing >> > instack-undercloud tripleo 6.0.0.0rc1 other >>cycle-trailing >> > kolla-ansible kolla4.0.0.0rc1 other >>cycle-trailing >> > kolla kolla4.0.0.0rc1 other >>cycle-trailing >> > openstack-ansible OpenStackAnsible 15.0.0.0rc1 other >> cycle-trailing >> > os-apply-configtripleo 6.0.0.0rc1 other >>cycle-with-milestones >> > os-cloud-configtripleo 6.0.0.0rc1 other >>cycle-with-milestones >> > os-collect-config tripleo 6.0.0.0rc1 other >>cycle-with-milestones >> > os-net-config tripleo 6.0.0.0rc1 other >>cycle-with-milestones >> > os-refresh-config tripleo 6.0.0.0rc1 other >>cycle-with-milestones >> > tripleo-heat-templates tripleo 6.0.0.0rc1 other >>cycle-trailing >> > tripleo-image-elements tripleo 6.0.0.0rc1 other >>cycle-trailing >> > tripleo-puppet-elementstripleo 6.0.0.0rc1 other >>cycle-trailing >> > >> >> I have lined up patches with the final release tags for all 3 projects. >> Please review and +1 or propose a new patch with an updated release >> candidate. >> >> Ansible: https://review.openstack.org/442138 >> Kolla: https://review.openstack.org/442137 >> TripleO: https://review.openstack.org/442129 >> >> Doug >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Weekly meeting Feb 23 is canceled
Feb 23 meeting is cancelled as majority of Fuel contributors will be on holidays that day and others are travelling. See you all next week. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][release] Opting out of Ocata?
Dims Thank you for keeping the hand on the pulse. I am going to take over the PTL duties and we are going to produce releases according to the wiki <https://wiki.openstack.org/wiki/Fuel/Release_Schedule>. We are going to have RC1 next week (around Feb 15). After that we are going to proceed as planned for March 6th Ocata release. On Wed, Feb 8, 2017 at 1:47 AM, Davanum Srinivas wrote: > Dear Fuel Team, > > There have been no releases for fuel-* projects in the Ocata time frame: > https://git.openstack.org/cgit/openstack/releases/tree/deliverables/ocata > > Fuel projects under governance are supposed to be following the > "cycle-trailing" schedule: > https://releases.openstack.org/reference/release_models. > html#cycle-trailing > > Please see Ocata schedule: > https://releases.openstack.org/ocata/schedule.html#o-trailing > > Is anyone still around keeping the lights on? > > Thanks, > Dims > > -- > Davanum Srinivas :: https://twitter.com/dims > > __ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][tripleo] Fuel and TripleO Cross-Project Integration
Stackers During OpenStack summit in Barcelona we had a rather productive cross-project integration session between Fuel and TripleO projects [0]. More precisely we discussed the following: 1. Services composition and deployment workflow control 2. Complex networking configuration (bonds, offloading, etc.) 3. Post-deployment cluster management, i.e. day-2 operations 4. Approaches to reference architecture recomposition, e.g. in-flight database vertical scaling 5. Upgrades 6. Provisioning and disks partitioning The most interesting part of integration would be to consider integration of deployment and post-deployment orchestration approaches and services composition. The further steps are to start working on: 1. Cross-project specification on workflow management, e.g. for upgrades and day-2 operations 2. Look into possibility of Mistral integration as a workflow execution tool within the designed model 3. Consider integration of Fuel provisioning, network configuration and disk partitioning with Ironic and TripleO [0] https://etherpad.openstack.org/p/fuel-ocata-fuel-tripleo-integration I would suggest that we add discussing this into TripleO or Fuel IRC meeting agenda next week. Please let me know what are you thoughts on this. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Plugins] Contributing a new fuel-plugin
Hi Omar You might want to follow basic OpenStack documentation here: http://docs.openstack.org/infra/manual/creators.html if you want to create a new project. For fuel plugins just put it into fuel namespace and call it something like 'fuel-plugin-'. If you want to contribute to the existing plugin, please use its respective launchpad project. Please let me know if you need any other help. On Fri, Oct 7, 2016 at 10:03 PM, Omar Rivera wrote: > Please, could someone help me find the correct process on how to > contribute fuel plugins upstream? > > I had followed these instructions but when I opened bug it was declared > invalid - has the process changed perhaps? [1] > > I cannot find relevant documentation for how to go about creating the > repository in gerrit and creating the launchpad project correctly. The only > thing I found is the add to the DriverLog repository however they expect > that there is a plugin repository already created. > > I had hoped for more instruction in this [2] launchpad project since it > seems to manage bugs for many plugins. Or should it be like the contrail > plugin [3] that has their own page. > > > [1] http://docs.openstack.org/developer/fuel-docs/ > plugindocs/fuel-plugin-sdk-guide/create-environment/plugin-repo.html > [2] https://launchpad.net/fuel-plugins > [3] https://launchpad.net/fuel-plugin-contrail > > -- > - Omar Rivera - > - > irc: gomarivera - > > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Mitaka stable branch
Bogdan, Vladimir *Regarding upgrades of Fuel Master Node and environments. * First, regarding Fuel Master Node upgrades and enablement of usage of 9.0 LCM features with older clusters. It is assumed that we test usability of Fuel Mitaka code with already deployed clusters, e.g. 8.0, 7.0 and so on. Whenever an issue arise, we fix it. This would allow us to reuse newest features to be able to enable LCM and newest orchestration and integration capabilities with older clusters by essentially, calling old serializers code within extensions pipeline, applying some pre- and postprocessing to the serialized data. Here is an example of how it is done (Work in progress): https://review.openstack.org/#/c/333845/ This is an extension that first runs new LCM serializer which data is not compatible with 9.0, but part of which we need for LCM engine (e.g. 'cluster context'), then we simply run 8.0 Serializer, add cluster info into serialized data and then we just update 'upload_configuration' and related tasks by simply copying them from Mitaka code of Fuel Library. I proof-tested this by adding Sahara into already installed 8.0 cluster with BVT scenario and it seems to be working. *Regarding environments upgrades* Having completed item #1 we should be able to run new orchestration against old clusters, so that we can upgrade environments to newer versions, esentially, by rolling reinstallation of control plane and resource nodes, which means that as soon as new version of installed software (including OpenStack, LMA toolchaing and other stuff) works fine with the feature-set specified within the old cluster configuration, it should be OK to do so, but this basically becomes a matter of building consistent upgrade path for the particular environment. *Conclusion* Let's add bugfixing for management of old clusters and pre-9.0 clusters LCM support into our RoadMap and we should be safe to go. On Wed, Jul 13, 2016 at 12:23 PM, Bogdan Dobrelya wrote: > On 07/13/2016 11:08 AM, Vladimir Kozhukalov wrote: > > > > > > Few Q: > > - Is the stable/mitaka the only stable branch in the scope of the > > changes? > > > > Yes, this announce is only about Mitaka branch. All other stable > > branches are to be treated as usual, i.e. no feature backports, bug > > fixes only following "master first" policy, etc. > > > > > > - As the master and stable/mitaka will diverge, the former might > contain > > backwards incompatible changes, ending up the upgrade paths from > > stable/mitaka to future >=10.x releases will likely be *blocked* for > its > > life time. Any plans how to address that? > > > > - What about upgrade paths availability from the stable/* branches > to: > > a) stable/mitaka > > b) future >=10.x releases? > > > > Fortunately, Fuel now has nice built-in LCM that allows to run > > complicated custom scenarios (including reconfigurations/upgrades of > > existent OpenStack clusters). Vladimir Kuklin is working hard on making > > this LCM capabilities applicable to cases stable/* -> stable/mitaka. I > > believe later we'll be able to implement stable/mitaka -> Newton, etc. > > That's OK for the upgrade process, while I'm not sure in the very > upgrade *possibility* if we allowed backwards incompatible changes make > it to the Newton. How would users upgrade from stable/mitaka to anything > wich might be backwards incompatible and might break things? And > features backported and being developed in both branches may conflict as > well. All of this makes the upgrade barely possible, so any ideas how > could we address that? > > > > > Let's try to imagine we removed old role based serializers from Nailgun > > in Newton release. The question is how are we going, for example, to > > add/remove nodes to/from Kilo/Liberty clusters. The answer would be we > > could add custom task graph and task based deployment engine to modify > > old clusters. I'd like Vladimir Kuklin to give some additional details. > > > > > > > > > > > > > > __ > > > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > -- > > Best regards, > > Bogdan Dobrely
Re: [openstack-dev] [Fuel] Failed to install fuel master
Hi, Alioune Let's start with the most basic steps. Which Fuel are you using? And how do you install the node? Do you use USB stick or DVD or some IPMI virtual media? From what I see here it pretty much looks like, that this media is not inserted into the host. On Tue, Jul 5, 2016 at 3:11 PM, Alioune wrote: > Hi all, > > I'm trying to install fuel master using [1] on phycal server but the > installation process fails and switches to a dracut console with the > following error: > > dracut-initqueue[595] floppy0: no floppy controllers found > dracut-initqueue[595] Warning: failed to fetck kickstart from > hd:sr0:/ks.cfg > dracut-initqueue[595] mount: no medium found on /dev/sr0 > dracut-initqueue[595] Warning: Cloud not boot > dracut-initqueue[595] Warning: /dev/root does not exist > > > Starting Dracut Emergency Shell > Warning: /dev/root does not exist > Generating "/run/initramfs/rdsosreport.txt" > dracut:/# > > Any suggestion for solving that error ? > > Regards, > > [1] > http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Replace OSTF with Rally
+1 to initial suggestion, but I guess we need to have a full feature equality (e.g. HA tests for mysql and rabbitmq replication) before switching to Rally. On Mon, Jun 27, 2016 at 6:17 PM, Sergii Golovatiuk wrote: > Hi, > > Before switching Fuel from ostf to rally, I would like to see feature > parity comparison. It's very necessary to understand how much work we need > to spend to rewrite all our tests in rally way. > > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Mon, Jun 27, 2016 at 4:32 PM, Alexander Kostrikov < > akostri...@mirantis.com> wrote: > >> Hello, everybody! >> Hello, Alex! >> >I thought Rally was more for benchmarking. Wouldn't Tempest make more >> sense? >> Rally is a good tool with nice api/usage/extensibility. >> I really liked "up and running tests in 5 minutes" in Rally with clear >> picture of what I am doing. >> So, I 100% for a Rally as a QA. >> >> Another note: >> We will need to implement some HA tests, probably not in Rally. >> >> On Mon, Jun 27, 2016 at 4:57 PM, Andrey Kurilin >> wrote: >> >>> >>> >>> On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky >> > wrote: >>> >>>> >>>> > On Jun 27, 2016, at 16:23, Alex Schultz >>>> wrote: >>>> > >>>> > I thought Rally was more for benchmarking. Wouldn't Tempest make >>>> more sense? >>>> >>>> According to Rally wiki page [1], it seems they have a verification >>>> layer (Tempest so far). Hm, I wonder does it mean we will need to rewrite >>>> our scenarios for Tempest? >>>> >>>> >>> Rally consists of two main components: Rally Task and Rally >>> Verification. They are totally separated. >>> Task component is fully pluggable and you can run there whatever you >>> want in whatever you want way. >>> Verification component is hardcoded now. It was designed for >>> managing(install, configure) and launching(execute and store results) >>> Tempest. But we have a spec to make this component pluggable too. >>> >>> >>>> - igor >>>> >>>> >>>> [1] https://wiki.openstack.org/wiki/Rally >>>> >>>> __ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Andrey Kurilin. >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> >> Kind Regards, >> >> Alexandr Kostrikov, >> >> Mirantis, Inc. >> >> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia >> >> >> Tel.: +7 (495) 640-49-04 >> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79> >> >> Skype: akostrikov_mirantis >> >> E-mail: akostri...@mirantis.com >> >> *www.mirantis.com <http://www.mirantis.ru/>* >> *www.mirantis.ru <http://www.mirantis.ru/>* >> >> __ >> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Nominate Ilya Kutukov for the fuel-web-core team
+1 On Thu, Jun 9, 2016 at 11:37 AM, Aleksey Kasatkin wrote: > +1 > > > Aleksey Kasatkin > > > On Thu, Jun 9, 2016 at 9:51 AM, Sergey Vasilenko > wrote: > >> +1 >> >> /sv >> On Jun 9, 2016 09:24, "Julia Aranovich" wrote: >> >>> +1 >>> >>> On Wed, Jun 8, 2016 at 8:52 PM Bulat Gaifullin >>> wrote: >>> >>>> Hey Fuelers, >>>> >>>> I'd like to nominate Ilya Kutukov for the fuel-web-core team. >>>> Ilya`s doing good reviews with detailed feedback [1], >>>> and has implemented custom graph execution engine for Fuel. >>>> Also Ilya`s implemented new database models for storing deployment >>>> tasks in Fuel. >>>> >>>> >>>> Fuel Cores, please reply back with +1/-1. >>>> >>>> [1] http://stackalytics.com/report/contribution/fuel-web/90 >>>> >>>> >>>> Regards, >>>> Bulat Gaifullin >>>> Mirantis Inc. >>>> >>>> >>>> __ >>>> 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 for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Newton Design Summit sessions planning
Fuelers I am OK with the proposed change 21 апр. 2016 г. 12:34 пользователь "Vitaly Kramskikh" < vkramsk...@mirantis.com> написал: > Folks, > > I'd like to request workroom sessions swap. > > I planned to lead a discussion of Fuel UI modularization on Wed > 11.00-11.40, but at the same time there will be discussion of handling JS > dependencies of Horizon which I'd really like to attend. > > So I request to swap my discussion with discussion of finalizing of HA > reference architecture with event-based control and fencing led by V. > Kuklin on Thu 11.00-11.40. > > Do you have any objections? > > 2016-04-14 17:55 GMT+03:00 Alexey Shtokolov : > >> Hi, +1 from my side. >> >> --- >> WBR, Alexey Shtokolov >> >> 2016-04-14 16:47 GMT+03:00 Evgeniy L : >> >>> Hi, no problem from my side. >>> >>> On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov < >>> vkozhuka...@mirantis.com> wrote: >>> Dear colleagues, I'd like to request workrooms sessions swap. We have a session about Fuel/Ironic integration and I'd like this session not to overlap with Ironic sessions, so Ironic team could attend Fuel sessions. At the same time, we have a session about orchestration engine and it would be great to invite there people from Mistral and Heat. My suggestion is as follows: Wed: 9:50 Astute -> Mistral/Heat/??? Thu: 9.00 Fuel/Ironic/Ironic-inspector If there are any objections, please let me know asap. Vladimir Kozhukalov On Fri, Apr 1, 2016 at 9:47 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > Looks like we have final version sessions layout [1] > for Austin design summit. We have 3 fishbows, > 11 workrooms, full day meetup. > > Here you can find some useful information about design > summit [2]. All session leads must read this page, > be prepared for their sessions (agenda, slides if needed, > etherpads for collaborative work, etc.) and follow > the recommendations given in "At the Design Summit" section. > > Here is Fuel session planning etherpad [3]. Almost all suggested > topics have been put there. Please put links to slide decks > and etherpads next to respective sessions. Here is the > page [4] where other teams publish their planning pads. > > If session leads want for some reason to swap their slots it must > be requested in this ML thread. If for some reason session lead > can not lead his/her session, it must be announced in this ML thread. > > Fuel sessions are: > === > Fishbowls: > === > Wed: > 15:30-16:10 > 16:30:17:10 > 17:20-18:00 > > === > Workrooms: > === > Wed: > 9:00-9:40 > 9:50-10:30 > 11:00-11:40 > 11:50-12:30 > 13:50-14:30 > 14:40-15:20 > Thu: > 9:00-9:40 > 9:50-10:30 > 11:00-11:40 > 11:50-12:30 > 13:30-14:10 > > === > Meetup: > === > Fri: > 9:00-12:30 > 14:00-17:30 > > [1] > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/d59d38b7/attachment.pdf > [2] https://wiki.openstack.org/wiki/Design_Summit > [3] https://etherpad.openstack.org/p/fuel-newton-summit-planning > [4] https://wiki.openstack.org/wiki/Design_Summit/Planning > > Thanks. > > Vladimir Kozhukalov > __ 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 >> >> > > > -- > Vitaly Kramskikh, > Fuel UI Tech Lead, > Mirantis, Inc. > __ 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][library] Update of astute.yaml fixtures and noop tests
Hi Alex
+1 to your proposal - this is long-awaited change.
On Fri, Apr 1, 2016 at 6:01 PM, Aleksandr Didenko
wrote:
> One more thing about spec to fixture mapping [0]. What if instead of:
>
> # RUN: (hiera1) (facts1)
>
> we'll use
>
> # RUN: (roles_array1) (facts1)
>
> ?
>
> We don't need to duplicate complicated task graph calculations to
> understand which task to execute, because we don't care about tasks
> ordering and dependencies in noop tests. All we need is to map rspec task
> tests to astute.yaml fixtures. And it could be done via roles.
>
> Regards,
> Alex
>
> [0]
> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>
>
> On Fri, Apr 1, 2016 at 4:05 PM, Aleksandr Didenko
> wrote:
>
>> Hi.
>>
>> As you may know, we're still using some very old astute.yaml fixtures
>> (v6.1) in our 'master' (v9.0) noop rspec tests [0]. Besides that, we have
>> problems with fixture-to-rspec mapping [1]. So we've started to work on
>> those problems [2].
>>
>> So please be aware of upcoming changes in noop rspec fixtures and
>> tests. If you see, that some important fixtures are missing (thus not
>> covered by tests) please let me know in this email thread or via
>> IRC/email/slack.
>>
>> Also, we should stop updating astute.yaml fixtures manually and start
>> using some kind of automation approach instead [3][4]. I propose to use [5]
>> script until we find a better solution. So if you want to add some new
>> astute.yaml fixture for noop tests, please propose a patch to this script
>> instead of uploading yaml file.
>>
>> Currently the following is missing in the new set of fixtures for
>> fuel-9.0:
>> - generate_vms ('vms_conf' array in astute.yaml - I'm not sure how to
>> properly enable it via nailgun, any help is much appreciated)
>> - selective ssl fixtures - since configuration data is not serialized
>> from nailgun, I think that we should move this into 'hiera/override' along
>> with implementation of new hiera overrides tests workflow [6]
>> - vmware related fixtures
>>
>> Please feel free to share your ideas/comments on this topic.
>>
>> Thanks,
>> Alex
>>
>> [0] https://bugs.launchpad.net/fuel/+bug/1535339
>> [1]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/usage.rst#spec-file-annotations
>> [2] https://review.openstack.org/#/q/topic:update-fixtures-to-9.0
>> [3]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/doc/fixtures.rst
>> [4]
>> https://blueprints.launchpad.net/fuel/+spec/deployment-dryrun-fixtures-generator
>> [5]
>> https://github.com/openstack/fuel-noop-fixtures/blob/master/utils/generate_yamls.sh
>> [6] https://bugs.launchpad.net/fuel/+bug/1564919
>>
>
>
> __
> 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
>
>
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@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] [Openstack] Problem after reboot fuel-master VM
Samer, you could always use `dockerctl check all|` command. On Wed, Mar 30, 2016 at 2:47 PM, Adam Heczko wrote: > Samer my 2c are: > after Fuel node reboot just run 'docker ps -a' to get information if all > containers have been already running. > > On Wed, Mar 30, 2016 at 1:07 PM, Samer Machara < > samer.mach...@telecom-sudparis.eu> wrote: > >> Thanks, >>Problem solved by magic. It looks like, the nailgun service take >> some time to start up in my computer. >> >> -- >> *From: *"Samer Machara" >> *To: *"OpenStack Development Mailing List" < >> openstack-dev@lists.openstack.org> >> *Sent: *Wednesday, March 30, 2016 12:39:35 PM >> *Subject: *Re: [Fuel] [Openstack] Problem after reboot fuel-master VM >> >> >> Hi Vladimir, >> I'm using fuel 7.0, Which log I need to see? >> >> -- >> *From: *"*Vladimir Kuklin* vkuklin at mirantis.com >> >> *To: *"OpenStack Development Mailing List" < >> openstack-dev@lists.openstack.org> >> *Sent: **Wed Mar 30 10:06:22 UTC 2016* >> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM >> >> Hi, Samer >> >> It seems that Nailgun has not started. Could you please provide us with the >> version of Fuel you are using? You can find logs for nailgun in: >> >> for <9.0/pre-Mitaka versions >> /var/log//nailgun/ >> >> for current Mitaka: >> >> /var/log/nailgun/ >> >> -- >> *From: *"Samer Machara" >> *To: *"OpenStack Development Mailing List" < >> openstack-dev@lists.openstack.org> >> *Sent: *Wednesday, March 30, 2016 11:38:44 AM >> *Subject: *[Fuel] [Openstack] Problem after reboot fuel-master VM >> >> Hello, >> I have rebooted the "fuel-master" VM and after that, I cannot access >> the Fuel UI. What I am missing. Please check the image to see the error. >> >> Another question, How can I rediscover a node that was removed from >> the pool of available nodes, and also add new nodes to the pool. I clone a >> fuel-slave node but, it is not recognized by fuel >> >> Thanks in advance. >> >> >> >> >> __ >> 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 >> >> > > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [Openstack] Problem after reboot fuel-master VM
Hi, Samer It seems that Nailgun has not started. Could you please provide us with the version of Fuel you are using? You can find logs for nailgun in: for <9.0/pre-Mitaka versions /var/log//nailgun/ for current Mitaka: /var/log/nailgun/ On Wed, Mar 30, 2016 at 12:38 PM, Samer Machara < samer.mach...@telecom-sudparis.eu> wrote: > Hello, > I have rebooted the "fuel-master " VM and after that, I cannot access > the Fuel UI. What I am missing. Please check the image to see the error. > > Another question, How can I rediscover a node tha t was removed from > the pool of available nodes, and also add new nodes to the pool. I clone a > fuel-slave node but, it is not recognized by fuel > > Thanks in advance. > > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][plugins][ovs] NSH Query
Hi, Vikram ++ plugin authors explicitly On Wed, Mar 30, 2016 at 12:20 PM, Vikram Choudhary wrote: > Hi Folks, > > We were trying https://github.com/openstack/fuel-plugin-ovs.git, and has > below query: > > *Our Setup:* > SF > | > > Classifier---SFF > -Destination >|- vxlan-gpe tunnel with NSH -| > > *Query:* > 1. At SF, we want to receive the packet with NSH content but only the > payload is received as the 'NSH' part is removed when the vxlan header is > stripped off. In this regard, we would like to know what should be the > OVS flow-rule / Tunnel or equivalent config option for SFF, so that the NSH > header is retained in the packet while it's sent to the SF? > > 2. What is the use of "nsh_covert" option? > > Thanks > Vikram > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Getting rid of cluster status
Folks As I generally support the idea of getting rid of cluster status, this requires thorough design. My opinion here is that we should leave it as a function of nodes state until we come up with a variant of better calculation of cluster status. Nevertheless it is true that cluster status is actually a function of other primary data and should be calculated on the client side. I suggest that we move towards more fine-grained component-based architecture (simplest example is OpenStack Fuel vs non-OpenStack Fuel) and figure out a way of calculating each component's status. Then we should calculate each component's status and then a cluster status should be an aggregate of those. For example, we could say that the only components we have right now are nodes and the aggregate is based on the nodes status and whether they are critical or not. On Tue, Mar 15, 2016 at 9:16 PM, Andrew Woodward wrote: > > > On Tue, Mar 15, 2016 at 4:04 AM Roman Prykhodchenko wrote: > >> Fuelers, >> >> I would like to continue the series of "Getting rid of …" emails. This >> time I’d like to talk about statuses of clusters. >> >> The issues with that attribute is that it is not actually related to real >> world very much and represents nothing. A few month ago I proposed to make >> it more real-world-like [1] by replacing a simple string by an aggregated >> value. However, after task based deployment was introduced even that >> approach lost its connection to the real world. >> >> My idea is to get rid of that attribute from a cluster and start working >> with status of every single node in it. Nevertheless, we only have tasks >> that are executed on nodes now, so we cannot apply the "status" term to >> them. What if we replace that with a sort of boolean value called >> maintenance_mode (or similar) that we will use to tell if the node is >> operational or not. After that we will be able to use an aggregated >> property for cluster and check, if there are any nodes that are under a >> progress of performing some tasks on them. >> > > Yes, we still need an operations attribute, I'm not sure a bool is enough, > but you are quite correct, setting the status of the cluster after > operational == True based on the result of a specific node failing, is in > practice invalid. > > At the same time, operational == True is not necessarily deployment > succeeded, its more along the line of deployment validated, which may be > further testing passing like ostf, or more manual in the operator wants to > do more testing their own prior to changing the state. > > As we adventure in to the LCM flow, we actually need status of each > component in addition of the general status of the cluster to determine the > proper course of action the on the next operation. > > For example nova-compute > if the cluster is not operational, then we can provision compute nodes, > and have them enabled, or active in the scheduler automatically. However if > the cluster is operational, a new compute node must be disabled, or > otherwise blocked from the default scheduler until the node has received > validation. In this case the interpretation of operational is quite simple > > For example ceph > Here we care less about the status of the cluster (slightly, this example > ignores ceph's impact on nova-compute), and more about the status of the > service. In the case that we deploy ceph-osd's when their are not replica > factor osd hosts online (3) the we can provision the OSD's similar to > nova-compute, in that we can bring them all online and active and data > could be placed to them immediately (more or less). but if the ceph status > is operational, then we have to take a different action, the OSD's have to > be brought in disabled, and gradually(probably by the operator) have their > data weight increased so they don't clog the network with data peering > which causes the clients may woes. > > >> Thoughts, ideas? >> >> >> References: >> >> 1. https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status >> >> >> - romcheg >> __ >> 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 >> > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > __ > OpenStack Development Mailing List (
Re: [openstack-dev] [Fuel] Trouble mapping the Remote PXE node
Hi, Akshik Thanks for the email. Do you have nailgun logs with you? I guess, it would much more easier to debug this while having more diagnostic info. Please, file a bug at launchpad following the steps described here: https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Bugs then post the link to this thread. The diagnostic snapshot would give us more info on your environment configuration along with logs of Nailgun. Feel free to contact us again whether you face any issues filing the bug. On Fri, Mar 11, 2016 at 9:59 AM, Akshik dbk wrote: > Hi, > > I'm using Fuel 7.0, trying to evaluate remote compute and node group > > > I've configured a remote PXE and I'm able to boot the node successfully > onto the remote pxe, but while adding it to the environment and trying to > configure interface I'm stuck with following error > > > fuel node --node-id 43 --network upload > > DEPRECATION WARNING: /etc/fuel/client/config.yaml exists and will be used > as the source for settings. This behavior is deprecated. Please specify the > path to your custom settings file in the FUELCLIENT_CUSTOM_SETTINGS > environment variable. > > 400 Client Error: Bad Request (Node '43': '53' network(s) are left > unassigned) > > > the interface yams file is > > http://paste.openstack.org/show/490098/ > > > pls. help > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [FFE] Unlock Settings Tab
Vitaly Thanks for bringing this up. Actually the spec has been on review for almost 2 weeks: https://review.openstack.org/#/c/282695/. Essentially, this is not introducing new DSL but replacing the existing one with more powerful extendable language which is being actively developed within OpenStack and is already a part of other projects (Murano, Mistral), which has much more contributors, can return not only boolean but any arbitrary collections. So it means that we want to deprecate current Expression language that you wrote and replace it with YAQL due to those reasons. You are not going to extend this Expression-based language in 3 weeks up to level of support of extensions, method overloading, return of arbitrary collections (e.g. we also want to calculate cross-depends and requires fields on the fly which require for it to return list of dicts) and support of this stuff on your own, are you? On Wed, Mar 2, 2016 at 10:09 AM, Vitaly Kramskikh wrote: > I think it's not a part of best practices to introduce changes like > https://review.openstack.org/#/c/279714/ (adding yet another DSL to the > project) without a blueprint and review and discussion of the spec. > > 2016-03-02 2:19 GMT+07:00 Alexey Shtokolov : > >> Fuelers, >> >> I would like to request a feature freeze exception for "Unlock settings >> tab" feature [0] >> >> This feature being combined with Task-based deployment [1] and >> LCM-readiness for Fuel deployment tasks [2] unlocks Basic LCM in Fuel. We >> conducted a thorough redesign of this feature and splitted it into several >> granular changes [3]-[6] to allow users to change settings on deployed, >> partially deployed, stopped or erred clusters and further run redeployment >> using a particular graph (custom or calculated based on expected changes >> stored in DB) and with new parameters. >> >> We need 3 weeks after FF to finish this feature. >> Risk of not delivering it after 3 weeks is low. >> >> Patches on review or in progress: >> <https://review.openstack.org/#/c/284139/> >> https://review.openstack.org/#/c/284139/ >> https://review.openstack.org/#/c/279714/ >> https://review.openstack.org/#/c/286754/ >> https://review.openstack.org/#/c/286783/ >> >> Specs: >> https://review.openstack.org/#/c/286713/ >> https://review.openstack.org/#/c/284797/ >> https://review.openstack.org/#/c/282695/ >> https://review.openstack.org/#/c/284250/ >> >> >> [0] https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab >> <https://blueprints.launchpad.net/fuel/+spec/unlock-settings-tab>[1] >> https://blueprints.launchpad.net/fuel/+spec/enable-task-based-deployment >> [2] >> https://blueprints.launchpad.net/fuel/+spec/granular-task-lcm-readiness >> [3] >> https://blueprints.launchpad.net/fuel/+spec/computable-task-fields-yaql >> [4] >> https://blueprints.launchpad.net/fuel/+spec/store-deployment-tasks-history >> [5] https://blueprints.launchpad.net/fuel/+spec/custom-graph-execution >> [6] >> https://blueprints.launchpad.net/fuel/+spec/save-deployment-info-in-database >> >> -- >> --- >> WBR, Alexey Shtokolov >> >> __ >> 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 >> >> > > > -- > Vitaly Kramskikh, > Fuel UI Tech Lead, > Mirantis, Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Fuel-Library] Fuel CI issues
Dmitry >I don't think "hurried" is applicable here: the only way to become more >ready to track upstream than we already are is to *start* tracking >upstream. Postponing that leaves us in a Catch-22 situation where we >can't stay in sync with upstream because we're not continuously catching >up with upstream. First of all, if you read my email again, you will see that I propose a way of tracking upstream in less continuous mode with nightly testing and switching to it based on automated integration testing which will leave us 0 opportunity to face the aforementioned issues. >That would lock us into that Catch-22 situation where we can't allow >Fuel CI to vote on puppet-openstack commits because fuel-library is >always too far behind puppet-openstack for its votes to mean anything >useful. This is not true. We can run FUEL CI against any set of commits. > We have to approach this from the opposite direction: make Fuel CI > stable and meaningful enough so that, 9 times out of 10, Fuel CI failure > indicates a real problem with the code, and the remaining cases can be > quickly unblocked by pushing a catch-up commit to fuel-library (ideally > with a Depends-On tag). Dmitry, could you please point me at the person who will be strictly responsible for creating this 'ketchup' commit? Do you know that this may take up the whole day (couple of hours to do RCA, couple of hours on writing and debugging and couple of hours for FUEL CI tests run) and block the entire Fuel project from having ANY code merged? Taking into consideration that openstack infra is currently under really high load it may take even several days for the fix to land into master. How do you expect us to have any feature merged prior to FF? > It is a matter of trust between projects: do we trust Puppet OpenStack > project to take Fuel's problems seriously and to avoid breaking our CI > more often than necessary? Can Puppet OpenStack project trust us with > the same? So far, our collaboration track record has been pretty good > bordering on examplary, and I think we should build on that and move > forward instead of clinging to the old ways. > The problem with moving only one piece at a time is that you end up so > far behind that you're slowing everyone down. BKL and GIL are not the > only way to deal with concurrency, we can do better than that. I have always thought that buliding software is about verification being more important than 'trust'. There should not be any humanitarian stuff invloved - we are not in a relationship with Puppet-OpenStack folks, although I really admire their work very much. We should not follow sliding git references without being 100% sure that we have mutual gating of the code. Moreover, having such git ref as a source in our Puppetfile will lead to the situation when we have UNREPRODUCIBLE build of Fuel project. Each build may and will result in different code and you will not be able to tell which one without actually looking into the build logs. I think, that this is unacceptable as it may lead to impossibilty of debugging and troubleshooting of anything because it will be impossible to reproduce things. Additionally, we do not have: 1) depends-on support 2) any process instantiated for monitoring of the Puppet-Openstack FUEL CI job 3) any person responsible for monitoring of that job Finally, we have another blocker issue [0] which essentially killed March 1st in EU timezone from code merge point of view as our master is blocked right now by non-boostrapping master node. Having that said I propose that we: 1) immediately pick a set of stable commits to puppet-openstck 2) immediately update puppetfile with this set 3) unblock other fuel developers 4) fix the aforementioned issues 5) turn tracking of upstream commits on when we have all the pieces set up and when we are sure that we will not ever break master with this change. [0] https://bugs.launchpad.net/fuel/+bug/1551584 On Tue, Mar 1, 2016 at 5:10 AM, Dmitry Borodaenko wrote: > On Mon, Feb 29, 2016 at 01:19:29PM +0300, Vladimir Kuklin wrote: > > Thanks for bringing this up. Frankly, I think that we hurried a little > bit > > by making our integration with upstream puppet manifests too continuous. > I > > would suppose that we used a little bit different technique. > > I don't think "hurried" is applicable here: the only way to become more > ready to track upstream than we already are is to *start* tracking > upstream. Postponing that leaves us in a Catch-22 situation where we > can't stay in sync with upstream because we're not continuously catching > up with upstream. > > > First of all, we need to have a set of stable Fuel commits against which > > the changes to upstream manifests should be tested. Could you please > > e
Re: [openstack-dev] [Fuel][Fuel-Library] Fuel CI issues
Hi Ivan Thanks for bringing this up. Frankly, I think that we hurried a little bit by making our integration with upstream puppet manifests too continuous. I would suppose that we used a little bit different technique. First of all, we need to have a set of stable Fuel commits against which the changes to upstream manifests should be tested. Could you please elaborate on whether we are doing this already? Secondly, we need to have FUEL CI working with a set of stable commits of puppet openstack manifests which passed those upstream tests as we should not have too much moving parts or we will get into situation similar to requirements.txt updates when we have pypi updated with new library, e.g. oslo-serialization. In this case, we will be able to do proper testing against frozen code-base for each piece thus avoiding such issues while retaining fair amount of integration with upstream puppet manifests for OpenStack. So what do you think? On Fri, Feb 26, 2016 at 1:28 PM, Ivan Berezovskiy wrote: > Hello, Fuelers! > > Yesterday we've faced an issue which came from puppet-neutron > module: LP #1549934 <https://bugs.launchpad.net/fuel/+bug/1549934>. Fix > was prepared very fast: > https://review.openstack.org/#/c/284882/ (thanks Sergey for this). > So, If CI is red on your patch please re-base it on top of master. > > Anyway, this issue affected a lot of patches and blocked some developers, > because BVT and neutron_smoke tests was also broken. We need to find > a way how to minimize risks and affection of such changes on fuel-library. > We have jobs which monitors upstream patches: > https://ci.fuel-infra.org/view/puppet-openstack/ > Let's start to monitor those jobs on daily basis. We should have at least 1 > (ideally 2 or more) engineers which are responsible for analysis of those > CI failures. If patch to puppet module is incorrect - we should review it > with explanation what is actually wrong. If patch is correct, but breaks > current Fuel CI, it means that problem is in our side and we should prepare > fuel-library adapt patch to fix the issue. Ideally, we should have an > ability > to test this fuel-library patch together with upstream one e.g. using > 'Depends on' > in commit message. > > Thoughts? > > -- > Thanks, Ivan Berezovskiy > MOS Puppet Team Lead > at Mirantis <https://www.mirantis.com/> > > slack: iberezovskiy > skype: bouhforever > phone: + 7-960-343-42-46 > > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Fuel-Library] Nominating Matthew Mosesohn for Fuel Library Core
Fellow Fuelers I would like to kindly ask you to consider voting for Matthew Mosesohn as a Fuel Library Core reviewer. Matthew has been working with Fuel since its inception, worked on countless amount of features, such as : Master Node Upgrades and Backup Improvements to Fuel Infra Mitaka, Kilo and Juno Support Detachable Services Plugins RHOS Support in Fuel UCA Support Refactoring of Haproxy and Firewall pieces He has also been known as our Fuel Master node and Docker guru and has been continuously working on bugfixing where he scores as a bug squashing monster with more than 150 bugfixes to all the parts of Fuel Library (#1 throughout FL history). As you can see, there is not a piece of Fuel Library that he has not yet gained experience with. And this can easily be fetched with simple statistics of Matt's contribution. He is the topmost contributor to all Fuel projects among all Fuel Library folks and is the 3rd contributor of Fuel Library. He also reviews a lot and has a fair amount of -1's (he is not as cruel as me, though :-)) Having that said, I would like to open the vote to promote Matt to OpenStack Fuel Library core reviewers. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Merge freeze for CI switch to Mitaka
Folks First of all, there is a critical bug which is not fixed. It may be floating because it is related to implicit resources ordering in puppet. But it does not mean that it is not a merge blocker. Secondly, I do not share your optimism about easiness of bugfixing of possible regressions because I do not see results of more complete testing of such changes. Additionally, there was no preliminary discussion about this change. You did not give us enough time to express our opinion. For example, the original email was sent after 8pm msk and I had already left the office. Finally goes my constructive proposal. 1) merge the fix https://review.openstack.org/281440 2) get several consecutive green bvts 3) in meantime drag this mitaka iso through swarm 4) compare the results and merge mitaka iso on Saturday if no criticals are found. Saturday is a working day in Russia, so there will be low dev activity and we will be able to control the swarm run. 17 февр. 2016 г. 21:06 пользователь "Igor Kalnitsky" < ikalnit...@mirantis.com> написал: > Vladimir, > > Obviously, there will be regressions in other scenarios. However, it's > better to catch them now. We have not much time before FF, and it'd be > better to merge such features as early as possible, and do not wait > for merge hell a day before FF. > > The thing we need to know is that BVT is green, and that means most > developers aren't blocked. > > Thanks, > Igor > > On Wed, Feb 17, 2016 at 7:48 PM, Vladimir Kuklin > wrote: > > Fuelers > > > > I have strong opinion against this merge freeze right now. We have > critical > > bugs blocking bvt and we do not have enough info on mitaka readiness for > > other scenarios than bvt. > > > > 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko" > > написал: > > > >> Fuel core reviewers, > >> > >> Fuel CI is being migrated to an ISO image with Mitaka packages, please > >> don't merge any commits to any Fuel repositories without coordination > >> with Aleksandra until further notice. > >> > >> This merge freeze is expected to last a few hours. > >> > >> -- > >> Dmitry Borodaenko > >> > >> > __ > >> 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 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] Merge freeze for CI switch to Mitaka
Fuelers I have strong opinion against this merge freeze right now. We have critical bugs blocking bvt and we do not have enough info on mitaka readiness for other scenarios than bvt. 17 февр. 2016 г. 20:45 пользователь "Dmitry Borodaenko" < dborodae...@mirantis.com> написал: > Fuel core reviewers, > > Fuel CI is being migrated to an ISO image with Mitaka packages, please > don't merge any commits to any Fuel repositories without coordination > with Aleksandra until further notice. > > This merge freeze is expected to last a few hours. > > -- > Dmitry Borodaenko > > __ > 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-dev] [Fuel][Puppet] New Rspec Noop Tests Matcher to Ensure Transitive Dependencies
Fuelers
It seems that this change [0] into Fuel came unnoticed, but it may help you
in testing your puppet catalogues.
I was refactoring our code pieces that actually wait for Load Balancer to
be ready to serve requests. I ended putting things into a special define
called `wait_for_backend`. This broke direct dependencies between resources
as there was only transitive order between them (e.g. A->B->C) instead of
direct (A->C). And this broke our noop tests as they were expecting to see
the latter ordering. This in turn required me to write an additional
matcher based on puppet source code.
[0] https://review.openstack.org/#/c/272702/
Here is an example of the code you might want to use in your rspecs:
`expect(graph).to
ensure_transitive_dependency("Class[openstack::galera::status]",
"Haproxy_backend_status[mysql]")`
graph is lazy calculated within noop tests shared_examples.
So, if you need to just check if one resource will execute after the
another, you do not need 'that_comes_[before|after]' anymore.
Puppeters
Folks, this may be also interesting for you.
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@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][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?
ck-dev >>> >> -- >> Dr. Pavlo Shchelokovskyy >> Senior Software Engineer >> Mirantis Inc >> www.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 >> > -- > -- > Andrew Woodward > Mirantis > Fuel Community Ambassador > Ceph Community > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Task Based Deployment Is at Least Twice Faster
gt;> In case of 4 cores for 7 VMs they are fighting for CPU resources
> and
> >> >>>> it
> >> >>>> marginalizes the gain of task-based deployment
> >> >>>>
> >> >>>> Fuel CI slaves with *6* cores *~1.6* times faster
> >> >>>>
> >> >>>> Fuel CI slaves with *12* cores *~1.7* times faster
> >> >>>
> >> >>> These are really outstanding results!
> >> >>> (tl;dr)
> >> >>> I believe the next step may be to leverage the "external install &
> svc
> >> >>> management" feature (example [1]) of the Liberty release (7.0.0) of
> >> >>> Puppet-Openstack (PO) modules. So we could use separate concurrent
> >> >>> cross-depends based tasks *within a single node* as well, like:
> >> >>> - task: install_all_packages - a singleton task for a node,
> >> >>> - task: [configure_x, for each x] - concurrent for a node,
> >> >>> - task: [manage_service_x, for each x] - some may be concurrent for
> a
> >> >>> node, while another shall be serialized.
> >> >>>
> >> >>> So, one might use the "--tags" separator for concurrent puppet runs
> to
> >> >>> make things go even faster, for example:
> >> >>>
> >> >>> # cat test.pp
> >> >>> notify
> >> >>> {"A": tag => "a" }
> >> >>> notify
> >> >>> {"B": tag => "b" }
> >> >>>
> >> >>> # puppet apply test.pp
> >> >>> Notice: A
> >> >>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as
> 'A'
> >> >>> Notice: B
> >> >>> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as
> 'B'
> >> >>>
> >> >>> # puppet apply test.pp --tags a
> >> >>> Notice: A
> >> >>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as
> 'A'
> >> >>>
> >> >>> # puppet apply test.pp --tags a & puppet apply test.pp --tags b
> >> >>> Notice: B
> >> >>> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as
> 'B'
> >> >>> Notice: A
> >> >>> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as
> 'A'
> >> >>>
> >> >>> Which is supposed to be faster, although not for this example.
> >> >>>
> >> >>> [1] https://review.openstack.org/#/c/216926/3/manifests/init.pp
> >> >>>
> >> >>>>
> >> >>>> You can see additional information and charts in the presentation
> >> >>>> [3].
> >> >>>>
> >> >>>> [0]
> >> >>>> -
> >> >>>>
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html
> >> >>>> [1]
> >> >>>> -
> >> >>>>
> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html
> >> >>>> [2] - 3 x HP ProLiant DL360p Gen8 (XeonE5 6 cores/64GB/SSD) + 7 x
> >> >>>> HP
> >> >>>> ProLiant DL320p Gen8 (XeonE3 4 cores/8-16GB/HDD)
> >> >>>> [3] -
> >> >>>>
> >> >>>>
> https://docs.google.com/presentation/d/1jZCFZlXHs_VhjtVYS2VuWgdxge5Q6sOMLz4bRLuw7YE
> >> >>>>
> >> >>>> ---
> >> >>>> WBR, Alexey Shtokolov
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> __
> >> >>>> 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
> >> >>>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Best regards,
> >> >>> Bogdan Dobrelya,
> >> >>> Irc #bogdando
> >> >>>
> >> >>>
> >> >>>
> __
> >> >>> 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
> >> >>
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Bogdan Dobrelya,
> >> > Irc #bogdando
> >> >
> >> >
> >> >
> __
> >> > 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
> >
> >
> >
> >
> > --
> > ---
> > WBR, Alexey Shtokolov
> >
> >
> __
> > 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
>
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@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] [oslo][doc][fuel] Removal of logging use_syslog_rfc_format configuration option
Ronald Thanks a lot notifying us - very much appreciated! Ivan, this might be of interest for your team. On Thu, Feb 4, 2016 at 9:37 PM, Ronald Bradford wrote: > In Mitaka we are planning on removing the deprecated logging configuration > option use_syslog_rfc_format [1] > > Matches in openstack-manuals [2] and fuel-library puppet modules [3] > should be removed to avoid any dated documentation or errors in operation > respectively. > > This option can also be found as a comment in sample configuration files > of multiple projects which should be removed automatically if these files > are generated via Sphinx. > In other projects using legacy Oslo Incubator code, this option is in > place. These projects should consider migrating to the olso.log library. > > Regards > > Ronald > > [1] https://review.openstack.org/#/c/263785/ > [2] > http://codesearch.openstack.org/?q=use_syslog_rfc_format&i=nope&files=&repos=openstack-manuals > [3] > http://codesearch.openstack.org/?q=use_syslog_rfc_format&i=nope&files=&repos=fuel-library > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] CentOS bootstrap image retirement
+1 On Wed, Feb 3, 2016 at 4:45 PM, Igor Kalnitsky wrote: > No objections from my side. Let's do it. > > On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov > wrote: > > Hi Sergey, > > > > I fully support this idea. It was our plan as well when we were > developing > > Ubuntu Bootstrap feature. So let's proceed with CentOS bootstrap removal. > > > > BR, > > Dmitry. > > > > On Tue, Feb 2, 2016 at 2:55 PM, Sergey Kulanov > > wrote: > >> > >> Hi Folks, > >> > >> I think it's time to declare CentOS bootstrap image retirement. > >> Since Fuel 8.0 we've switched to Ubuntu bootstrap image usage [1, 2] and > >> CentOS one became deprecated, > >> so in Fuel 9.0 we can freely remove it [2]. > >> For now we are building CentOS bootstrap image together with ISO and > then > >> package it into rpm [3], so by removing fuel-bootstrap-image [3] we: > >> > >> * simplify patching/update story, since we don't need to rebuild/deliver > >> this > >> package on changes in dependent packages [4]. > >> > >> * speed-up ISO build process, since building centos bootstrap image > takes > >> ~ 20% > >> of build-iso time. > >> > >> We've prepared related blueprint for this change [5] and spec [6]. We > also > >> have some draft patchsets [7] > >> which passed BVT tests. > >> > >> So the next steps are: > >> * get feedback by reviewing the spec/patches; > >> * remove related code from the rest fuel projects (fuel-menu, > fuel-devops, > >> fuel-qa). > >> > >> > >> Thank you > >> > >> > >> [1] > >> > https://specs.openstack.org/openstack/fuel-specs/specs/7.0/fuel-bootstrap-on-ubuntu.html > >> [2] > >> > https://specs.openstack.org/openstack/fuel-specs/specs/8.0/dynamically-build-bootstrap.html > >> [3] > >> > https://github.com/openstack/fuel-main/blob/master/packages/rpm/specs/fuel-bootstrap-image.spec > >> [4] > >> > https://github.com/openstack/fuel-main/blob/master/bootstrap/module.mk#L12-L50 > >> [5] > >> > https://blueprints.launchpad.net/fuel/+spec/remove-centos-bootstrap-from-fuel > >> [6] https://review.openstack.org/#/c/273159/ > >> [7] > >> > https://review.openstack.org/#/q/topic:bp/remove-centos-bootstrap-from-fuel > >> > >> > >> -- > >> Sergey > >> DevOps Engineer > >> IRC: SergK > >> Skype: Sergey_kul > >> > >> > __ > >> 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [Fuel UI] Node role list grouping
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 > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [Fuel UI] Node role list grouping
Sergii I disagree with you here a little bit. Role abstraction is a useful thing from high-level standpoint. I would suggest that this list of roles grouping, e.g. which roles are mandatory and which are configured within which group can be specified: 1) in global settings of Nailgun 2) per-plugin 3) per environment in UI This should cover all the cases even for very flexible roles allocation. On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk < sgolovat...@mirantis.com> wrote: > Hi, > > > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich > wrote: > >> Hi folks, >> >> Our team has started a redesign of node roles panel [1] on Add Nodes/Edit >> Roles screens in Fuel UI. >> Currently, node roles panel takes a big part of the screen and User have >> to scroll down to node list to check nodes and then scroll up again to >> check roles. This becomes more actual for desktops with a small screen. >> >> And we faced with the question of grouping new role containers in the >> panel. There is out initial suggestion [2]: >> >> [image: role-list-grouping-1.png] >> >>- the first group (the first line on the screenshot) is roles which >>are required or recommended for deployment (controller, compute, cinder, >>etc.). >> >> It's not true. There can be deployments without Controllers or without > computes or without Storage. > >> >>- the second group is optional roles which are not mandatory for >>deployment (base-os, virt, etc.) >>- the last group is roles which are unavailable at the moment because >>of some restrictions. For example, mongo role can not be assigned to a >> node >>if ceilometer setting is not enabled on Settings tab >> >> BUT there is also a suggestion [3] (see comment #6) to add a new role >> 'category' attribute into its yaml description [4] that will reflect the >> role function. >> For example, cinder, ceph-osd, cinder-vmware roles are from Storage >> category; compute, ironic are Compute and so on. >> This new 'category' attribute will also allow proper calculating of an >> environment capacity: it does not make sense to count CPU and RAM of >> non-compute nodes or HDD of non-storage nodes. >> >> So, we have an initial proposal for such a grouping by a role category: >> >> CONTROLLER: controller >> COMPUTE: compute, virt, compute-vmware, ironic >> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd >> OTHER: base-os, mongo >> >> And we ask your help to review this grouping, i.e. to define the list of >> possible role categories and to distribute the roles between these >> categories. >> > > We removed role as abstraction from library. It's very very artificial > abstraction. Instead we use tasks, grouping them to different combinations. > That allows plugin developers to adjust reference architecture to their > needs. > > >> >> Best regards, >> Julia >> >> P.S. We also should take into account, that Fuel plugins can also provide >> their own roles. >> >> [1] >> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel >> [2] >> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png >> [3] https://bugs.launchpad.net/fuel/+bug/1375750 >> [4] >> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142 >> >> >> __ >> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Overriding and removing VIPs from plugins
+1 to overriding VIPs On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko wrote: > Folks, > > currently merge policy for network roles only allows to add new VIPs to > already existing roles [1]. If a plugin supplies a VIP with a name that > already exists but with different parameters, Nailgun will not allow to do > that. We faced a need to override configuration of several VIPs by > completely removing them from network roles by supplying something like > [2]. To enable that I’ve made a temporary workaround [3] to the merging > policy that only handles one cornerstone. > > I’ve talked to ikalnitsky and we realized that this functionality of > merging new VIPs from plugins to an existing network role is actually wrong > and should be replaced by complete overriding. Let’s discuss this > possibility here. > > > References: > > 1. > https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55 > 2. http://xsnippet.org/361361/ > 3. https://review.openstack.org/#/c/273169/1 > > > - romcheg > > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] RabbitMQ in dedicated network
nsubscribe > >> < > http://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 > >> > > > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > __ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] RabbitMQ in dedicated network
Kyrylo One comment here. Hostname on the nodes resolves to its management network as it is put into /etc/hosts file during the deployment. On Wed, Dec 23, 2015 at 9:27 PM, Alexey Lebedeff wrote: > > When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME > environment variable), you could actually use IP-address as a node name. > > Matthew Mosesohn writes: > > > I agree. As far as I remember, rabbit needs fqdns to work and map > > correctly. I think it means we should disable the ability to move the > > internal messaging network role in order to fix this bug until we can add > > extra dns entries per network role (or at least addr) > > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" > wrote: > > > >> Hi Kirill, > >> > >> I don't think we can give up on using fqdn node names for RabbitMQ > because > >> we need to support TLS in the future. > >> > >> Thanks, > >> Andrey Maximov > >> Fuel Project Manager > >> > >> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov > >> wrote: > >> > >>> Hello, > >>> > >>> I would like to start discussion regarding the issue we have discovered > >>> recently [1]. > >>> > >>> In a nutshell, if RabbitMQ is configured to run in separate > >>> mgmt/messaging network it fails on building cluster. > >>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is > >>> built using FQDN. Apparently, FQDN resolves to admin network which is > >>> different in this particular case. > >>> As a result, RabbitMQ on secondary controller node fails to join to > >>> primary controller node. > >>> > >>> I can suggest two ways to tackle the issue: one is pretty simple, while > >>> other is not. > >>> > >>> The first way is to accept by design using admin network for RabbitMQ > >>> internal communication between controller nodes. > >>> > >>> The second way is to dig into pacemaker and RabbitMQ reconfiguration. > >>> Since it requires to refuse from using common fqdn/node names, this > >>> approach can be argued. > >>> > >>> > >>> -- > >>> [1] https://bugs.launchpad.net/fuel/+bug/1528707 > >>> > >>> Best regards, > >>> Kyrylo > > __ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][UX] Throw KVM\QEMU and leave Libvirt on Wizard
+1 to Andrey On Mon, Dec 21, 2015 at 6:12 PM, Andrey Danin wrote: > I suggest to call this item in the Wizard as "QEMU-KVM" with the following > description: > "Select this option if you want to use QEMU as a hypervisor with > capability of KVM acceleration." > > On Mon, Dec 21, 2015 at 5:22 PM, Igor Kalnitsky > wrote: > >> > Qemu is not a hypervisor This will be even more confusing. >> >> It looks like hypervisor much more than libvirt. Moreover, according >> to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor. >> >> [1] https://en.wikipedia.org/wiki/Hypervisor >> >> > Today, when a user selects KVM, Fuel attempts to use KVM acceleration >> and >> > defaults to QEMU in the case that KVM acceleration is not possible. >> >> Sheena, are you sure it works this way? Some time ago we didn't >> support this. However, I fully support this idea and believe this is >> the way to go. In this case the hypervisor entry could be called >> something like "Qemu (+ KVM if available)". >> >> >> On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson >> wrote: >> > We should collapse this into one entry - I don't have any preference on >> > the naming convention, but as Fuel checks to see whether the hardware is >> > capable of performing KVM acceleration, there's no reason to continue >> > giving a selection to the user regarding KVM. >> > >> > Today, when a user selects KVM, Fuel attempts to use KVM acceleration >> and >> > defaults to QEMU in the case that KVM acceleration is not possible. We >> > should keep this behavior and make the entry a single KVM/QEMU selection >> > to eliminate the false perception of choice (and the ability for users >> to >> > select the incorrect option). >> > >> > -Original Message- >> > From: Bob Ball [mailto:bob.b...@citrix.com] >> > Sent: Monday, December 21, 2015 7:32 AM >> > To: OpenStack Development Mailing List (not for usage questions) >> > >> > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt >> > on Wizard >> > >> >> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky >> >> >> >> wrote: >> >> > What about hypervisor "Qemu", and checkbox option on Settings tab - >> >> > "Use KVM extension"? >> >> Qemu is not a hypervisor This will be even more confusing. >> >> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok. >> > >> > Libvirt isn't a hypervisor either. Note that Xen, Virtuozzo CT, >> Virtuozzo >> > VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with >> > Libvirt and OpenStack (taken from >> > http://docs.openstack.org/developer/nova/support-matrix.html) >> > >> > Bob >> > >> > >> __ >> > 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 >> > > > > -- > Andrey Danin > ada...@mirantis.com > skype: gcon.monolake > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Proposal to Delay Docker Removal From Fuel Master Node
Vladimir I am pretty much for removing docker, but I do not think that we should startle our developers/QA folks with additional efforts on fixing 2 different environments. Let's just think from the point of development velocity here and at delay such changes for at least after NY. Because if we do it immediately after SCF there will be a whole bunch of holidays and Russian holidays are Jan 1st-10th and you (who is the SME for docker removal) will be offline. Do you really want to fix things instead of enjoying holidays? On Wed, Dec 16, 2015 at 4:09 PM, Evgeniy L wrote: > +1 to Vladimir Kozhukalov, > > Entire point of moving branches creation to SCF was to perform such > changes as > early as possible in the release, I see no reasons to wait for HCF. > > Thanks, > > On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com> wrote: > >> -1 >> >> We already discussed this and we have made a decision to move stable >> branch creation from HCF to SCF. There were reasons for this. We agreed >> that once stable branch is created, master becomes open for new features. >> Let's avoid discussing this again. >> >> Vladimir Kozhukalov >> >> On Wed, Dec 16, 2015 at 9:55 AM, Bulat Gaifullin > > wrote: >> >>> +1 >>> >>> Regards, >>> Bulat Gaifullin >>> Mirantis Inc. >>> >>> >>> >>> On 15 Dec 2015, at 22:19, Andrew Maksimov >>> wrote: >>> >>> +1 >>> >>> Regards, >>> Andrey Maximov >>> Fuel Project Manager >>> >>> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin >>> wrote: >>> >>>> Folks >>>> >>>> This email is a proposal to push Docker containers removal from the >>>> master node to the date beyond 8.0 HCF. >>>> >>>> Here is why I propose to do so. >>>> >>>> Removal of Docker is a rather invasive change and may introduce a lot >>>> of regressions. It is well may affect how bugs are fixed - we might have 2 >>>> ways of fixing them, while during SCF of 8.0 this may affect velocity of >>>> bug fixing as you need to fix bugs in master prior to fixing them in stable >>>> branches. This actually may significantly increase our bugfixing pace and >>>> put 8.0 GA release on risk. >>>> >>>> >>>> >>>> -- >>>> Yours Faithfully, >>>> Vladimir Kuklin, >>>> Fuel Library Tech Lead, >>>> Mirantis, Inc. >>>> +7 (495) 640-49-04 >>>> +7 (926) 702-39-68 >>>> Skype kuklinvv >>>> 35bk3, Vorontsovskaya Str. >>>> Moscow, Russia, >>>> www.mirantis.com <http://www.mirantis.ru/> >>>> www.mirantis.ru >>>> vkuk...@mirantis.com >>>> >>>> >>>> __ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://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 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] PostgreSQL 9.3 and JSON operations
Igor Sorry, this vote is irrelevant as it is not about all the concerns rasied by Artem, Aleksandra and me. It is about JSON vs non-JSON Postgres which is not exactly the case. On Tue, Dec 15, 2015 at 9:47 PM, Igor Kalnitsky wrote: > FYI: so far (according to poll [1]) we have > > * 11 votes for keeping 9.2 > * 4 votes for restoring 9.3 > > [1] > https://docs.google.com/spreadsheets/d/1RNcEVFsg7GdHIXlJl-6LCELhlwQ_zmTbd40Bk_jH1m4/edit?usp=sharing > > On Tue, Dec 15, 2015 at 8:34 PM, Vladimir Kuklin > wrote: > > Folks > > > > Let me add my 2c here. > > > > I am for using Postgres 9.3. Here is an additional argument to the ones > > provided by Artem, Aleksandra and others. > > > > Fuel is being sometimes highly customized by our users for their specific > > needs. It has been Postgres 9.3 for a while and they might have as well > > gotten used to it and assumed by default that this would not change. So > some > > of their respective features they are developing for their own sake may > > depend on Postgres 9.3 and we will never be able to tell the fraction of > > such use cases. Moreover, downgrading DBMS version of Fuel should be > > inevitably considered as a 'deprecation' of some features our software > suite > > is providing to our users. This actually means that we MUST provide our > > users with a warning and deprecation period to allow them to adjust to > these > > changes. Obviously, accidental change of Postgres version does not follow > > such a policy in any way. So I see no other ways except for getting back > to > > Postgres 9.3. > > > > > > On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky > > > wrote: > >> > >> Hey Mike, > >> > >> Thanks for your input. > >> > >> > actually not. if you replace your ARRAY columns with JSON entirely, > >> > >> It still needs to fix the code, i.e. change ARRAY-specific queries > >> with JSON ones around the code. ;) > >> > >> > there's already a mostly finished PR for SQLAlchemy support in the > >> > queue. > >> > >> Does it mean SQLAlchemy will have one unified interface to make JSON > >> queries? So we can use different backends if necessary? > >> > >> Thanks, > >> - Igor > >> > >> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer wrote: > >> > > >> > > >> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote: > >> >> Hey Julien, > >> >> > >> >>> > >> >>> > https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql > >> >> > >> >> I believe this blueprint is about DB for OpenStack cloud (we use > >> >> Galera now), while here we're talking about DB backend for Fuel > >> >> itself. Fuel has a separate node (so called Fuel Master) and we use > >> >> PostgreSQL now. > >> >> > >> >>> does that mean Fuel is only going to be able to run with PostgreSQL? > >> >> > >> >> Unfortunately we already tied up to PostgreSQL. For instance, we use > >> >> PostgreSQL's ARRAY column type. Introducing JSON column is one more > >> >> way to tighten knots harder. > >> > > >> > actually not. if you replace your ARRAY columns with JSON entirely, > >> > MySQL has JSON as well now: > >> > https://dev.mysql.com/doc/refman/5.7/en/json.html > >> > > >> > there's already a mostly finished PR for SQLAlchemy support in the > >> > queue. > >> > > >> > > >> > > >> >> > >> >> - Igor > >> >> > >> >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou > >> >> wrote: > >> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote: > >> >>> > >> >>>> The things I want to notice are: > >> >>>> > >> >>>> * Currently we aren't tied up to PostgreSQL 9.3. > >> >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by > using a > >> >>>> set of JSON operations. > >> >>> > >> >>> I'm curious and have just a small side question: does that mean Fuel > >> >>> is > >> >>> only going to be able to run with PostgreSQL? > >> >>> > >> >>> I also see > >> >>> > >> &g
Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations
Folks Let me add my 2c here. I am for using Postgres 9.3. Here is an additional argument to the ones provided by Artem, Aleksandra and others. Fuel is being sometimes highly customized by our users for their specific needs. It has been Postgres 9.3 for a while and they might have as well gotten used to it and assumed by default that this would not change. So some of their respective features they are developing for their own sake may depend on Postgres 9.3 and we will never be able to tell the fraction of such use cases. Moreover, downgrading DBMS version of Fuel should be inevitably considered as a 'deprecation' of some features our software suite is providing to our users. This actually means that we MUST provide our users with a warning and deprecation period to allow them to adjust to these changes. Obviously, accidental change of Postgres version does not follow such a policy in any way. So I see no other ways except for getting back to Postgres 9.3. On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky wrote: > Hey Mike, > > Thanks for your input. > > > actually not. if you replace your ARRAY columns with JSON entirely, > > It still needs to fix the code, i.e. change ARRAY-specific queries > with JSON ones around the code. ;) > > > there's already a mostly finished PR for SQLAlchemy support in the queue. > > Does it mean SQLAlchemy will have one unified interface to make JSON > queries? So we can use different backends if necessary? > > Thanks, > - Igor > > On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer wrote: > > > > > > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote: > >> Hey Julien, > >> > >>> > https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql > >> > >> I believe this blueprint is about DB for OpenStack cloud (we use > >> Galera now), while here we're talking about DB backend for Fuel > >> itself. Fuel has a separate node (so called Fuel Master) and we use > >> PostgreSQL now. > >> > >>> does that mean Fuel is only going to be able to run with PostgreSQL? > >> > >> Unfortunately we already tied up to PostgreSQL. For instance, we use > >> PostgreSQL's ARRAY column type. Introducing JSON column is one more > >> way to tighten knots harder. > > > > actually not. if you replace your ARRAY columns with JSON entirely, > > MySQL has JSON as well now: > > https://dev.mysql.com/doc/refman/5.7/en/json.html > > > > there's already a mostly finished PR for SQLAlchemy support in the queue. > > > > > > > >> > >> - Igor > >> > >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou > wrote: > >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote: > >>> > >>>> The things I want to notice are: > >>>> > >>>> * Currently we aren't tied up to PostgreSQL 9.3. > >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using a > >>>> set of JSON operations. > >>> > >>> I'm curious and have just a small side question: does that mean Fuel is > >>> only going to be able to run with PostgreSQL? > >>> > >>> I also see > >>> > https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql, > >>> maybe it's related? > >>> > >>> Thanks! > >>> > >>> -- > >>> Julien Danjou > >>> // Free Software hacker > >>> // https://julien.danjou.info > >> > >> > __ > >> 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Proposal to Delay Docker Removal From Fuel Master Node
Folks This email is a proposal to push Docker containers removal from the master node to the date beyond 8.0 HCF. Here is why I propose to do so. Removal of Docker is a rather invasive change and may introduce a lot of regressions. It is well may affect how bugs are fixed - we might have 2 ways of fixing them, while during SCF of 8.0 this may affect velocity of bug fixing as you need to fix bugs in master prior to fixing them in stable branches. This actually may significantly increase our bugfixing pace and put 8.0 GA release on risk. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Experimental Task Based Deployment Landed into Master
Fuelers I am thrilled to announce that task based deployment engine [0] has been just merged into Fuel master. We checked it against existing BVT test cases for regressions as well as against functional testing for several cases of deployment. All the OSTF and network verification tests have successfully passed. We will obviously need to polish it and fix bugs which will arise, but this is a gigantic step forward for our orchestration engine which should allow us to drastically increase our development velocity as well as end user experience. Thanks to all who participated in development testing and review: Dmitry Ilyin Vladimir Sharshov Bulat Gaifullin Alexey Shtokolov Igor Kalnitsky Evgeniy Li Sergii Golovatiuk Dmitry Shulyak and many-many others I am pretty confident that this will allow us to develop and test faster as well as introduce support of some of Life-Cycle Management scenarios in 8.0 release. Once again, thank you all, folks, for your dedicated work and efforts on making Fuel better. [0] https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][plugins]Security problem in Fuel 7.0
t; Alexey, >>>>>> >>>>>> thank you for bringing this up. IMO discussing security problems is >>>>>> better to be done in a special kind of Launchpad bugs. >>>>>> >>>>>> - romcheg >>>>>> >>>>>> >>>>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin >>>>>> написав(ла): >>>>>> > >>>>>> > Hello all, >>>>>> > >>>>>> > We have a security problem in Fuel 7.0. It's related to plugin >>>>>> > development and allows to execute code in mcollective docker >>>>>> container >>>>>> > on Fuel master node. Any fuel plugin may contains a yaml file with >>>>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there >>>>>> is >>>>>> > an ability to run some code on node with role "master". It's also >>>>>> > possible to connect to any target node via ssh without a password >>>>>> from >>>>>> > within the container. >>>>>> > >>>>>> > As i understood, it was made to simplify some deployment cases. I >>>>>> see >>>>>> > some steps for resolving this situation: >>>>>> > 1. Fuel team should disallow >>>>>> > execution of any puppet manifests or bash code on nodes with master >>>>>> > role. >>>>>> > 2. Append the Fuel documentation. Notify users about this >>>>>> > security issue. >>>>>> > >>>>>> > What do you think about it? What deployment cases which require >>>>>> > execution of code on role "master" do you know? >>>>>> > >>>>>> > -- >>>>>> > Best regards, >>>>>> > Alexey >>>>>> > Deployment Engineer >>>>>> > Mirantis, Inc >>>>>> > Cell: +7 (968) 880 2288 <%2B7%20%28968%29%20880%202288> >>>>>> > Skype: shikelbober >>>>>> > Slack: aelagin >>>>>> > mailto:aela...@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 >>>>>> >>>>>> >>>>> >>>>> __ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>>> -- >>>>> Eugene Korekin >>>>> Partner Enablement Team Deployment Engineer >>>>> >>>>> >>>>> __ >>>>> 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 >>>>> >>>> -- >>>> >>>> -- >>>> >>>> Andrew Woodward >>>> >>>> Mirantis >>>> >>>> Fuel Community Ambassador >>>> >>>> Ceph Community >>>> >>>> >>>> __ >>>> 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> -- >>> Eugene Korekin >>> Partner Enablement Team Deployment Engineer >>> >>> >>> >>> __ >>> 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 >> > -- > > -- > > Andrew Woodward > > Mirantis > > Fuel Community Ambassador > > Ceph Community > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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
o 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 >> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] FFE request for erlang and rabbitmq-server packaged for centos7
Andrey I think this request is about updating RPM version of erlang which relates only to master node here. On Thu, Dec 3, 2015 at 3:48 PM, Andrey Sledzinskiy < asledzins...@mirantis.com> wrote: > Hi everybody, > please, note that we faced next issue [0] during 7.0-MU1 testing and one > of the possible solutions was to upgrade rabbitmq to 3.5.5. > This issue is also present in 8.0 and affects at least one SWARM > destructive test. > > [0] https://bugs.launchpad.net/fuel/+bug/1513511 > > On Thu, Dec 3, 2015 at 1:32 AM, Mike Scherbakov > wrote: > >> Based on time of this request, you seem to be late to the party... >> FF is in action. Formally it was requested before FF, but as I mentioned >> in my email [1], we'd need at least a day for consider exception and assess >> related risks. Filing it couple of hours before FF doesn't give a chance to >> do it. >> >> Any other opinions? >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/080895.html >> >> On Wed, Dec 2, 2015 at 9:52 AM Artem Silenkov >> wrote: >> >>> Hello! >>> >>> We have got >>> - erlang=18.1 https://review.fuel-infra.org/#/c/12896/ >>> - rabbitmq-server=3.5.6 https://review.fuel-infra.org/#/c/12901/ >>> packaged for ubuntu trusty in corresponding requests. >>> >>> Those requests are not merged yet but probably would today evening. >>> We need some time to backport it for centos7 in order to keep versions >>> synced. >>> >>> It is not rocket science to package it for centos7 and it could take not >>> more then one working day. >>> This work could be done as soon as ubuntu packages are landed. >>> >>> Regards, >>> Artem Silenkov >>> --- >>> MOS~Packaging >>> 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 >>> >> -- >> Mike Scherbakov >> #mihgen >> >> __ >> 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 >> >> > > > -- > Thanks, > Andrey Sledzinskiy > QA Engineer, > Mirantis, Kharkiv > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][FFE] Disabling HA for RPC queues in RabbitMQ
m that change. The change itself >>> is a >>> >> very small patch [3]. The only thing which I want to do before >>> proposing to >>> >> merge this change is to conduct destructive tests against it in order >>> to >>> >> make sure that we do not have a regression here. That should take just >>> >> several days, so if there will be no other objections, we will be >>> able to >>> >> merge the change in a week or two timeframe. >>> >> >>> >> Thanks, >>> >> >>> >> Dmitry >>> >> >>> >> [1] https://review.openstack.org/247517 >>> >> [2] >>> >> >>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081006.html >>> >> [3] https://review.openstack.org/249180 >>> >> >>> >> >>> __ >>> >> OpenStack Development Mailing List (not for usage questions) >>> >> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> >>> -- >>> With best regards, Peter Lemenkov. >>> >>> >>> __ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://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://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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Feature Freeze Exception Request: Task Based Deployment in Astute
separated services plugins* Task-based approach allows one to deploy things with separate services in much more flexible ways. E.g one will not have to introduce 2 roles in the plugin for controller to detach keystone services, e.g. pre-keystone-controller-tasks and post-keystone-controller-tasks. All he will need is to introduce "skipped" keystone task for controllers so that keystone is deployed only on the node with keystone role. ** Merge plan* Merge Astute changes - ETA Dec 4rd Merge Nailgun changes - ETA Dec 4rd Prepare Fuel Library changes - ETA Dec 3rd Test this feature on Scale Lab and against swarm - ETA SCF Make decision whether to enable task-based deployment engine by default - SCF ** Summary* This feature brings a lot of benefits for everyone. Its current implementation introduces 0 chances for regressions as it will be disabled by default and it will require specific actions for a user to start using this feature. In meanwhile we will test this feature at Scale Lab and against swarm and custom tests. And by SCF we may decide whether to switch to it based on the reported results. If it happens before SCF, we will be able to significantly ramp up our development and bugfixing velocity. -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Feature Freeze is soon
Mike I think, it is rather good idea. I guess we can have a couple of requests still - although everyone is shy, we might get a little storm of FFE's. BTW, I will file at least one. On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov wrote: > Hi Fuelers, > we are couple of days away from FF [1]. I have not noticed any request for > feature freeze exception, so I assume that we pretty much decided what is > going into 8.0 and what is not. > > If there are items which we'd like to ask exception for, I'd like us to > have this requested now - so that we all can spend some time on analysis of > what is done and what is left, and on risks assessment. I'd suggest to not > consider any exception requests on the day of FF, as it doesn't leave us > time to spend on it. > > To make a formal checkpoint of what is in and what is out, I suggest to > get together on FF day, Wednesday, and go over all the items we have been > working on in 8.0. What do you think folks? For instance, in #fuel-dev IRC > at 8am PST (4pm UTC)? > > [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule > -- > Mike Scherbakov > #mihgen > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Getting rid of Docker containers on the Fuel master node
ed approach that we used before. >>> > >>> > As far as there is nothing new here, we just need to use our old >>> site.pp >>> > (with minimal modifications), it looks like it is possible to implement >>> > this during 8.0 release cycle. If there are no principal objections, >>> > please give me a chance to do this ASAP (during 8.0), I know it is a >>> > huge risk for the release, but still I think I can do this. >>> > >>> > >>> > >>> > >>> > Vladimir Kozhukalov >>> > >>> > >>> > >>> __ >>> > 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 >>> > >>> >>> >>> -- >>> Best regards, >>> Bogdan Dobrelya, >>> Irc #bogdando >>> >>> >>> __ >>> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Getting rid of Docker containers on the Fuel master node
Vladimir
Although I am a big fan of this idea, I think it is too risky to do this
during our latest iteration for 8.0 release. There is a lot of stuff that
relies on our containerised approach. For example, it is our Fuel CI
master-node tests which will require adjustments. There are pieces of
things related to infrastructure for update repositories delivery and so on
and so forth. I would assess the risk of this change to break things and
block everything as high. So far, I suggest that if we provide a clear
deadline when such changes can get into master branch. I think, that we
should have all the code including CI jobs in place by Nov 30. Remember -
if CI is broken, our feature freeze is also broken. So I would suggest to
have a couple of days in advance before feature freeze to revert things.
On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya
wrote:
> On 19.11.2015 15:59, Vladimir Kozhukalov wrote:
> > Dear colleagues,
> >
> > As might remember, we introduced Docker containers on the master node a
> > while ago when we implemented first version of Fuel upgrade feature. The
> > motivation behind was to make it possible to rollback upgrade process if
> > something goes wrong.
> >
> > Now we are at the point where we can not use our tarball based upgrade
> > approach any more and those patches that deprecate upgrade tarball has
> > been already merged. Although it is a matter of a separate discussion,
> > it seems that upgrade process rather should be based on kind of backup
> > and restore procedure. We can backup Fuel data on an external media,
> > then we can install new version of Fuel from scratch and then it is
> > assumed backed up Fuel data can be applied over this new Fuel instance.
>
> A side-by-side upgrade, correct? That should work as well.
>
> > The procedure itself is under active development, but it is clear that
> > rollback in this case would be nothing more than just restoring from the
> > previously backed up data.
> >
> > As for Docker containers, still there are potential advantages of using
> > them on the Fuel master node, but our current implementation of the
> > feature seems not mature enough to make us benefit from the
> > containerization.
> >
> > At the same time there are some disadvantages like
> >
> > * it is tricky to get logs and other information (for example, rpm
> > -qa) for a service like shotgun which is run inside one of
> containers.
> > * it is specific UX when you first need to run dockerctl shell
> > {container_name} and then you are able to debug something.
> > * when building IBP image we mount directory from the host file system
> > into mcollective container to make image build faster.
> > * there are config files and some other files which should be shared
> > among containers which introduces unnecessary complexity to the
> > whole system.
> > * our current delivery approach assumes we wrap into rpm/deb packages
> > every single piece of the Fuel system. Docker images are not an
> > exception. And as far as they depend on other rpm packages we forced
> > to build docker-images rpm package using kind of specific build
> > flow. Besides this package is quite big (300M).
> > * I'd like it to be possible to install Fuel not from ISO but from RPM
> > repo on any rpm based distribution. But it is double work to support
> > both Docker based and package based approach.
>
> There is another point, the containers long build time when installing
> the master node.
>
> >
> > Probably some of you can give other examples. Anyway, the idea is to get
> > rid of Docker containers on the master node and switch to plane package
> > based approach that we used before.
> >
> > As far as there is nothing new here, we just need to use our old site.pp
> > (with minimal modifications), it looks like it is possible to implement
> > this during 8.0 release cycle. If there are no principal objections,
> > please give me a chance to do this ASAP (during 8.0), I know it is a
> > huge risk for the release, but still I think I can do this.
> >
> >
> >
> >
> > Vladimir Kozhukalov
> >
> >
> >
> __
> > 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
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
Re: [openstack-dev] [Fuel] HA cluster disk monitoring, failover and recovery
Bogdan I think we should firstly check whether attribute deletion leads to node starting its services or not. From what I read in the official Pacemaker documentation, it should work out of the box without the need to restart the node. And by the way the quote above mentions 'use ONE of the following methods' meaning that we could actually use attribute deletion. The 2nd and the 3rd options do the same - they clear short-living node attribute. So we need to figure out why OCF script does not update the corresponding attribute by itself. On Tue, Nov 17, 2015 at 7:03 PM, Bogdan Dobrelya wrote: > On 17.11.2015 15:28, Kyrylo Galanov wrote: > > Hi Team, > > Hello > > > > > I have been testing fail-over after free disk space is less than 512 mb. > > (https://review.openstack.org/#/c/240951/) > > Affected node is stopped correctly and services migrate to a healthy > node. > > > > However, after free disk space is more than 512 mb again the node does > > not recover it's state to operating. Moreover, starting the resources > > manually would rather fail. In a nutshell, the pacemaker service / node > > should be restarted. Detailed information is available > > here: > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html > > > > How do we address this issue? > > According to the docs you provided, > " After a node's health status has turned to red, solve the issue that > led to the problem. Then clear the red status to make the node eligible > again for running resources. Log in to the cluster node and use one of > the following methods: > > Execute the following command: > > crm node status-attr NODE delete #health_disk > > Restart OpenAIS on that node. > > Reboot the node. > > The node will be returned to service and can run resources again. " > > So this looks like an expected behaviour! > > What else could be done: > - We should check if we have this nuance documented, and submit a bug to > fuel-docs team, if not yet there. > - Submitting a bug and inspecting logs would be nice to do as well. > I believe some optimizations may be done, bearing in mind this pacemaker > cluster-recheck-interval and failure-timeout story [0]. > > [0] > http://blog.kennyrasschaert.be/blog/2013/12/18/pacemaker-high-failability/ > > > > > > > Best regards, > > Kyrylo > > > > > > > __ > > 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 > > > > > -- > Best regards, > Bogdan Dobrelya, > Irc #bogdando > > ______ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] HA cluster disk monitoring, failover and recovery
Folks Is not it possible for an OCF script to clear this attribute after a sufficient period of successful monitoring of node health? It could be a better approach in this case then restarting the node. On Tue, Nov 17, 2015 at 5:41 PM, Alex Schultz wrote: > Hey Kyrylo, > > > On Tue, Nov 17, 2015 at 8:28 AM, Kyrylo Galanov > wrote: > > Hi Team, > > > > I have been testing fail-over after free disk space is less than 512 mb. > > (https://review.openstack.org/#/c/240951/) > > Affected node is stopped correctly and services migrate to a healthy > node. > > > > However, after free disk space is more than 512 mb again the node does > not > > recover it's state to operating. Moreover, starting the resources > manually > > would rather fail. In a nutshell, the pacemaker service / node should be > > restarted. Detailed information is available here: > > > https://www.suse.com/documentation/sle_ha/book_sleha/data/sec_ha_configuration_basics_monitor_health.html > > > > How do we address this issue? > > > > So the original change for this was > https://review.openstack.org/#/c/226062/. As indicated by the commit > message, the only way pacemaker will recover is that the operator must > run a pacemaker command to clear the disk alert. > > crm node status-attr delete "#health_disk" > > Once the operator has cleared up the diskspace issue and run the above > command, pacemaker will rejoin the cluster and start services again. > The documentation bug for this is > https://bugs.launchpad.net/fuel/+bug/1500422. > > Thanks, > -Alex > > > > > Best regards, > > Kyrylo > > > > > __ > > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [Openstack-operators] Mirantis Fuel Multi-Region
Hi Folks Let me comment on a couple of things. Multiregion support is possible from deployment side. You need to pass a region parameter to corresponding nodes being deployed. It is a part of detached services feature which is delivered through plugins: " http://specs.fuel-infra.org/fuel-specs-master/specs/7.0/separate-services.html " Please look into this change: https://review.openstack.org/#/c/191244/ It should allow you to set Region name per-node. You will need just to download nodes settings and add a corresponding parameter 'region' into deployment yaml files. This will lead for controllers (or corresponding nodes roles whether you choos to use separated controller services) to create endpoints with corresponding region name. Should you face any issues, please create a bug at Launchpad or contact us within openstack-dev mailing list with [Fuel] tag in the message or approach us at #fuel-dev IRC channel. And another comment regarding multirack installation. In 8.0 we are planning to enable multiple rack configuration MVP to allow users to be able to deploy across multiple L2 segments for admin network. Please refer to https://blueprints.launchpad.net/fuel/+spec/l3-multiple-racks . On Tue, Nov 17, 2015 at 12:53 PM, Dina Belova wrote: > + openstack-dev mailing list to bring more Fuel audience. > > On Tue, Nov 17, 2015 at 12:44 PM, Federico Michele Facca < > federico.fa...@create-net.org> wrote: > >> Hi, >> as said, you need to do manual changes to your deployed nodes. >> then you will have to: >> - synch your galera cluster across the two dc >> - configure properly the load balancers >> - configure the memcached configuration >> - register the services of the second region on the new shared keystone >> >> Br, >> Federico >> >> PS: I think that you can change the region name in the YAML file using >> fuel cli ( >> https://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#cli-usage), >> but that won't help much honestly, being the trivial of the steps above. >> >> -- >> Future Internet is closer than you think! >> http://www.fiware.org >> >> Official Mirantis partner for OpenStack Training >> https://www.create-net.org/community/openstack-training >> >> -- >> Dr. Federico M. Facca >> >> CREATE-NET >> Via alla Cascata 56/D >> 38123 Povo Trento (Italy) >> >> P +39 0461 312471 >> M +39 334 6049758 >> E federico.fa...@create-net.org >> T @chicco785 >> W www.create-net.org >> >> On Tue, Nov 17, 2015 at 10:29 AM, Eren Türkay wrote: >> >>> On 17-11-2015 10:40, Federico Michele Facca wrote: >>> > Hi Eren, >>> >>> Hello Federico >>> >>> > afaik, with the new plugin architecture, in fuel 7/8 it should be easy >>> to >>> > create a plugin for achieve your goal. >>> > in case of manual job, depending on your cloud architecture there are >>> different >>> > options, the main ones are: >>> > - you keep a single keystone in a datacenter and register the new >>> region >>> > services in there. >>> >>> Yes, that's what I am aiming for. I need a single keystone and multiple >>> endpoints. However, as far as I understand, multi-dc isn't supported yet >>> on >>> Mirantis (nor the region name change). Do you know the actual/example >>> implementation for multi-dc with new plugin architecture? Here are my >>> findings >>> regarding to the issue. It seems deploying multi-site with fuel is >>> really hard >>> and not supported. >>> >>> https://answers.launchpad.net/fuel/+question/267127 >>> >>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076298.html >>> >>> >>> -- >>> Eren Türkay, System Administrator >>> https://skyatlas.com/ | +90 850 885 0357 >>> >>> Yildiz Teknik Universitesi Davutpasa Kampusu >>> Teknopark Bolgesi, D2 Blok No:107 >>> Esenler, Istanbul Pk.34220 >>> >>> >> >> ___ >> OpenStack-operators mailing list >> openstack-operat...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > > -- > > Best regards, > > Dina Belova > > Software Engineer > > Mirantis Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] API services available on public VIP
Adam I think, the answer is realtively simple - if user does not want to expose those APIs, he can easily configure his infra to filter this traffic. We just need to mention this in Ops Guide. On Fri, Nov 13, 2015 at 4:02 PM, Adam Heczko wrote: > Hello fuelers, > > today I'd like to raise a questions about Fuel deployment practice related > to Public (external) network. > Current approach is to expose by default over public IP openstack API > endpoints like nova, cinder, glance, neutron etc. These API services are > exposed through HAProxy with TLS support, so this approach seems to be > relatively secure. > OTOH industry practice is to don't expose over public IPs too much and > rather rely on user action / decision to expose API access to the public. > I'd like to ask for your opinions regarding this topic and approach taken > by Fuel. > > Thank you, > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering
Hi, Andrew Thanks for a quick turnaround. > The one I linked to in my original reply does: > https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster I do not have logs of testing of this script. Maybe, Bogdan has something to tell about results of testing this script. From the first glance it does not contain gigantic amount of workarounds we injected into our script to handle various situations when a node fails to join or tries to join a cluster that does not want to accept it (in this case you need to kick it from the cluster with forget_cluster_node and it starts an RPC multicall in rabbitmq internals to all cluster nodes, including the dead one, hanging forever). Actually, we started a long time ago with an approach similar to the one in the script above, but we faced a lot of issues in the case when a node tries to join a cluster after a dirty failover or a long time of being out of the cluster. I do not have all the logs of which particular cases we were handling while introducing that additional logic (it was an agile process, if you know what I mean :-) ), but we finally came up with this almost 2K lines code script. We are actively communicating with Pivotal folks on improving methods of monitoring RabbitMQ cluster nodes or even switching to RabbitMQ clusterer+autocluster plugins and writing new smaleer and fancier OCF script, but this is only in plans for further Fuel releases, I guess. > > > Changing the state isn’t ideal but there is precedent, the part that has me concerned is the error codes coming out of notify. > > Apart from producing some log messages, I can’t think how it would produce any recovery. > > > Unless you’re relying on the subsequent monitor operation to notice the error state. > > I guess that would work but you might be waiting a while for it to notice. > > Yes, we are relying on subsequent monitor operations. We also have several OCF check levels to catch a case when one node does not have rabbitmq application started properly (btw, there was a strange bug that we had to wait for several non-zero checks to fail to get the resource to restart http://bugs.clusterlabs.org/show_bug.cgi?id=5243) . Regarding this bug - it was very easy to reproduce - just add additional check to 'Dummy' resource with non-intersecting interval returning ERR_GENERIC code and the default check returning SUCCESS code. You will find that it is restarting only after 2 consequent failures of non-zero level check. On Thu, Nov 12, 2015 at 10:58 PM, Andrew Beekhof wrote: > > > On 12 Nov 2015, at 10:44 PM, Vladimir Kuklin > wrote: > > > > Hi, Andrew > > > > >Ah good, I understood it correctly then :) > > > I would be interested in your opinion of how the other agent does the > bootstrapping (ie. without notifications or master/slave). > > >That makes sense, the part I’m struggling with is that it sounds like > the other agent shouldn’t work at all. > > > Yet we’ve used it extensively and not experienced these kinds of hangs. > > Regarding other scripts - I am not aware of any other scripts that > actually handle cloned rabbitmq server. I may be mistaking, of course. So > if you are aware if these scripts succeed in creating rabbitmq cluster > which actually survives 1-node or all-node failure scenarios and > reassembles the cluster automatically - please, let us know. > > The one I linked to in my original reply does: > > > https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster > > > > > > Changing the state isn’t ideal but there is precedent, the part that > has me concerned is the error codes coming out of notify. > > > Apart from producing some log messages, I can’t think how it would > produce any recovery. > > > > > Unless you’re relying on the subsequent monitor operation to notice > the error state. > > > I guess that would work but you might be waiting a while for it to > notice. > > > > Yes, we are relying on subsequent monitor operations. We also have > several OCF check levels to catch a case when one node does not have > rabbitmq application started properly (btw, there was a strange bug that we > had to wait for several non-zero checks to fail to get the resource to > restart http://bugs.clusterlabs.org/show_bug.cgi?id=5243) . > > It appears I misunderstood your bug the first time around :-( > Do you still have logs of this occuring? > > > I now remember, why we did notify errors - for error logging, I guess. > > > > > > On Thu, Nov 12, 2015 at 1:30 AM, Andrew Beekhof > wrote: > > > > > On 11 Nov 2015, at 11:35 PM, Vladimir Kuklin > wrote: > > > > > > Hi, Andrew > > > > > > Let me answer
Re: [openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering
Hi, Andrew >Ah good, I understood it correctly then :) > I would be interested in your opinion of how the other agent does the bootstrapping (ie. without notifications or master/slave). >That makes sense, the part I’m struggling with is that it sounds like the other agent shouldn’t work at all. > Yet we’ve used it extensively and not experienced these kinds of hangs. Regarding other scripts - I am not aware of any other scripts that actually handle cloned rabbitmq server. I may be mistaking, of course. So if you are aware if these scripts succeed in creating rabbitmq cluster which actually survives 1-node or all-node failure scenarios and reassembles the cluster automatically - please, let us know. > Changing the state isn’t ideal but there is precedent, the part that has me concerned is the error codes coming out of notify. > Apart from producing some log messages, I can’t think how it would produce any recovery. > Unless you’re relying on the subsequent monitor operation to notice the error state. > I guess that would work but you might be waiting a while for it to notice. Yes, we are relying on subsequent monitor operations. We also have several OCF check levels to catch a case when one node does not have rabbitmq application started properly (btw, there was a strange bug that we had to wait for several non-zero checks to fail to get the resource to restart http://bugs.clusterlabs.org/show_bug.cgi?id=5243) . I now remember, why we did notify errors - for error logging, I guess. On Thu, Nov 12, 2015 at 1:30 AM, Andrew Beekhof wrote: > > > On 11 Nov 2015, at 11:35 PM, Vladimir Kuklin > wrote: > > > > Hi, Andrew > > > > Let me answer your questions. > > > > This agent is active/active which actually marks one of the node as > 'pseudo'-master which is used as a target for other nodes to join to. We > also check which node is a master and use it in monitor action to check > whether this node is clustered with this 'master' node. When we do cluster > bootstrap, we need to decide which node to mark as a master node. Then, > when it starts (actually, promotes), we can finally pick its name through > notification mechanism and ask other nodes to join this cluster. > > Ah good, I understood it correctly then :) > I would be interested in your opinion of how the other agent does the > bootstrapping (ie. without notifications or master/slave). > > > > > Regarding disconnect_node+forget_cluster_node this is quite simple - we > need to eject node from the cluster. Otherwise it is mentioned in the list > of cluster nodes and a lot of cluster actions, e.g. list_queues, will hang > forever as well as forget_cluster_node action. > > That makes sense, the part I’m struggling with is that it sounds like the > other agent shouldn’t work at all. > Yet we’ve used it extensively and not experienced these kinds of hangs. > > > > > We also handle this case whenever a node leaves the cluster. If you > remember, I wrote an email to Pacemaker ML regarding getting notifications > on node unjoin event '[openstack-dev] [Fuel][Pacemaker][HA] Notifying > clones of offline nodes’. > > Oh, I recall that now. > > > So we went another way and added a dbus daemon listener that does the > same when node lefts corosync cluster (we know that this is a little bit > racy, but disconnect+forget actions pair is idempotent). > > > > Regarding notification commands - we changed behaviour to the one that > fitter our use cases better and passed our destructive tests. It could be > Pacemaker-version dependent, so I agree we should consider changing this > behaviour. But so far it worked for us. > > Changing the state isn’t ideal but there is precedent, the part that has > me concerned is the error codes coming out of notify. > Apart from producing some log messages, I can’t think how it would produce > any recovery. > > Unless you’re relying on the subsequent monitor operation to notice the > error state. > I guess that would work but you might be waiting a while for it to notice. > > > > > On Wed, Nov 11, 2015 at 2:12 PM, Andrew Beekhof > wrote: > > > > > On 11 Nov 2015, at 6:26 PM, bdobre...@mirantis.com wrote: > > > > > > Thank you Andrew. > > > Answers below. > > > >>> > > > Sounds interesting, can you give any comment about how it differs to > the other[i] upstream agent? > > > Am I right that this one is effectively A/P and wont function without > some kind of shared storage? > > > Any particular reason you went down this path instead of full A/A? > > > > > > [i] > > > > https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rab
Re: [openstack-dev] [HA][RabbitMQ][messaging][Pacemaker][operators] Improved OCF resource agent for dynamic active-active mirrored clustering
.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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][fuel] How can I install Redhat-OSP using Fuel
Hi, Fei It seems you will need to do several things with Fuel - create a new release, associate your cluster with it when creating it and provide paths to corresponding repositories with packages. Also, you will need to create a base image for Image-based provisioning. I am not sure we have all the 100% of the code that supports it, but it should be possible to do so with some additional efforts. Let me specifically refer to Fuel Agent team who are working on Image-Based Provisioning and Nailgun folks who should help you with figuring out patterns for repositories URLs configuration. On Tue, Nov 10, 2015 at 5:15 AM, Fei LU wrote: > Greeting Fuel teams, > > > My company is working on the installation of virtualization > infrastructure, and we have noticed Fuel is a great tool, much better than > our own installer. The question is that Mirantis is currently supporting > OpenStack on CentOS and Ubuntu, while my company is using Redhat-OSP. > > I have read all the Fuel documents, including fuel dev doc, but I haven't > found the solution how can I add my own release into Fuel. Or maybe I'm > missing something. > > So, would you guys please give some guide or hints? > > Appreciating any help. > Kane > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead
Matthew Thanks for your feedback. Could you please elaborate more on the statistics of such tech-debt eliminations? My perception is that such bugs do not ever get fixed actually jeopardizing our efforts on bugfixing and actually making our statistics manupilative. So far my suggestion is the following - if you can, please do not introduce workarounds. If you have - introduce a TODO/FIXME comment for it in the code and create a tech-debt bug. If you see something of that kind that is already there and does not have such a comment - add this TODO/FIXME and create a tech-debt bug. So this is a best effort initiative, but I would encourage core reviewers to be stricter with such workarounds and hacks - please, do not get them pass through your hands unless there is a really good reason to merge this code with these hacks right now. On Wed, Nov 11, 2015 at 1:43 PM, Matthew Mosesohn wrote: > Vladimir, > > Bugfixes and minor refactoring often belong in separate commits. Combining > "extending foo to enable bar in XYZ" with "ensuring logs from service abc > are sent via syslog" often makes little sense to code reviewers. In this > case it is a feature enhancement + a bugfix. > > Looking at it from one perspective, if the bugfix is made poorly without a > feature commit, then it looks like the scenario you described. However, it > has the benefit that it can be cleanly backported. If we simply reverse the > order of the commits (untangling the workaround), we get the same result, > but get flamed. > > Sometimes both approaches are necessary. I agree that not growing tech > debt is important, but perceptions really depend on trends over 3+ weeks. > It's possible that such tech debt bugs are created and solved within 2-3 > days of the workaround. I know that's the exception, but I think we should > be most concerned about what happens when we carry tech debt across entire > Fuel releases. > On Nov 11, 2015 10:28 AM, "Aleksandr Didenko" > wrote: > >> +1 from me >> >> On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin < >> sbogat...@mirantis.com> wrote: >> >>> I think that it is excellent thought. >>> +1 >>> >>> On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin >>> wrote: >>> >>>> Folks >>>> >>>> I wanted to raise awareness about one of the things I captured while >>>> doing reviews recently - we are sacrificing quality to bugfixing and >>>> feature development velocity, essentially moving from one heap to another - >>>> from bugs/features to 'tech-debt' bugs. >>>> >>>> I understand that we all have deadlines and need to meet them. But, >>>> folks, let's create the following policy: >>>> >>>> 1) do not introduce hacks/workarounds/kludges if it is possible. >>>> 2) while fixing things if you have a hack/workaround/kludge that you >>>> need to work with - think of removing it instead of enhancing and extending >>>> it. If it is possible - fix it. Do not let our technical debt grow. >>>> 3) if there is no way to avoid kludge addition/enhancing, if there is >>>> no way to remove it - please, add a 'TODO/FIXME' line above it, so that we >>>> can collect them in the future and fix them gradually. >>>> >>>> I suggest to add this requirement into code-review policy. >>>> >>>> What do you think about this? >>>> >>>> -- >>>> Yours Faithfully, >>>> Vladimir Kuklin, >>>> Fuel Library Tech Lead, >>>> Mirantis, Inc. >>>> +7 (495) 640-49-04 >>>> +7 (926) 702-39-68 >>>> Skype kuklinvv >>>> 35bk3, Vorontsovskaya Str. >>>> Moscow, Russia, >>>> www.mirantis.com <http://www.mirantis.ru/> >>>> www.mirantis.ru >>>> vkuk...@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/mai
Re: [openstack-dev] [fuel] Using upstream packages & modules
Alex Thanks for your very detailed answer - it clarified things a bit. So, if you would allow me to rephrase it - you are actually conducting a research on what is the actual gap between our downstream/fork and upstream UCA/puppet-openstack. This seems to be a very promising initiative. Are you going to come up with some external-user readable report soon? Also, regarding multiple distros support. I think, we need to come up with an approach of making 'release manager' piece of Nailgun data driven and just allow a user to run any distribution he or she wants. Just register a set of repos with packages and run it. Actually, we already have it - we need to make base-image generation for RPM more flexible and any RPM/DEB based distro should work ok with it. The remaining piece is to actually support distro-specific things, e.g. CentOS/RHEL networking configuration, e.g. l23 network stored config puppet providers. But this is a distro-supporter/community burden. On Tue, Nov 10, 2015 at 6:25 PM, Alex Schultz wrote: > Hey Vladimir, > > On Tue, Nov 10, 2015 at 5:56 AM, Vladimir Kuklin > wrote: > > Alex > > > > That's great to hear that. But be aware - making all of the components > work > > exactly the way they work within MOS is actually identical to upstreaming > > MOS. We are using some components of different versions to satisfy many > > requirements for our Reference Architecutre implementation. It will not > be > > so easy to base them upon existing 3rd party distributions. For example, > > `read timeout` for SQL requests is crucial for our HA as it handles cases > > when an SQL node dies while serving the request. And you will find > myriads > > of them. And as we do not control things in upstream, we will always have > > some downstream divergence. > > > > Yes, I'm aware that it'll be an effort to make it work identically to > MOS. Currently that's not my goal. My goal is to get it working at > all and be able to document the deficiencies when using upstream > packages/modules vs MOS provided ones. Once we have documented these > differences we will be able to make decisions as to what efforts > should be made if we choose to address the differences. The read > timeout thing seems to be an issue with what mysql python driver is > used so that could easily be configurable based on a packages or a > configuration option. > > > I guess, the optimal solution is to figure out the actual divergence > between > > upstream and downstream and try to push things upstream as hard as we > can, > > while retaining overrides for some packages and manifests on top of > upstream > > versions. Do not get me wrong, but it seems there is exactly 0 (zero) > ways > > you can get Fuel working with upstream packages unless they support > exactly > > the same feature set and fix the same bugs in various components that > Fuel > > expect them to support or fix. By 'working' I mean passing the same set > of > > at least smoke and destructive tests, let alone passing scale tests. > > > > So I think this is where we are currently backwards in the way we're > doings. As we hope to push Fuel as a community project, we need to be > more open to supporting the distributions versions of these packages > as being supported. If we want to continue with specific versions of > things we need to be able to modularize them and apply them to a > downstream version of Fuel that we can promote with the MOS package > set. I agree that right now it's highly unlikely that one would be > able to use Fuel without any MOS packages. Because I don't think it's > possible right now, what I'm attempting to do is be able to deploy an > alternate OpenStack package set but not all of the other pieces as > they relate to our reference architecture. That seems to be a more > achievable goal right now and allows us to document the gaps where > Fuel/MOS are a head (or behind depending on your views) with upstream. > > > Simon > > > > AFAIK, this patch is really simple and can be easily applied to any > version > > of HAProxy. So it is not too hard handle it while it provides sufficient > > benefits to our deployment engineers. If you have any better solution, > > please feel free to share the code with us. > > > > Unfortunately the haproxy fork that we're currently running with also > includes our forked version of the puppet haproxy module. I'm not sure > the includes configs patch is really worth carrying the additional > work/forks but I think that is a conversation for another day. > Personally I think it would better if fuel-library supported the > currently a
Re: [openstack-dev] [Fuel] Master node upgrade
Evgeniy I am not sure you addressed me, but, anyway, - yes, we will have a situation with old containers on new host node. This will be identical to old host node from database migration point of view. On Tue, Nov 10, 2015 at 7:38 PM, Evgeniy L wrote: > Hi Vladimir, > > Just to make sure that we are on the same page. We'll have to use upgrade > script anyway, since you will need to run database migration and register > new releases. > > Thanks, > > On Monday, 9 November 2015, Vladimir Kozhukalov > wrote: > >> Looks like most people thing that building backup/re-install approach is >> more viable. So, we certainly need to invent completely new upgrade from >> and thus my suggestion is disable building/testing upgrade tarball right >> now, because anyway it makes no sense. >> >> >> Vladimir Kozhukalov >> >> On Fri, Nov 6, 2015 at 8:21 PM, Vladimir Kuklin >> wrote: >> >>> Just my 2 cents here - let's do docker backup and roll it up onto brand >>> new Fuel 8 node. >>> >>> On Fri, Nov 6, 2015 at 7:54 PM, Oleg Gelbukh >>> wrote: >>> >>>> Matt, >>>> >>>> You are talking about this part of Operations guide [1], or you mean >>>> something else? >>>> >>>> If yes, then we still need to extract data from backup containers. I'd >>>> prefer backup of DB in simple plain text file, since our DBs are not that >>>> big. >>>> >>>> [1] >>>> https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master >>>> >>>> -- >>>> Best regards, >>>> Oleg Gelbukh >>>> >>>> On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn < >>>> mmoses...@mirantis.com> wrote: >>>> >>>>> Oleg, >>>>> >>>>> All the volatile information, including a DB dump, are contained in >>>>> the small Fuel Master backup. There should be no information lost unless >>>>> there was manual customization done inside the containers (such as puppet >>>>> manifest changes). There shouldn't be a need to back up the entire >>>>> containers. >>>>> >>>>> The information we would lose would include the IP configuration >>>>> interfaces besides the one used for the Fuel PXE network and any custom >>>>> configuration done on the Fuel Master. >>>>> >>>>> I want #1 to work smoothly, but #2 should also be a safe route. >>>>> >>>>> On Fri, Nov 6, 2015 at 5:39 PM, Oleg Gelbukh >>>>> wrote: >>>>> >>>>>> Evgeniy, >>>>>> >>>>>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L wrote: >>>>>> >>>>>>> Also we should decide when to run containers >>>>>>> upgrade + host upgrade? Before or after new CentOS is installed? >>>>>>> Probably >>>>>>> it should be done before we run backup, in order to get the latest >>>>>>> scripts for >>>>>>> backup/restore actions. >>>>>>> >>>>>> >>>>>> We're working to determine if we need to backup/upgrade containers at >>>>>> all. My expectation is that we should be OK with just backup of DB, IP >>>>>> addresses settings from astute.yaml for the master node, and credentials >>>>>> from configuration files for the services. >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Oleg Gelbukh >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov < >>>>>>> vkozhuka...@mirantis.com> wrote: >>>>>>> >>>>>>>> Dear colleagues, >>>>>>>> >>>>>>>> At the moment I'm working on deprecating Fuel upgrade tarball. >>>>>>>> Currently, it includes the following: >>>>>>>> >>>>>>>> * RPM repository (upstream + mos) >>>>>>>> * DEB repository (mos) >>>>>>>> * openstack.yaml >>>>>>>> * version.yaml >>>>>>>> * upgrade script itself (+ virtualenv) >>>>>>&g
[openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead
Folks I wanted to raise awareness about one of the things I captured while doing reviews recently - we are sacrificing quality to bugfixing and feature development velocity, essentially moving from one heap to another - from bugs/features to 'tech-debt' bugs. I understand that we all have deadlines and need to meet them. But, folks, let's create the following policy: 1) do not introduce hacks/workarounds/kludges if it is possible. 2) while fixing things if you have a hack/workaround/kludge that you need to work with - think of removing it instead of enhancing and extending it. If it is possible - fix it. Do not let our technical debt grow. 3) if there is no way to avoid kludge addition/enhancing, if there is no way to remove it - please, add a 'TODO/FIXME' line above it, so that we can collect them in the future and fix them gradually. I suggest to add this requirement into code-review policy. What do you think about this? -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Using upstream packages & modules
difference is a >>> config or functionality issue. >>> >> >> I know at least for one difference between the MOS and Ubuntu versions: >> HAProxy from MOS has a patch to support the "include" configuration >> parameter. >> This is unrelated to your mail but I think this fork should die since it >> will never be accepted upstream and there are other ways to address the use >> case [0]. >> >> HTH, >> Simon >> >> [0] http://marc.info/?l=haproxy&m=130817444025140&w=2 >> >> >>> >>> The second issue that I have run across is that we are appending >>> read_timeout=60 to our mysql connection strings for our >>> configurations. This seems to be unsupported by the libraries and >>> OpenStack components provided by the UCA package set. I'm not sure >>> how the priority of python-pymsql vs python-mysqldb is resolved as I >>> had both packages installed but it continued to fail on read_timeout >>> being in the connection string. For now I've updated the fuel-library >>> code to remove this item from the connection strings and will be >>> circling back around to figure out the correct 'fix' for this issue. >>> >>> I'm hoping to be able to have a working ISO, plugin and a set of >>> instructions that can be used to deploy a basic cloud using Fuel by >>> the end of this week. >>> >>> Thanks, >>> -Alex >>> >>> [0] https://review.openstack.org/#/c/240325/ >>> [1] https://review.openstack.org/#/c/241615/ >>> [2] https://review.openstack.org/#/c/241741/ >>> >>> >>> ______ >>> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Master node upgrade
based >>>>> upgrade approach can be aligned with (1) (fuel-upgrade would use official >>>>> Centos upgrade script as a first step for upgrade), but it definitely can >>>>> not be aligned with (2), because it assumes reinstalling the master node >>>>> from scratch. >>>>> >>>>> Right now, I'm finishing the work around deprecating version.yaml and >>>>> my further steps would be to modify fuel-upgrade script so it does not >>>>> copy >>>>> RPM/DEB repos, but those steps make little sense taking into account >>>>> Centos >>>>> 7 feature. >>>>> >>>>> Colleagues, let's make a decision about how we are going to upgrade >>>>> the master node ASAP. Probably my tarball related work should be reduced >>>>> to >>>>> just throwing tarball away. >>>>> >>>>> >>>>> Vladimir Kozhukalov >>>>> >>>>> >>>>> __ >>>>> 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 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Change VIP address via API
ant to.
>>>>
>>>> > When the user runs GET request for the first time, all 'ipaddr'
>>>> > fields are equal to None.
>>>>
>>>> Should we return VIPs that aren't allocated, and if so - why? If they
>>>> would be just, you know, fetched from network roles - that's a bad
>>>> design. Each VIP should have an explicit entry in VIPs database table.
>>>>
>>>> > There is a question, what to do when the given address overlaps
>>>> > with the network from another environment? My opinion that those
>>>> > should pass with a warning message.
>>>>
>>>> The thing is that there's no way to *warn* users through API. You
>>>> could either reject or accept request. So all we can do is to
>>>> introduce some `force` flag, and if it's passed - ignore overlapping.
>>>>
>>>> I didn't get what do you mean by:
>>>>
>>>> > overlaps with the network of current environment which does not
>>>> > match the network role of the VIP?
>>>>
>>>> Could you please explain?
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> P.S: I see this API call somehow this way
>>>> http://xsnippet.org/361113/raw/
>>>>
>>>> On Mon, Nov 2, 2015 at 6:07 PM, Aleksey Kasatkin <
>>>> akasat...@mirantis.com> wrote:
>>>> > Hi folks,
>>>> >
>>>> > I'm working on the following story [1][2]:
>>>> > API must allow VIP to be manually set to ANY valid IP address. If the
>>>> IP on
>>>> > update API is a member of any network in this environment then the
>>>> address
>>>> > should be put in the assignments table so that it can not be used in
>>>> any
>>>> > other
>>>> > automatic assignment. (This allows the user to override if the
>>>> automatic
>>>> > allocation doesn't match their needs or in the case that they want to
>>>> use
>>>> > external LB).
>>>> >
>>>> > [1] https://bugs.launchpad.net/fuel/+bug/1482399
>>>> > [2] https://review.openstack.org/230943
>>>> >
>>>> > So, I have the following proposal for now:
>>>> > Add new url (e.g. /clusters//network_configuration/vips/
>>>> ), use
>>>> > GET
>>>> > to query current VIPs info, use PUT to change VIPs addresses (set them
>>>> > manually
>>>> > or request to allocate them automatically).
>>>> > Now VIPs have the following format in API requests data:
>>>> > vips: [
>>>> > {
>>>> > 'network_role': 'management',
>>>> > 'namespace': 'haproxy',
>>>> > 'ipaddr': '10.10.10.10',
>>>> > 'node_roles': ['controller']
>>>> > },...
>>>> > ]
>>>> > So, 'ipaddr' field can be set to any (almost any) user-defined value
>>>> or to
>>>> > None (null in YAML).
>>>> > When it is set to None, IP address will be allocated automatically.
>>>> When the
>>>> > user runs GET
>>>> > request for the first time, all 'ipaddr' fields are equal to None.
>>>> So, user
>>>> > can set some (or all)
>>>> > of them to desired values and run PUT. When the GET is run after PUT,
>>>> all
>>>> > addresses will be
>>>> > filled with values. User can reset some of them to None or change to
>>>> other
>>>> > IP when required.
>>>> > So, addresses will be re-allocated on the next PUT requests.
>>>> > If address given by user overlaps with some of the allocated IPs, PUT
>>>> > request will be rejected.
>>>> > There is a question, what to do when the given address overlaps with
>>>> the
>>>> > network from another
>>>> > environment? overlaps with the network of current environment which
>>>> does not
>>>> > match the
>>>> > network role of the VIP?
>>>> > My opinion that those should pass with a warning message.
>>>> >
>>>> > Please share your proposals and comments on this,
>>>> >
>>>> > Thanks,
>>>> >
>>>> >
>>>> > Aleksey Kasatkin
>>>> >
>>>> >
>>>> >
>>>> __
>>>> > 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
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> 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
>
>
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@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][Plugins][UX] Component registry
+1 to Evgeniy There should be no type of restrictions that cannot be overriden by user. On Mon, Nov 2, 2015 at 5:37 PM, Vitaly Kramskikh wrote: > Hi, > > I think having both compatibility and incompatibility lists is a good > idea. I think we need just to show a warning if users pick options which > are not in compatibility list and disable options which are in > incompatibility list. We also need to be able to provide a message in case > of incompatibility: the current implementation of the wizard supports > custom messages in the wizard config and they are quite useful. > > 2015-11-02 16:16 GMT+07:00 Evgeniy L : > >> Hi, >> >> The main reason why I think we should get all of the three states is we >> don't know exactly if those plugins (which developer didn't specify) are >> compatible or not, so we should not make any assumptions and prevent >> the user from enabling any plugins she/he wants. The best we can do here >> is to provide all of the information plugin developer knows, directly to >> the user, >> without us in the middle who make decisions based on incomplete data. >> >> So lets ask plugin developer to specify a set of components which he >> tested >> his plugin with. Plus a list of components which he tested with and he is >> sure >> that those are not going to working together. >> >> On UI we can show explicitly, that this combination is tested and >> approved to >> be working, another combination is not working for sure (plugin >> developers tested >> it and explicitly specified), and there will be a lot of combination >> which are going >> to work together without problems, but we should say the user, that the >> developer >> didn't test it and he should test and use it carefully. >> >> Thanks, >> >> On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych >> wrote: >> >>> Hi fuelers, >>> >>> Currently we are working on feature component registry [1] which should >>> help us to prevent not logical compositions of different components in >>> wizard tab during cluster(environment) creation. Now we have a mechanizm >>> of 'restrictions' which is not flexible for components provided by >>> plugins. In our current approach we have two states for components - >>> compatible/incompatible which are described in compatibility matrix >>> based on OpenStack components (For example: cinder-vmware storage only >>> compatible with vCetner hypervisor and should work when only KVM uses). >>> In this case we allow user to choose only that components we defently >>> know works well with each other. Another approach tell us to have 3 >>> states: compatible/incompatible/ and all other components about >>> compatibility with others we know nothing. In that case we should show >>> on wizard which components compatible, which not, and others which user >>> can enable on his own risk. So I need your opinions: should we allow for >>> user choose only that coponents which are tested and defently works or >>> prevent her/him from choosing which are defently not works and means >>> potentional risk of failing deployment when component about we know >>> nothing isn't work together. >>> >>> >>> >>> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry >>> >>> >>> __ >>> 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 >> >> > > > -- > Vitaly Kramskikh, > Fuel UI Tech Lead, > Mirantis, Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] State of the Fuel gates: liftoff!
Dmitry I apologize - I did not notice that the commit depends on other ones to Fuel Library which actually improve unit tests coverage. Disregard my previous message, please. On Fri, Oct 23, 2015 at 2:14 PM, Vladimir Kuklin wrote: > Dmitry > > These are awesome news. > > BTW, why should we enable unit tests for Fuel Library in voting mode right > now? It seems not all our modules have them passing. Can we wait a bit and > recheck it or we will get our master merges blocked? > > On Fri, Oct 23, 2015 at 3:25 AM, Dmitry Borodaenko < > dborodae...@mirantis.com> wrote: > >> Back in July, I proposed a plan to implement PTI in Fuel [0] during Fuel >> 8.0 development cycle, with the following mandatory stages: >> >> Stage 1: Create non-voting gate jobs for a single Fuel repo. >> Stage 2: Get these gate jobs to pass and make them voting. >> Stage 3: Create non-voting gate jobs for all Fuel repos. >> Stage 4: Cover all Fuel repos with voting unit test gate jobs. >> >> and bonus stages: >> >> Stage 5: Add functional tests for Fuel UI and Fuel Library to the gates. >> Stage 6: Run fuel-qa (multi-node deployment) tests on OpenStack Infra. >> >> [0] >> http://lists.openstack.org/pipermail/openstack-dev/2015-July/069908.html >> >> With the Kilo based Fuel 7.0 released in September, we were finally able >> to make some solid progress on that. Of 21 non-plugin Fuel repositories >> on review.openstack.org, 12 (including one of our two largest core >> components: fuel-web) already have voting gate jobs, 3 more (including >> the other largest core component: fuel-library) have passing gate jobs >> that can become voting once all outstanding fixes are merged, and 3 more >> are a work in progress. >> >> Voting: >> - fuel-agent >> - fuel-dev-tools >> - fuel-devops >> - fuel-mirror >> - fuel-octane >> - fuel-ostf (pep8; python gates are waiting for images with gevent) >> - fuel-plugins >> - fuel-specs >> - fuel-stats >> - fuel-upgrade >> - fuel-web >> - python-fuelclient >> >> Ready to vote: >> - fuel-library (needs https://review.openstack.org/238628) >> - fuel-menu >> - shotgun >> >> Work in progress: >> - fuel-astute (has unit tests, needs a gate job) >> - fuel-docs (docs gate job is failing) >> - network-checker (unit test gate job is failing) >> >> Not covered by unit tests: >> - fuel-main (scripts to make Fuel ISO) >> - fuel-nailgun-agent (588 lines of Ruby) >> - fuel-qa (Fuel deployment system tests) >> >> While it might be a bit too early to pull out a "Mission Accomplished" >> banner, it's safe to say that vast majority of Fuel code is now covered >> by gate checks running unit tests and syntax checks on OpenStack CI. >> >> Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir! >> Many thanks to the OpenStack Infra team for encouraging and supporting >> this effort! >> >> -- >> Dmitry Borodaenko >> >> __ >> 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 >> > > > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru > vkuk...@mirantis.com > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] State of the Fuel gates: liftoff!
Dmitry These are awesome news. BTW, why should we enable unit tests for Fuel Library in voting mode right now? It seems not all our modules have them passing. Can we wait a bit and recheck it or we will get our master merges blocked? On Fri, Oct 23, 2015 at 3:25 AM, Dmitry Borodaenko wrote: > Back in July, I proposed a plan to implement PTI in Fuel [0] during Fuel > 8.0 development cycle, with the following mandatory stages: > > Stage 1: Create non-voting gate jobs for a single Fuel repo. > Stage 2: Get these gate jobs to pass and make them voting. > Stage 3: Create non-voting gate jobs for all Fuel repos. > Stage 4: Cover all Fuel repos with voting unit test gate jobs. > > and bonus stages: > > Stage 5: Add functional tests for Fuel UI and Fuel Library to the gates. > Stage 6: Run fuel-qa (multi-node deployment) tests on OpenStack Infra. > > [0] > http://lists.openstack.org/pipermail/openstack-dev/2015-July/069908.html > > With the Kilo based Fuel 7.0 released in September, we were finally able > to make some solid progress on that. Of 21 non-plugin Fuel repositories > on review.openstack.org, 12 (including one of our two largest core > components: fuel-web) already have voting gate jobs, 3 more (including > the other largest core component: fuel-library) have passing gate jobs > that can become voting once all outstanding fixes are merged, and 3 more > are a work in progress. > > Voting: > - fuel-agent > - fuel-dev-tools > - fuel-devops > - fuel-mirror > - fuel-octane > - fuel-ostf (pep8; python gates are waiting for images with gevent) > - fuel-plugins > - fuel-specs > - fuel-stats > - fuel-upgrade > - fuel-web > - python-fuelclient > > Ready to vote: > - fuel-library (needs https://review.openstack.org/238628) > - fuel-menu > - shotgun > > Work in progress: > - fuel-astute (has unit tests, needs a gate job) > - fuel-docs (docs gate job is failing) > - network-checker (unit test gate job is failing) > > Not covered by unit tests: > - fuel-main (scripts to make Fuel ISO) > - fuel-nailgun-agent (588 lines of Ruby) > - fuel-qa (Fuel deployment system tests) > > While it might be a bit too early to pull out a "Mission Accomplished" > banner, it's safe to say that vast majority of Fuel code is now covered > by gate checks running unit tests and syntax checks on OpenStack CI. > > Nice work Alexey, Alex, Alexander, Sebastian, Vladimir, and Vladimir! > Many thanks to the OpenStack Infra team for encouraging and supporting > this effort! > > -- > Dmitry Borodaenko > > __ > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun
> > Each task can use some code to transform this output to the > representation that is actually needed for this particular task. Whenever a > task transforms this data it can access API and do version negotiation, for > example. Each time this transformation is performed this task can return > the data to some storage that will save this data for sake of control and > troubleshooting, such as, for example, user can always see which changes > are going to be applied and decide what to do next. > > Also, this means that the process of data calculation itself is very > 'lazy' or 'delayed', i. e. the data itself is calculated right at the > beginning of deployment transaction, so that it is not locked to some > particular details of deployment engine data processing and not prone to > issues like 'oh, I cannot get VIP because it has not been allocated yet by > Nailgun/oh, I cannot set it because it has already been set by Nailgun and > there is no way to alter it'. > >> To me, the two paragraphs above a contradictory. If the data calculations are lazy, I don't really see how one can introspect into changes that will be applied by a component at any given run. You just >> don't have this information, and you need to calculate it anyways to see which settings will be passed to a component. Might be I got your point wrong here. Please correct me if this is the case. Oleg, I actually meant that we do it in the following stages: 1) Change stuff in any amount of business logic engines you want, configuration databases, wikipedia, 4chan, etc. 2) Schedule a transaction of deployment 3) Make 'transformers/serializers' for each of the task collect all the data and store them before execution is started 4) Allow user to compare differences and decide whether he actually wants to apply this change 5) Commit the deployment - run particular tasks with particular set of settings which are staged and frozen (otherwise it will be impossible to debug this stuff) 6) If there is lack of data for some task, e.g. you need some entitties to be created during the deployment so that other task will use their output or side-effects to calculate things - this task should not be executed within this transaction. This means that the whole deployment should be splitted into 2 transactions. I can mention an old story here - when we were running puppet we needed to create some stuff for neutron knowing ID of the network that had been created by another resource 5 seconds earlier. But we could not do this because puppet 'freezes' the input provided with "facts" before this transaction runs. This is exactly the same usecase. So these 6 items actually mean: 1) Clear separation between layers of the system and their functional boundaries 2) Minimum of cross-dependencies between component data - e.g. deployment tasks should not ever produce anything that is then stored in the storage. Instead, you should have an API that provides you with data which is the result of deployment run. E.g. if you need to create a user in LDAP and you need this user's ID for some reason, your deployment task should create this user and, instead of returning this output to the storage, you just run another transaction and the task that requires this ID fetches it from LDAP. On Thu, Oct 22, 2015 at 1:25 PM, Dmitriy Shulyak wrote: > > Hi Oleg, > > I want to mention that we are using similar approach for deployment > engine, the difference is that we are working not with components, but with > deployment objects (it could be resources or tasks). > Right now all the data should be provided by user, but we are going to add > concept of managed resource, so that resource will be able to request data > from 3rd party service before execution, or by notification, if it is > supported. > I think this is similar to what Vladimir describes. > > As for the components - i see how it can be useful, for example > provisioning service will require data from networking service, but i think > nailgun can act as router for such cases. > This way we will keep components simple and purely functional, and nailgun > will perform a role of a client which knows how to build interaction > between components. > > So, as a summary i think this is 2 different problems. > > > > > > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.
Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun
Oleg Thank you for your feedback. IMO, the schema you are providing is very complex and would surely benefit from some examples. If I understand correctly your proposal, you are trying to do the things that we actually want to get rid of - tight coupling and schema control of data that is being used by components. There should be no cross-reference between components that do actual deployment. Instead, there should be a clear separation between layers of our deployment system. All the data that is provided to deployment (or provisioning/power_management/etc.) tasks should be accessible through API of the top-level components such as Network/Partitioning/IPAddressAllocation/ Manager or any other type of external configuration database such as ENC of external puppet master/LDAP/. Each task can use some code to transform this output to the representation that is actually needed for this particular task. Whenever a task transforms this data it can access API and do version negotiation, for example. Each time this transformation is performed this task can return the data to some storage that will save this data for sake of control and troubleshooting, such as, for example, user can always see which changes are going to be applied and decide what to do next. Also, this means that the process of data calculation itself is very 'lazy' or 'delayed', i. e. the data itself is calculated right at the beginning of deployment transaction, so that it is not locked to some particular details of deployment engine data processing and not prone to issues like 'oh, I cannot get VIP because it has not been allocated yet by Nailgun/oh, I cannot set it because it has already been set by Nailgun and there is no way to alter it'. On Thu, Oct 22, 2015 at 12:16 PM, Oleg Gelbukh wrote: > Hello, > > We discussed this proposal in our team and came up with the following > vision of a configuration provisioning system: > > - Installer is a system of multiple components: hardware inventory, > user interfaces, provisioning modules, deployment modules, checker modules, > volume manager, network manager, plugins, etc. > - Every component has its own data representation (we call them > 'views' as they provide an introspection in the configuration of the > system), which should include all the settings data the component should > have access to to perform its functions. > - Every component has 2 types of data in its view/representation: > authoritative data (which the component can modify) and external data > (which essentially is links to elements of another component's > view/representation). > - There is no 'universal' or 'general' representation of data which > serves a source of truth for all other views: every component is a source > of truth for its authoritative data. > - Views are defined as templates in some declarative language (YaML, > JSON, XML, %whatever%), think of jsonschema here. Authoritative settings of > the component have only type, external settings must also contain a link to > external view (might be just piece of code with properly referenced > elements of external view as parameters). > - View template shall be rendered in the data store during > 'registration' of the component in the system, i.e. data structure shall be > created to represent the format of the data with necessary links. > - Views can be saved to the data store and modified by component that > 'owns' the view's template, or via system's API. Changes to authoritative > settings in the view shall be propagated to all views that contain external > links to those settings. > - Both view template and views defined by it have versions. Template > version if defined by the version of it's owner component. View version > increases with every change made to it and can be used by the orchestrator > and component to determine if the async update of view was made by external > links. > > We will continue to flesh it out as a specification in Fuel specs > repository. I will greatly appreciate any feedback on this vision, > including comments, objections, concerns and questions. > > -- > Best regards, > Oleg Gelbukh > > On Tue, Oct 20, 2015 at 2:13 PM, Vladimir Kuklin > wrote: > >> Folks >> >> Can we please stop using etherpad and move to some more usable thing as >> Google Docs? Etherpad seems too unusable for such discussion especially >> with this coloured formatting. >> >> Mike >> >> I currently see no need in following marketing trend for noSQL here - we >> need to store a set of structured data. This store should be the one that >> can be easily consumed directly or with some API wrapper. That is all. We >>
Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun
aph, and then the last task in the graph runs corresponding
>> serializer - and there is a Python exception for whatever reason (user
>> input leads to bug in calculation). You could get it right a way, if you
>> tried to calculate it before overall deployment - but now you've been
>> waiting deployment to be almost done to catch it.
>>
>> Thank you,
>>
>> On Fri, Oct 16, 2015 at 9:22 AM Vladimir Kuklin
>> wrote:
>>
>>> Hey, Fuelers
>>>
>>> TL;DR This email is about how to make
>>>
>>> * Intro
>>> I want to bring up one of the important topics on how to make Fuel more
>>> flexible. Some of you know that we have been discussing means of doing this
>>> internally and now it is time to share these thoughts with all of you.
>>>
>>> As you could know per Evgeniy Li's message [0] we are looking forward
>>> splitting Fuel (specifically it's Fuel-Web) part into set of microservices
>>> each one serving their own purpose like networking configuration,
>>> partitioning, etc.
>>>
>>>
>>> And while we are working on this it seems that we need to get rid of
>>> so-called Nailgun serializers that are put too close to business logic
>>> engine, that have a lot of duplicating attributes; you are not able to
>>> easily modify or extend them; you are not able to change their behaviour
>>> even when Fuel Library is capable of doing so - everything is hardcoded in
>>> Nailgun code without clear separation between business logic and actual
>>> deployment workflow data generation and orchestration.
>>>
>>> Let me give you an example:
>>>
>>> * Case A. Replace Linux bridges with OVS bridges by default
>>>
>>> We all know that we removed OVS as much as possible from our reference
>>> architecture due to its buginess. Imagine a situation when someone
>>> magically fixed OVS and wants to use it as a provider for generic bonds and
>>> bridge. It actually means that he needs to set default provider in
>>> network_scheme for l23network puppet module to 'ovs' instead of 'lnx'.
>>> Imagine, he has put this magical OVS into a package and created a plugin.
>>> The problem here will be that he needs to override what network serializer
>>> is sending to the nodes.
>>>
>>> But the problem here is that he cannot do it without editing Nailgun
>>> code or override this serializer in any way.
>>>
>>> * Case B. Make Swift Partitions Known to Fuel Library
>>>
>>> Imagine, you altered the way you partition your disk in Nailgun. You
>>> created a special role for swift disks which should occupy the whole disk.
>>> In this case you should be able to get this info from api and feed it to
>>> swift deployment task. But it is not so easy - this stuff is still
>>> hardcoded in deployment serializers like {mp} field of nodes array of
>>> hashes.
>>>
>>> * Proposed solution
>>>
>>> In order to tackle this I propose to extract these so called serializers
>>> (see links [1] and [2]) and put them closer to library. You can see that
>>> half of the code is actually duplicated for deployment and provsioning
>>> serializers and there is actually no inheritance of common code betwen
>>> them. If you want to introduce new attribute and put it into astute.yaml,
>>> you will need to rewrite Nailgun code. This is not very
>>> deployment/sysop/sysadmin engineer-friendly. Essentially, the proposal is
>>> to introduce a library of such `serializers` (I would like to call them
>>> translators actually) which could leverage inheritance, polymorphism and
>>> incapsulation pretty much in OOP mode but with ability for deployment
>>> engineers to apply versioning to serializers and allow each particular task
>>> to work with different sources of data with different versions of API.
>>>
>>> What this actually means: each task has a step called 'translation'
>>> which fetches attributes from any arbitrary set of sources and converts
>>> them into the format that is consumable by the deployment stage of this
>>> task. From our current architectural point of view it will look like
>>> generation of a set of yaml files that will be merged by hiera so that each
>>> puppet task can leverage the power of hiera.
>>>
>>> This actually means that in scope of our modularization initiative each
>>> module should have an API which will be accessed by thos
Re: [openstack-dev] [Fuel] Testing before switching to upstream librarian
pstream >>>>> modules to ensure no bugs are regressed that relate to the particular >>>>> Puppet module being migrated. >>>>> >>>>> Secondly, what should our policy be? Revert the switch to upstream >>>>> module? Or just work on cherry-picking the appropriate fixes? >>>>> >>>>> Best Regards, >>>>> Matthew Mosesohn >>>>> >>>>> >>>>> __ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Thanks, Ivan Berezovskiy >>> MOS Puppet Team Lead >>> at Mirantis <https://www.mirantis.com/> >>> >>> slack: iberezovskiy >>> skype: bouhforever >>> phone: + 7-960-343-42-46 >>> >>> >>> >>> __ >>> 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 >>> >>> >> >> >> -- >> Regards, >> Sergey Kolekonov >> >> __ >> 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun
Hey, Fuelers
TL;DR This email is about how to make
* Intro
I want to bring up one of the important topics on how to make Fuel more
flexible. Some of you know that we have been discussing means of doing this
internally and now it is time to share these thoughts with all of you.
As you could know per Evgeniy Li's message [0] we are looking forward
splitting Fuel (specifically it's Fuel-Web) part into set of microservices
each one serving their own purpose like networking configuration,
partitioning, etc.
And while we are working on this it seems that we need to get rid of
so-called Nailgun serializers that are put too close to business logic
engine, that have a lot of duplicating attributes; you are not able to
easily modify or extend them; you are not able to change their behaviour
even when Fuel Library is capable of doing so - everything is hardcoded in
Nailgun code without clear separation between business logic and actual
deployment workflow data generation and orchestration.
Let me give you an example:
* Case A. Replace Linux bridges with OVS bridges by default
We all know that we removed OVS as much as possible from our reference
architecture due to its buginess. Imagine a situation when someone
magically fixed OVS and wants to use it as a provider for generic bonds and
bridge. It actually means that he needs to set default provider in
network_scheme for l23network puppet module to 'ovs' instead of 'lnx'.
Imagine, he has put this magical OVS into a package and created a plugin.
The problem here will be that he needs to override what network serializer
is sending to the nodes.
But the problem here is that he cannot do it without editing Nailgun code
or override this serializer in any way.
* Case B. Make Swift Partitions Known to Fuel Library
Imagine, you altered the way you partition your disk in Nailgun. You
created a special role for swift disks which should occupy the whole disk.
In this case you should be able to get this info from api and feed it to
swift deployment task. But it is not so easy - this stuff is still
hardcoded in deployment serializers like {mp} field of nodes array of
hashes.
* Proposed solution
In order to tackle this I propose to extract these so called serializers
(see links [1] and [2]) and put them closer to library. You can see that
half of the code is actually duplicated for deployment and provsioning
serializers and there is actually no inheritance of common code betwen
them. If you want to introduce new attribute and put it into astute.yaml,
you will need to rewrite Nailgun code. This is not very
deployment/sysop/sysadmin engineer-friendly. Essentially, the proposal is
to introduce a library of such `serializers` (I would like to call them
translators actually) which could leverage inheritance, polymorphism and
incapsulation pretty much in OOP mode but with ability for deployment
engineers to apply versioning to serializers and allow each particular task
to work with different sources of data with different versions of API.
What this actually means: each task has a step called 'translation' which
fetches attributes from any arbitrary set of sources and converts them into
the format that is consumable by the deployment stage of this task. From
our current architectural point of view it will look like generation of a
set of yaml files that will be merged by hiera so that each puppet task can
leverage the power of hiera.
This actually means that in scope of our modularization initiative each
module should have an API which will be accessed by those tasks in runtime
right before the tasks are executed. This also means that if a user changes
some of the values in the databases of those modules, rerun of such task
will lead to a different result of 'translation' and trigger some actions
like 'keystone_config ~> Service[keystone]' in puppet.
There is a tough discussion (etherpad here:[4]) on:
1) how to handle versioning/revert capabilities
2) where to store output produced by those 'translators'
3) which type of the storage to use
Please, feel free to provide your feedback on this approach and tell me
where this approach is going to be wrong.
[0] http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66563
[1]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py
[2]
https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/provisioning_serializers.py
[3] https://github.com/xenolog/l23network
[4] https://etherpad.openstack.org/p/data-processor-per-component
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Dev
Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling
Matt > You are right, it probably won't. At that point you are using puppet to work around some fundamental issues in your OpenStack deployment. Actually, as you know, with Fuel we are shipping our code to people who have their own infrastructure. We do not have any control over that infrastructure and any information about it. So we should expect the worst - that sometimes such issues will happen and we need to take care of them in the best possible way, e.g. someone tripped the wire and then put it back into the switch. And it seems that we can do it right in puppet code instead of making user wait for puppet rerun. > Another one that is a deployment architecture problem. We solved this by configuring the load balancer to direct keystone traffic to a single db node, now we solve it with Fernet tokens. If you have this > specific issue above it's going to manifest in all kinds of strange ways and can even happen to control services like neutron/nova etc as well. Which means even if we get puppet to pass with a bunch of > retries, OpenStack is not healthy and the users will not be happy about it. Again, what you described is for the case when the system was in some undesirable state like reading from incorrect database and then got into persistent working state. And you solve it by making load balancer aware of which backend to send request to. But I am talking about sporadic failures which from the statistical point of view look negligible and should not be handled by load balancer. Imagine the situation when load balancer is ok with that backend and this backend faces intermittent operational issue like getting garbled response or having some bug in the code. This is a sporadic failure which will not be caught by load balancer because if you make it so sensitive to such issues it will behave poorly. So, I think, the best option here is to handle such issues on application level. On Thu, Oct 15, 2015 at 4:37 PM, Matt Fischer wrote: > > > On Thu, Oct 15, 2015 at 4:10 AM, Vladimir Kuklin > wrote: > >> Gilles, >> >> 5xx errors like 503 and 502/504 could always be intermittent operational >> issues. E.g. when you access your keystone backends through some proxy and >> there is a connectivity issue between the proxy and backends which >> disappears in 10 seconds, you do not need to rerun the puppet completely - >> just retry the request. >> >> Regarding "REST interfaces for all Openstack API" - this is very close >> to another topic that I raised ([0]) - using native Ruby application and >> handle the exceptions. Otherwise whenever we have an OpenStack client >> (generic or neutron/glance/etc. one) sending us a message like '[111] >> Connection refused' this message is very much determined by the framework >> that OpenStack is using within this release for clients. It could be >> `requests` or any other type of framework which sends different text >> message depending on its version. So it is very bothersome to write a bunch >> of 'if' clauses or gigantic regexps instead of handling simple Ruby >> exception. So I agree with you here - we need to work with the API >> directly. And, by the way, if you also support switching to native Ruby >> OpenStack API client, please feel free to support movement towards it in >> the thread [0] >> >> Matt and Gilles, >> >> Regarding puppet-healthcheck - I do not think that puppet-healtcheck >> handles exactly what I am mentioning here - it is not running exactly at >> the same time as we run the request. >> >> E.g. 10 seconds ago everything was OK, then we had a temporary >> connectivity issue, then everything is ok again in 10 seconds. Could you >> please describe how puppet-healthcheck can help us solve this problem? >> > > > You are right, it probably won't. At that point you are using puppet to > work around some fundamental issues in your OpenStack deployment. > > >> >> Or another example - there was an issue with keystone accessing token >> database when you have several keystone instances running, or there was >> some desync between these instances, e.g. you fetched the token at keystone >> #1 and then you verify it again keystone #2. Keystone #2 had some issues >> verifying it not due to the fact that token was bad, but due to the fact >> that that keystone #2 had some issues. We would get 401 error and instead >> of trying to rerun the puppet we would need just to handle this issue >> locally by retrying the request. >> >> [0] http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66423 >> > > Another one that is a deployment architecture problem. We solved this by > configuring the load balanc
Re: [openstack-dev] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling
Gilles, 5xx errors like 503 and 502/504 could always be intermittent operational issues. E.g. when you access your keystone backends through some proxy and there is a connectivity issue between the proxy and backends which disappears in 10 seconds, you do not need to rerun the puppet completely - just retry the request. Regarding "REST interfaces for all Openstack API" - this is very close to another topic that I raised ([0]) - using native Ruby application and handle the exceptions. Otherwise whenever we have an OpenStack client (generic or neutron/glance/etc. one) sending us a message like '[111] Connection refused' this message is very much determined by the framework that OpenStack is using within this release for clients. It could be `requests` or any other type of framework which sends different text message depending on its version. So it is very bothersome to write a bunch of 'if' clauses or gigantic regexps instead of handling simple Ruby exception. So I agree with you here - we need to work with the API directly. And, by the way, if you also support switching to native Ruby OpenStack API client, please feel free to support movement towards it in the thread [0] Matt and Gilles, Regarding puppet-healthcheck - I do not think that puppet-healtcheck handles exactly what I am mentioning here - it is not running exactly at the same time as we run the request. E.g. 10 seconds ago everything was OK, then we had a temporary connectivity issue, then everything is ok again in 10 seconds. Could you please describe how puppet-healthcheck can help us solve this problem? Or another example - there was an issue with keystone accessing token database when you have several keystone instances running, or there was some desync between these instances, e.g. you fetched the token at keystone #1 and then you verify it again keystone #2. Keystone #2 had some issues verifying it not due to the fact that token was bad, but due to the fact that that keystone #2 had some issues. We would get 401 error and instead of trying to rerun the puppet we would need just to handle this issue locally by retrying the request. [0] http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66423 On Thu, Oct 15, 2015 at 12:23 PM, Gilles Dubreuil wrote: > > > On 15/10/15 12:42, Matt Fischer wrote: > > > > > > On Thu, Oct 8, 2015 at 5:38 AM, Vladimir Kuklin > <mailto:vkuk...@mirantis.com>> wrote: > > > > Hi, folks > > > > * Intro > > > > Per our discussion at Meeting #54 [0] I would like to propose the > > uniform approach of exception handling for all puppet-openstack > > providers accessing any types of OpenStack APIs. > > > > * Problem Description > > > > While working on Fuel during deployment of multi-node HA-aware > > environments we faced many intermittent operational issues, e.g.: > > > > 401/403 authentication failures when we were doing scaling of > > OpenStack controllers due to difference in hashing view between > > keystone instances > > 503/502/504 errors due to temporary connectivity issues > > The 5xx errors are not connectivity issues: > > 500 Internal Server Error > 501 Not Implemented > 502 Bad Gateway > 503 Service Unavailable > 504 Gateway Timeout > 505 HTTP Version Not Supported > > I believe nothing should be done to trap them. > > The connectivity issues are different matter (to be addressed as > mentioned by Matt) > > > non-idempotent operations like deletion or creation - e.g. if you > > are deleting an endpoint and someone is deleting on the other node > > and you get 404 - you should continue with success instead of > > failing. 409 Conflict error should also signal us to re-fetch > > resource parameters and then decide what to do with them. > > > > Obviously, it is not optimal to rerun puppet to correct such errors > > when we can just handle an exception properly. > > > > * Current State of Art > > > > There is some exception handling, but it does not cover all the > > aforementioned use cases. > > > > * Proposed solution > > > > Introduce a library of exception handling methods which should be > > the same for all puppet openstack providers as these exceptions seem > > to be generic. Then, for each of the providers we can introduce > > provider-specific libraries that will inherit from this one. > > > > Our mos-puppet team could add this into their backlog and could work > > on that in upstream or downstream and propose it upstream. > > > > What do you think on that, puppet folks? > > > > The real issue
[openstack-dev] [Fuel] Fuel Library Component Lead Nomination
Fuel Librarians I would like to nominate myself as a Candidate for Fuel Library Component Lead position Let me mention the list of main points I would like to work on. This list is going to essentially resemble my PTL candidacy item list but it will also differ from it significantly. * General Standards of Decision Making This assumes that each design decision on architecture must be applied according to the sufficient data and expert analysis performed by subject matter experts and cold and heartless machines that should run tests and collect metrics of existing and proposed solutions to figure out the best solution. Each decision on the new library or tool to choose must be accompanied by clear report showing that this change actually makes difference. I will start working on the unified toolchain and methodology on how to make decisions immediately. * HA Polishing This one has always been one of the strongest parts of Fuel and we are using our own unique and innovative ways of deploying HA architecture. Nevertheless, we still have many things to work on to make it perfect: 1) Fencing and power management facilities 2) Node health monitoring 3) RabbitMQ clusterer plugin * Reference Architecture Changes It seems pretty obvious that our reference architecture requires some simplification and polishing. We have several key-value storages, we are using several HTTP servers/proxies and so on. This makes us support lots of stuff instead of concentrating on a 'golden' set of tools and utilities and making them work perfectly. I want to spend significant time on figuring out possible solutions for redefining of our architecture based on aforementioned principles. * Quality and Deployment Velocity Although we are among the only projects who run very extensive set of tests including for each commit into Fuel Library - we can still work on many things for perfect QA and CI. These are: 1) deployment integration tests for all the components, e.g. run deployment for each deployment-related component like nailgun, nailgun-agent, fuel-agent, fuel-astute and others 2) significantly increase test coverage: e.g. cover each deployment task with noop test, increase unit test coverage for all the Fuel-only modules 3) work on the ways of automated generation of test plans for each particular feature and bugfix including regression, functional, scale, stress and other types of tests 4) work on the way of introducing more granular tests for fuel deployment components - we have an awesome framework to get faster feedback, written by fuel QA team, but we have not yet integrated it into our CI * Flexibility and Scalability We have a lot of work to do on orchestration and capabilities of our deployment engine. We need to introduce hierarchy for deployment attributes like for the whole cluster, for racks, for nodes and tasks themselves. We also need to work on our provisioning scalability parts such as moving towards iPXE + peer2peer base image distribution. * Documentation It seems we have lots of good tools like our devops toolkit, noop tests and other things. But this info is not available to external contributors and plugin developers. Even Fuel engineers do not know everything about how these tools work. I am going to setup several webinars and write a dozen of articles on how to develop and test Fuel Library. * Community And the last but not least - community collaboration. We are doing great job while gluing existing deployment libraries and testing their integration. Community folks like puppet-openstack are also doing great job. And, instead of duplicating it, I would like to merge with upstream code as much as possible thus freeing our resources onto the things we do the best along with sharing the stuff we do the best with community by testing results of their work against our reference architecture and installations. Additionally, it is worth to mention that I envision significant value in making Fuel able to install current OpenStack trunk code thus allowing us to set up Fuel CI for each piece of OpenStack and allowing OpenStack developers to test their code against multi-host HA-enabled reference architecture in an easy and automated way. Thank you all for your time and consideration! -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Changes in bugs workflow on Launchpad
Dima What I think is that we need to somehow group the bugs so that after they are initially triaged particular component developers can understand which bugs to get from the pool of unassigned bugs. Could you please show how you are going to tackle this? On Tue, Oct 13, 2015 at 11:24 PM, Mike Scherbakov wrote: > Dmitry, > I think that #1 is reasonable. > For #2, separate LP projects, I'd want to assess pros/cons before making a > decision. I see more cons at the moment. I've started adding it in the > etherpad, I'd appreciate if other folks would join and provide their input > there. > > Thank you, > > On Tue, Oct 13, 2015 at 11:34 AM Dmitry Pyzhov > wrote: > >> Guys, >> >> I propose several changes in bugs workflow on Launchpad. >> 1) Let's stop using component based team groups as assignees for bugs >> 2) Let's create separate Launchpad projects for qa, docs and infra teams >> >> It will affect everyone who tracks any list of bugs. So I want to be sure >> that everyone can ask question or raise concern. >> >> Why do we need this? We are growing community. In 7.0 release we >> addressed 2153 bugs. This number is almost unmanageable. We have a lot of >> tags (99 official and 219 other tags), a lot of Launchpad groups. We have >> several big teams with their own workflows. We have 1482 bugs in our >> current release. In order to understand if a bug in really a bug or some >> kind of support request one have to analyse its tags, assignee and teams of >> assignee. And there is a chance that the analysis will produce wrong result. >> >> I'm trying to make our bug management as clear as possible and produce as >> little extra everyday mouse clicking as possible. Here is list of required >> changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy >> >> Feel free to ask questions. >> __ >> 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 >> > -- > Mike Scherbakov > #mihgen > > ______ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [puppet][Fuel] Using Native Ruby Client for Openstack Providers
Matt Thanks for your input. So, I mentioned the following - Fuel guys can contribute into Ruby client for OpenStack as we are also interested in making it faster. That's why I asked for support in case we invest substantial effort (as we do not want to waste our time on things that will not land into upstream) and asked if the approach that I proposed is OK with you. On Tue, Oct 13, 2015 at 6:07 PM, Matt Fischer wrote: > From a technical point of view, not forking and using a native library > makes total sense. I think it would likely be faster and certainly cleaner > than parsing output. Unfortunately I don't think that we have the resources > to actively maintain the library. I think that's the main blocker for me. > > On Tue, Oct 13, 2015 at 7:13 AM, Vladimir Kuklin > wrote: > >> Puppetmaster and Fuelers, >> >> Last week I mentioned that I would like to bring the theme of using >> native ruby OpenStack client and use it within the providers. >> >> Emilien told me that I had already been late and the decision was made >> that puppet-openstack decided to not work with Aviator based on [0]. I went >> through this thread and did not find any unresolvable issues with using >> Aviator in comparison with potential benefits it could have brought up. >> >> What I saw actually was like that: >> >> * Pros >> >> 1) It is a native ruby client >> 2) We can import it in puppet and use all the power of Ruby >> 3) We will not need to have a lot of forks/execs for puppet >> 4) You are relying on negotiated and structured output provided by API >> (JSON) instead of introducing workarounds for client output like [1] >> >> * Cons >> >> 1) Aviator is not actively supported >> 2) Aviator does not track all the upstream OpenStack features while >> native OpenStack client does support them >> 3) Ruby community is not really interested in OpenStack (this one is >> arguable, I think) >> >> * Proposed solution >> >> While I completely understand all the cons against using Aviator right >> now, I see that Pros above are essential enough to change our mind and >> invest our own resources into creating really good OpenStack binding in >> Ruby. >> Some are saying that there is not so big involvement of Ruby into >> OpenStack. But we are actually working with Puppet/Ruby and are invloved >> into community. So why should not we own this by ourselves and lead by >> example here? >> >> I understand that many of you do already have a lot of things on their >> plate and cannot or would not want to support things like additional >> library when native OpenStack client is working reasonably well for you. >> But if I propose the following scheme to get support of native Ruby client >> for OpenStack: >> >> 1) we (community) have these resources (speaking of the company I am >> working for, we at Mirantis have a set of guys who could be very interested >> in working on Ruby client for OpenStack) >> 2) we gradually improve Aviator code base up to the level that it >> eliminates issues that are mentioned in 'Cons' section >> 3) we introduce additional set of providers and allow users and operators >> to pick whichever they want >> 4) we leave OpenStackClient default one >> >> Would you support it and allow such code to be merged into upstream >> puppet-openstack modules? >> >> >> [0] >> https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J >> [1] >> https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86 >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com <http://www.mirantis.ru/> >> www.mirantis.ru >> vkuk...@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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [puppet][Fuel] Using Native Ruby Client for Openstack Providers
Rich Thanks for your feedback - let me comment on a couple of things. First of all, I do not think we have complete support for any action in OpenStack client right now - we still need to rely on neutronclient, glanceclient, etc. Secondly, regarding Ruby power - this is about any good programming language, not about Ruby - I can simply mention better exception handling as you would not need to parse the output and generate your own exceptions - this makes it easier to support the whole set of providers. As I mentioned earlier, we do not have perfect exception handling for intermittent operational issues. Finally, I understand that you do not see metrics. Although, it seems to me absolutely obvious that fork/exec is going to be the problem here, that's OK, I will work on that and come up with quantitative analysis. On Tue, Oct 13, 2015 at 5:18 PM, Rich Megginson wrote: > On 10/13/2015 07:13 AM, Vladimir Kuklin wrote: > > Puppetmaster and Fuelers, > > Last week I mentioned that I would like to bring the theme of using native > ruby OpenStack client and use it within the providers. > > Emilien told me that I had already been late and the decision was made > that puppet-openstack decided to not work with Aviator based on [0]. I went > through this thread and did not find any unresolvable issues with using > Aviator in comparison with potential benefits it could have brought up. > > What I saw actually was like that: > > * Pros > > 1) It is a native ruby client > 2) We can import it in puppet and use all the power of Ruby > 3) We will not need to have a lot of forks/execs for puppet > > > I think 1), 2), and 3) go together - that is, the reason why 1) and 2) are > good is because of 3) - since aviator is native ruby, there is no need to > fork/exec. What other "power of Ruby" is there to be taken advantage of? > > As for fork/exec, it remains to be seen that fork/exec is causing a > performance problem. Note that you can also run the openstackclient in > "persistent" mode - that is, use it as a persistent pipe, which will read > commands from stdin and output to stdout, which should alleviate much if > not all of any performance problem caused by multiple fork/exec. We just > haven't investigated this route yet because it needs to be proven that > fork/exec causes performance problems. > > 4) You are relying on negotiated and structured output provided by API > (JSON) instead of introducing workarounds for client output like [1] > > > openstackclient can output JSON. > > > * Cons > > 1) Aviator is not actively supported > > > This is huge. > > 2) Aviator does not track all the upstream OpenStack features while native > OpenStack client does support them > > > This is also huge. > > 3) Ruby community is not really interested in OpenStack (this one is > arguable, I think) > > * Proposed solution > > While I completely understand all the cons against using Aviator right > now, I see that Pros above are essential enough to change our mind and > invest our own resources into creating really good OpenStack binding in > Ruby. > > > I'm still not convinced. > > Some are saying that there is not so big involvement of Ruby into > OpenStack. But we are actually working with Puppet/Ruby and are invloved > into community. So why should not we own this by ourselves and lead by > example here? > > > > > > I understand that many of you do already have a lot of things on their > plate and cannot or would not want to support things like additional > library when native OpenStack client is working reasonably well for you. > But if I propose the following scheme to get support of native Ruby client > for OpenStack: > > 1) we (community) have these resources (speaking of the company I am > working for, we at Mirantis have a set of guys who could be very interested > in working on Ruby client for OpenStack) > 2) we gradually improve Aviator code base up to the level that it > eliminates issues that are mentioned in 'Cons' section > 3) we introduce additional set of providers and allow users and operators > to pick whichever they want > 4) we leave OpenStackClient default one > > Would you support it and allow such code to be merged into upstream > puppet-openstack modules? > > > I would be in favor of such a plan if > https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20151013 > questions 0.4.1-0.4.7 could be answered in the affirmative. > > > > [0] > https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J > [1] > https://github.com/openst
[openstack-dev] [puppet][Fuel] Using Native Ruby Client for Openstack Providers
Puppetmaster and Fuelers, Last week I mentioned that I would like to bring the theme of using native ruby OpenStack client and use it within the providers. Emilien told me that I had already been late and the decision was made that puppet-openstack decided to not work with Aviator based on [0]. I went through this thread and did not find any unresolvable issues with using Aviator in comparison with potential benefits it could have brought up. What I saw actually was like that: * Pros 1) It is a native ruby client 2) We can import it in puppet and use all the power of Ruby 3) We will not need to have a lot of forks/execs for puppet 4) You are relying on negotiated and structured output provided by API (JSON) instead of introducing workarounds for client output like [1] * Cons 1) Aviator is not actively supported 2) Aviator does not track all the upstream OpenStack features while native OpenStack client does support them 3) Ruby community is not really interested in OpenStack (this one is arguable, I think) * Proposed solution While I completely understand all the cons against using Aviator right now, I see that Pros above are essential enough to change our mind and invest our own resources into creating really good OpenStack binding in Ruby. Some are saying that there is not so big involvement of Ruby into OpenStack. But we are actually working with Puppet/Ruby and are invloved into community. So why should not we own this by ourselves and lead by example here? I understand that many of you do already have a lot of things on their plate and cannot or would not want to support things like additional library when native OpenStack client is working reasonably well for you. But if I propose the following scheme to get support of native Ruby client for OpenStack: 1) we (community) have these resources (speaking of the company I am working for, we at Mirantis have a set of guys who could be very interested in working on Ruby client for OpenStack) 2) we gradually improve Aviator code base up to the level that it eliminates issues that are mentioned in 'Cons' section 3) we introduce additional set of providers and allow users and operators to pick whichever they want 4) we leave OpenStackClient default one Would you support it and allow such code to be merged into upstream puppet-openstack modules? [0] https://groups.google.com/a/puppetlabs.com/forum/#!searchin/puppet-openstack/aviator$20openstackclient/puppet-openstack/GJwDHNAFVYw/ayN4cdg3EW0J [1] https://github.com/openstack/puppet-swift/blob/master/lib/puppet/provider/swift_ring_builder.rb#L21-L86 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] [puppet][Fuel] OpenstackLib Client Provider Better Exception Handling
Hi, folks * Intro Per our discussion at Meeting #54 [0] I would like to propose the uniform approach of exception handling for all puppet-openstack providers accessing any types of OpenStack APIs. * Problem Description While working on Fuel during deployment of multi-node HA-aware environments we faced many intermittent operational issues, e.g.: 401/403 authentication failures when we were doing scaling of OpenStack controllers due to difference in hashing view between keystone instances 503/502/504 errors due to temporary connectivity issues non-idempotent operations like deletion or creation - e.g. if you are deleting an endpoint and someone is deleting on the other node and you get 404 - you should continue with success instead of failing. 409 Conflict error should also signal us to re-fetch resource parameters and then decide what to do with them. Obviously, it is not optimal to rerun puppet to correct such errors when we can just handle an exception properly. * Current State of Art There is some exception handling, but it does not cover all the aforementioned use cases. * Proposed solution Introduce a library of exception handling methods which should be the same for all puppet openstack providers as these exceptions seem to be generic. Then, for each of the providers we can introduce provider-specific libraries that will inherit from this one. Our mos-puppet team could add this into their backlog and could work on that in upstream or downstream and propose it upstream. What do you think on that, puppet folks? [0] http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-10-06-15.00.html -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][PTL] PTL Candidates Q&A Session
Which is actually contradictory and ambiguous and shows that PTL has less power than CLs while CLs at the same time have less power than PTL. I think this is the time when universe should collapse as we found that time-space is contradicting laws of propositional calculus. On Tue, Oct 6, 2015 at 6:26 PM, Tomasz Napierala wrote: > Hi > > That’s right, but we made slight change here: > "Define architecture direction & review majority of design specs. Rely on > Component Leads and Core Reviewers" > > So we assume that detailed architectural work will be relayed to Component > Leads > > > > On 02 Oct 2015, at 10:12, Evgeniy L wrote: > > > > Hi Mike, > > > > According to the description of the role, I wouldn't say that the role > is less architectural than > > political, since PTL should review designs and resolve conflicts between > cores (which are > > usually technical), PTL should also have strong skills in software > architecture, and understanding > > of what Fuel should look like. > > > > Thanks, > > > > On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov < > mscherba...@mirantis.com> wrote: > > > we may mix technical direction / tech debt roadmap and process, > political, and people management work of PTL. > > sorry, of course I meant that we rather should NOT mix these things. > > > > To make my email very short, I'd say PTL role is more political and > process-wise rather than architectural. > > > > On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov < > mscherba...@mirantis.com> wrote: > > Vladimir, > > we may mix technical direction / tech debt roadmap and process, > political, and people management work of PTL. > > > > PTL definition in OpenStack [1] reflects many things which PTL becomes > responsible for. This applies to Fuel as well. > > > > I'd like to reflect some things here which I'd expect PTL doing, most of > which will intersect with [1]: > > - Participate in cross-project initiatives & resolution of issues around > it. Great example is puppet-openstack vs Fuel [2] > > - Organize required processes around launchpad bugs & blueprints > > - Personal personal feedback to Fuel contributors & public suggestions > when needed > > - Define architecture direction & review majority of design specs. Rely > on Component Leads and Core Reviewers > > - Ensure that roadmap & use cases are aligned with architecture work > > - Resolve conflicts between core reviewers, component leads. Get people > to the same page > > - Watch for code review queues and quality of reviews. Ensure discipline > of code review. > > - Testing / coverage have to be at the high level > > > > Considering all above, contributors actually have been working with all > of us and know who could be better handling such a hard work. I don't think > special Q&A is needed. If there are concerns / particular process/tech > questions we'd like to discuss - those should be just open as email threads. > > > > [1] https://wiki.openstack.org/wiki/PTL_Guide > > [2] > http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html > > > > Thank you, > > > > On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin > wrote: > > Folks > > > > I think it is awesome we have three candidates for PTL position in Fuel. > I read all candidates' emails (including mine own several times :-) ) and I > got a slight thought of not being able to really differentiate the > candidates platforms as they are almost identical from the high-level point > of view. But we all know that the devil is in details. And this details > will actually affect project future. > > > > Thus I thought about Q&A session at #fuel-dev channel in IRC. I think > that this will be mutually benefitial for everyone to get our platforms a > little bit more clear. > > > > Let's do it before or right at the start of actual voting so that our > contributors can make better decisions based on this session. > > > > I suggest the following format: > > > > 1) 3 questions from electorate members - let's put them onto an etherpad > > 2) 2 questions from a candidate to his opponents (1 question per > opponent) > > 3) external moderator - I suppose, @xarses as our weekly meeting > moderator could help us > > 4) time and date - Wednesday or Thursday comfortable for both timezones, > e.g. after 4PM UTC or right after fuel weekly meeting. > > > > What do you think, folks? > > > > -- > > Yours Faithfully, > > Vladimir Kukl
Re: [openstack-dev] [fuel] What to do when a controller runs out of space
Eugene With all due respect to you and other OpenStack developers, I as a system administrator do not believe when someone says that something is working that way. Actually, what I would prefer to do is to stress-test these services on their 'statelessness'. Currently we have l3-agent not so stateless and lacking centralized synchronization in proper way which you have no actually defied. So I agree - let's move this into different thread and not hijack this one. On Tue, Oct 6, 2015 at 5:11 PM, Eugene Nikanorov wrote: > > On Tue, Oct 6, 2015 at 4:22 PM, Vladimir Kuklin > wrote: > >> Eugene >> >> For example, each time that you need to have one instance (e.g. master >> instance) of something non-stateless running in the cluster. >> > > Right. This is theoretical. Practically, there are no such services among > openstack. > > You are right that currently lots of things are fixed already - heat >> engine is fine, for example. But I still see this issue with l3 agents and >> I will not change my mind until we conduct complete scale and destructive >> testing with new neutron code. >> >> Secondly, if we cannot reliably identify when to engage - then we need to >> write the code that will tell us when to engage. If this code is already in >> place and we can trigger a couple of commands to figure out Neutron agent >> state, then we can add them to OCF script monitor and that is all. I agree >> that we have some issues with our OCF scripts, for example some unoptimal >> cleanup code that has issues with big scale, but I am almost sure we can >> fix it. >> >> Finally, let me show an example of when you need a centralized cluster >> manager to manage such situations - you have a temporary issue with >> connectivity to neutron server over management network for some reason. >> Your agents are not cleaned up and neutron server starts new l3 agent >> instances on different node. In this case you will have IP duplication in >> the network and will bring down the whole cluster as connectivity through >> 'public' network will be working just fine. In case when we are using >> Pacemaker - such node will be either fenced or will stop all the services >> controlled by pacemaker as it is a part of non-quorate partition of the >> cluster. When this happens, l3 agent OCF script will run its cleanup >> section and purge all the stale IPs thus saving us from the trouble. I >> obviously may be mistaking, so please correct me if this is not the case. >> > I think this deserves discussion in a separate thread, which I'll start > soon. > My initial point was (to state it clearly), that I will be -2 on any new > additions of openstack services to pacemaker kingdom. > > Thanks, > Eugene. > >> >> >> On Tue, Oct 6, 2015 at 3:46 PM, Eugene Nikanorov > > wrote: >> >>> >>> >>>> 2) I think you misunderstand what is the difference between >>>> upstart/systemd and Pacemaker in this case. There are many cases when you >>>> need to have syncrhonized view of the cluster. Otherwise you will hit >>>> split-brain situations and have your cluster misfunctioning. Until >>>> OpenStack provides us with such means there is no other way than using >>>> Pacemaker/Zookeper/etc. >>>> >>> >>> Could you please give some examples of those 'many cases' for openstack >>> specifically? >>> As for my 'misunderstanding' - openstack services only need to be always >>> up, not more than that. >>> Upstart does a perfect job there. >>> >>> >>>> 3) Regarding Neutron agents - we discussed it many times - you need to >>>> be able to control and clean up stuff after some service crashed. >>>> Currently, Neutron does not provide reliable ways to do it. If your agent >>>> dies and does not clean up ip addresses from the network namespace you will >>>> get into the situation of ARP duplication which will be a kind of split >>>> brain described in item #2. I personally as a system architect and >>>> administrator do not believe for this to change in at least several years >>>> for OpenStack so we will be using Pacemaker for a very long period of time. >>>> >>> >>> This has been changed already, and a while ago. >>> OCF infrastructure around neutron agents has never helped neutron in any >>> meaningful way and is just an artifact from the dark past. >>> The reasons are: pacemaker/ocf doesn't have enough intelligence to know >>>
Re: [openstack-dev] [fuel] What to do when a controller runs out of space
at the local rabbitmq >>>>> is always available but I need to look into that. Either way, I >>>>> believe we still should continue to discuss this issue as we are >>>>> managing services in multiple ways on a single host. Additionally I do >>>>> not believe that we really perform quality health checks on our >>>>> services. >>>>> >>>>> Thanks, >>>>> -Alex >>>>> >>>>> >>>>> > >>>>> > On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko < >>>>> svasile...@mirantis.com> >>>>> > wrote: >>>>> >> >>>>> >> >>>>> >> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov >>>>> >> wrote: >>>>> >>> >>>>> >>> No pacemaker for os services, please. >>>>> >>> We'll be moving out neutron agents from pacemaker control in 8.0, >>>>> other >>>>> >>> os services don't need it too. >>>>> >> >>>>> >> >>>>> >> could you please provide your arguments. >>>>> >> >>>>> >> >>>>> >> /sv >>>>> >> >>>>> >> >>>>> __ >>>>> >> 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 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 >>> >>> >> >> >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com <http://www.mirantis.ru/> >> www.mirantis.ru >> vkuk...@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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] What to do when a controller runs out of space
gt; > Most of openstack services (in fact, ALL api servers) are stateless, >>> they >>> > don't require any cluster management (also, they don't need to be >>> moved in >>> > case of lack of space). >>> > Statefull services like neutron agents have their states being a >>> function of >>> > db state and are able to syncronize it with the server without external >>> > "help". >>> > >>> >>> So it's not an issue with moving services so much as being able to >>> stop the services when a condition is met. Have we tested all OS >>> services to ensure they do function 100% when out of disk space? I >>> would assume that glance might have issues with image uploads if there >>> is no space to handle a request. >>> >>> > So now usage of pacemaker can be only justified for cases where >>> service's >>> > clustering mechanism requires active monitoring (rabbitmq, galera) >>> > But even there, examples when we are better off without pacemaker are >>> all >>> > around. >>> > >>> > Thanks, >>> > Eugene. >>> > >>> >>> After I sent this email, I had further discussions around the issues >>> that I'm facing and it may not be completely related to disk space. I >>> think we might be relying on the expectation that the local rabbitmq >>> is always available but I need to look into that. Either way, I >>> believe we still should continue to discuss this issue as we are >>> managing services in multiple ways on a single host. Additionally I do >>> not believe that we really perform quality health checks on our >>> services. >>> >>> Thanks, >>> -Alex >>> >>> >>> > >>> > On Mon, Oct 5, 2015 at 1:34 PM, Sergey Vasilenko < >>> svasile...@mirantis.com> >>> > wrote: >>> >> >>> >> >>> >> On Mon, Oct 5, 2015 at 12:22 PM, Eugene Nikanorov >>> >> wrote: >>> >>> >>> >>> No pacemaker for os services, please. >>> >>> We'll be moving out neutron agents from pacemaker control in 8.0, >>> other >>> >>> os services don't need it too. >>> >> >>> >> >>> >> could you please provide your arguments. >>> >> >>> >> >>> >> /sv >>> >> >>> >> >>> __ >>> >> 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 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] PTL & Component Leads elections
+1 to Igor. Do we have voting system set up? On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky wrote: > > * September 29 - October 8: PTL elections > > So, it's in progress. Where I can vote? I didn't receive any emails. > > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala > wrote: > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov > wrote: > >> > >> > >> Time line: > >> > >> PTL elections > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL > position > >> * September 29 - October 8: PTL elections > > > > Just a reminder that we have a deadline for candidates today. > > > > Regards, > > -- > > Tomasz 'Zen' Napierala > > Product Engineering - Poland > > > > > > > > > > > > > > > > > > > __ > > 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 > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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][PTL] PTL Candidates Q&A Session
Folks I think it is awesome we have three candidates for PTL position in Fuel. I read all candidates' emails (including mine own several times :-) ) and I got a slight thought of not being able to really differentiate the candidates platforms as they are almost identical from the high-level point of view. But we all know that the devil is in details. And this details will actually affect project future. Thus I thought about Q&A session at #fuel-dev channel in IRC. I think that this will be mutually benefitial for everyone to get our platforms a little bit more clear. Let's do it before or right at the start of actual voting so that our contributors can make better decisions based on this session. I suggest the following format: 1) 3 questions from electorate members - let's put them onto an etherpad 2) 2 questions from a candidate to his opponents (1 question per opponent) 3) external moderator - I suppose, @xarses as our weekly meeting moderator could help us 4) time and date - Wednesday or Thursday comfortable for both timezones, e.g. after 4PM UTC or right after fuel weekly meeting. What do you think, folks? -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Fuel PTL Candidacy
nleash The Monster of Synergy) And the last but not least - community collaboration. We are doing great job while gluing existing deployment libraries and testing their integration. Community folks like puppet-openstack are also doing great job. And, instead of duplicating it, I would like to merge with upstream code as much as possible thus freeing our resources onto the things we do the best along with sharing the stuff we do the best with community by testing results of their work against our reference architecture and installations. Additionally, it is worth to mention that I envision significant value in making Fuel able to install current OpenStack trunk code thus allowing us to set up Fuel CI for each piece of OpenStack and allowing OpenStack developers to test their code against multi-host HA-enabled reference architecture in an easy and automated way. * Conclusion I am sure that going this way will make our project better and ramp up our project quality and growth significantly, allow us to finally join Big Tent and become the default most effective and easy-to-use installer and manager of OpenStack clouds. I will be happy to lead Fuel project during this cadence with this pretty consistent and wide platform. It seems a little bit ambitious and not so simple to implement it - but I expect help from Component Leads for Fuel-Library and Fuel-Python as well as yours. Remember, as Red Queen said: "you must run at least twice as fast as that!" Thank you all for your time and consideration! -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] PTL & Component Leads elections
Dmitry Thank you for the clarification, but my questions still remain unanswered, unfortunately. It seems I did not phrase them correctly. 1) For each of the positions, which set of git repositories should I run this command against? E.g. which stackforge/fuel-* projects contributors are electing PTL or CL? 2) Who is voting for component leads? Mike's email says these are core reviewers. Our previous IRC meeting mentioned all the contributors to particular components. Documentation link you sent is mentioning all contributors to Fuel projects. Whom should I trust? What is the final version? Is it fine that documentation contributor is eligible to nominate himself and vote for Library Component Lead? Until there is a clear and sealed answer to these questions we do not have a list of people who can vote and who can nominate. Let's get it clear at least before PTL elections start. On Thu, Sep 24, 2015 at 4:49 AM, Dmitry Borodaenko wrote: > Vladimir, > > Sergey's initial email from this thread has a link to the Fuel elections > wiki page that describes the exact procedure to determine the electorate > and the candidates [0]: > > The electorate for a given PTL and Component Leads election are the > Foundation individual members that are also committers for one of > the Fuel team's repositories over the last year timeframe (September > 18, 2014 06:00 UTC to September 18, 2015 05:59 UTC). > > ... > > Any member of an election electorate can propose their candidacy for > the same election. > > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015#Electorate > > If you follow more links from that page, you will find the Governance > page [1] and from there the Election Officiating Guidelines [2] that > provide a specific shell one-liner to generate that list: > > git log --pretty=%aE --since '1 year ago' | sort -u > > [1] https://wiki.openstack.org/wiki/Governance > [2] https://wiki.openstack.org/wiki/Election_Officiating_Guidelines > > As I have specified in the proposed Team Structure policy document [3], > this is the same process that is used by other OpenStack projects. > > [3] https://review.openstack.org/225376 > > Having a different release schedule is not a sufficient reason for Fuel > to reinvent the wheel, for example OpenStack Infrastructure project > doesn't even have a release schedule for many of its deliverables, and > still follows the same elections schedule as the rest of OpenStack: > > [4] http://governance.openstack.org/reference/projects/infrastructure.html > > Lets keep things simple. > > -- > Dmitry Borodaenko > > > On Wed, Sep 23, 2015 at 01:27:07PM +0300, Vladimir Kuklin wrote: > > Dmitry, Mike > > > > Thank you for the list of usable links. > > > > But still - we do not have clearly defined procedure on determening who > is > > eligible to nominate and vote for PTL and Component Leads. Remember, that > > Fuel still has different release cycle and Kilo+Liberty contributors list > > is not exactly the same for "365days" contributors list. > > > > Can we finally come up with the list of people eligible to nominate and > > vote? > > > > On Sun, Sep 20, 2015 at 2:37 AM, Mike Scherbakov < > mscherba...@mirantis.com> > > wrote: > > > > > Let's move on. > > > I started work on MAINTAINERS files, proposed two patches: > > > https://review.openstack.org/#/c/225457/1 > > > https://review.openstack.org/#/c/225458/1 > > > > > > These can be used as templates for other repos / folders. > > > > > > Thanks, > > > > > > On Fri, Sep 18, 2015 at 7:45 PM Davanum Srinivas > > > wrote: > > > > > >> +1 Dmitry > > >> > > >> -- Dims > > >> > > >> On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko < > > >> dborodae...@mirantis.com> wrote: > > >> > > >>> Dims, > > >>> > > >>> Thanks for the reminder! > > >>> > > >>> I've summarized the uncontroversial parts of that thread in a policy > > >>> proposal as per you suggestion [0], please review and comment. I've > > >>> renamed SMEs to maintainers since Mike has agreed with that part, > and I > > >>> omitted code review SLAs from the policy since that's the part that > has > > >>> generated the most discussion. > > >>> > > >>> [0] https://review.openstack.org/225376 > > >>> > > >>> I don't think we should postpone the el
Re: [openstack-dev] [fuel] PTL & Component Leads elections
Dmitry, Mike Thank you for the list of usable links. But still - we do not have clearly defined procedure on determening who is eligible to nominate and vote for PTL and Component Leads. Remember, that Fuel still has different release cycle and Kilo+Liberty contributors list is not exactly the same for "365days" contributors list. Can we finally come up with the list of people eligible to nominate and vote? On Sun, Sep 20, 2015 at 2:37 AM, Mike Scherbakov wrote: > Let's move on. > I started work on MAINTAINERS files, proposed two patches: > https://review.openstack.org/#/c/225457/1 > https://review.openstack.org/#/c/225458/1 > > These can be used as templates for other repos / folders. > > Thanks, > > On Fri, Sep 18, 2015 at 7:45 PM Davanum Srinivas > wrote: > >> +1 Dmitry >> >> -- Dims >> >> On Fri, Sep 18, 2015 at 9:07 PM, Dmitry Borodaenko < >> dborodae...@mirantis.com> wrote: >> >>> Dims, >>> >>> Thanks for the reminder! >>> >>> I've summarized the uncontroversial parts of that thread in a policy >>> proposal as per you suggestion [0], please review and comment. I've >>> renamed SMEs to maintainers since Mike has agreed with that part, and I >>> omitted code review SLAs from the policy since that's the part that has >>> generated the most discussion. >>> >>> [0] https://review.openstack.org/225376 >>> >>> I don't think we should postpone the election: the PTL election follows >>> the same rules as OpenStack so we don't need a Fuel-specific policy for >>> that, and the component leads election doesn't start until October 9, >>> which gives us 3 weeks to confirm consensus on that aspect of the >>> policy. >>> >>> -- >>> Dmitry Borodaenko >>> >>> >>> On Fri, Sep 18, 2015 at 07:30:39AM -0400, Davanum Srinivas wrote: >>> > Sergey, >>> > >>> > Please see [1]. Did we codify some of these roles and responsibilities >>> as a >>> > community in a spec? There was also a request to use terminology like >>> say >>> > MAINTAINERS in that email as well. >>> > >>> > Are we pulling the trigger a bit early for an actual election? >>> > >>> > Thanks, >>> > Dims >>> > >>> > [1] http://markmail.org/message/2ls5obgac6tvcfss >>> > >>> > On Fri, Sep 18, 2015 at 6:56 AM, Vladimir Kuklin >> > >>> > wrote: >>> > >>> > > Sergey, Fuelers >>> > > >>> > > This is awesome news! >>> > > >>> > > By the way, I have a question on who is eligible to vote and to >>> nominate >>> > > him/her-self for both PTL and Component Leads. Could you elaborate >>> on that? >>> > > >>> > > And there is no such entity as Component Lead in OpenStack - so we >>> are >>> > > actually creating one. What are the new rights and responsibilities >>> of CL? >>> > > >>> > > On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov < >>> slukja...@mirantis.com> >>> > > wrote: >>> > > >>> > >> Hi folks, >>> > >> >>> > >> I'd like to announce that we're running the PTL and Component Leads >>> > >> elections. Detailed information available on wiki. [0] >>> > >> >>> > >> Project Team Lead: Manages day-to-day operations, drives the project >>> > >> team goals, resolves technical disputes within the project team. [1] >>> > >> >>> > >> Component Lead: Defines architecture of a module or component in >>> Fuel, >>> > >> reviews design specs, merges majority of commits and resolves >>> conflicts >>> > >> between Maintainers or contributors in the area of responsibility. >>> [2] >>> > >> >>> > >> Fuel has two large sub-teams, with roughly comparable codebases, >>> that >>> > >> need dedicated component leads: fuel-library and fuel-python. [2] >>> > >> >>> > >> Nominees propose their candidacy by sending an email to the >>> > >> openstack-dev@lists.openstack.org mailing-list, which the subject: >>> > >> "[fuel] PTL candidacy" or "[fuel] lead candidacy" >>> > >> (for example, "
Re: [openstack-dev] [Fuel] Core Reviewers groups restructure
+1 On Tue, Sep 22, 2015 at 2:17 AM, Mike Scherbakov wrote: > Thanks guys. > So for fuel-octane then there are no actions needed. > > For fuel-agent-core group [1], looks like we are already good (it doesn't > have fuel-core group nested). But it would need to include fuel-infra group > and remove Aleksandra Fedorova (she will be a part of fuel-infra group). > > python-fuel-client-core [2] is good as well (no nested fuel-core). > However, there is another group python-fuelclient-release [3], which has to > be eliminated, and main python-fuelclient-core would just have fuel-infra > group included for maintenance purposes. > > [1] https://review.openstack.org/#/admin/groups/995,members > [2] https://review.openstack.org/#/admin/groups/551,members > [3] https://review.openstack.org/#/admin/groups/552,members > > > On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh > wrote: > >> FYI, we have a separate core group for stackforge/fuel-octane repository >> [1]. >> >> I'm supporting the move to modularization of Fuel with cleaner separation >> of authority and better defined interfaces. Thus, I'm +1 to such a change >> as a part of that move. >> >> [1] https://review.openstack.org/#/admin/groups/1020,members >> >> -- >> Best regards, >> Oleg Gelbukh >> >> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov < >> mscherba...@mirantis.com> wrote: >> >>> Hi all, >>> as of my larger proposal on improvements to code review workflow [1], we >>> need to have cores for repositories, not for the whole Fuel. It is the path >>> we are taking for a while, and new core reviewers added to specific repos >>> only. Now we need to complete this work. >>> >>> My proposal is: >>> >>>1. Get rid of one common fuel-core [2] group, members of which can >>>merge code anywhere in Fuel. Some members of this group may cover a >>> couple >>>of repositories, but can't really be cores in all repos. >>>2. Extend existing groups, such as fuel-library [3], with members >>>from fuel-core who are keeping up with large number of reviews / merges. >>>This data can be queried at Stackalytics. >>>3. Establish a new group "fuel-infra", and ensure that it's included >>>into any other core group. This is for maintenance purposes, it is >>> expected >>>to be used only in exceptional cases. Fuel Infra team will have to decide >>>whom to include into this group. >>>4. Ensure that fuel-plugin-* repos will not be affected by removal >>>of fuel-core group. >>> >>> #2 needs specific details. Stackalytics can show active cores easily, we >>> can look at people with *: >>> http://stackalytics.com/report/contribution/fuel-web/180. This is for >>> fuel-web, change the link for other repos accordingly. If people are added >>> specifically to the particular group, leaving as is (some of them are no >>> longer active. But let's clean them up separately from this group >>> restructure process). >>> >>>- fuel-library-core [3] group will have following members: Bogdan >>>D., Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko. >>>- fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, >>>Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak >>>- fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li >>>- fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K. >>>- fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky, >>>Nastya Urlapova >>>- fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny >>>Konstantinov, Olga Gusarenko >>>- fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry >>>Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky >>>- fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov >>>- fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey >>>Sledzinsky, Dmitry Shulyak >>>- fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin >>>- fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya >>>Urlapova >>>- fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly >>>Kramskikh >>>- fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey >>>Kasatkin (this project seems to be dead, let's consider to rip it off) >>>- fuel-specs-core: there is no such a
[openstack-dev] Apache2 vs uWSGI vs ...
Folks I just suggested to untie keystone from wsgi and implement uwsgi support. And then let the user decide what he or she wants. There is a plenty of auth modules for nginx also. Nginx us much better as a proxy server and you know it. Regarding mod wsgi and apache we already saw that it cannot handle simple restart. I think this is not in any way acceptable from operations point if view. 18 сент. 2015 г. 18:59 пользователь "Fox, Kevin M" написал: > Part of the reason to use Apache though is the diverse set of > authentication mechanisms it supports. Operators have the desire to plugin > Keystone into their existing authentication systems and Apache tends to be > easier to do that then others. > > Thanks, > Kevin > > From: Jim Rollenhagen [j...@jimrollenhagen.com] > Sent: Thursday, September 17, 2015 7:04 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] Apache2 vs uWSGI vs ... > > On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote: > > In the fuel project, we recently ran into a couple of issues with > Apache2 + > > mod_wsgi as we switched Keystone to run . Please see [1] and [2]. > > > > Looking deep into Apache2 issues specifically around "apache2ctl > graceful" > > and module loading/unloading and the hooks used by mod_wsgi [3]. I > started > > wondering if Apache2 + mod_wsgi is the "right" solution and if there was > > something else better that people are already using. > > > > One data point that keeps coming up is, all the CI jobs use Apache2 + > > mod_wsgi so it must be the best solutionIs it? If not, what is? > > Disclaimer: it's been a while since I've cared about performance with a > web server in front of a Python app. > > IIRC, mod_wsgi was abandoned for a while, but I think it's being worked > on again. In general, I seem to remember it being thought of as a bit > old and crusty, but mostly working. > > At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0] > and saw a significant performance increase. This was a Django app. uwsgi > is fairly straightforward to operate and comes loaded with a myriad of > options[1] to help folks make the most of it. I've played with Ironic > behind uwsgi and it seemed to work fine, though I haven't done any sort > of load testing. I'd encourage folks to give it a shot. :) > > Of course, uwsgi can also be ran behind Apache2, if you'd prefer. > > gunicorn[2] is another good option that may be worth investigating; I > personally don't have any experience with it, but I seem to remember > hearing it has good eventlet support. > > // jim > > [0] https://uwsgi-docs.readthedocs.org/en/latest/ > [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html > [2] http://gunicorn.org/ > > __ > 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] Apache2 vs uWSGI vs ...
Folks I think we do not need to switch to nginx-only or consider any kind of war between nginx and apache adherents. Everyone should be able to use web-server he or she needs without being pinned to the unwanted one. It is like Postgres vs MySQL war. Why not support both? May be someone does not need something that apache supports and nginx not and needs nginx features which apache does not support. Let's let our users decide what they want. And the first step should be simple here - support for uwsgi. It will allow for usage of any web-server that can work with uwsgi. It will allow also us to check for the support of all apache-like bindings like SPNEGO or whatever and provide our users with enough info on making decisions. I did not personally test nginx modules for SAML and SPNEGO, but I am pretty confident about TLS/SSL parts of nginx. Moreover, nginx will allow you to do things you cannot do with apache, e.g. do smart load balancing, which may be crucial for high-loaded installations. On Fri, Sep 18, 2015 at 4:12 PM, Adam Young wrote: > On 09/17/2015 10:04 PM, Jim Rollenhagen wrote: > > On Thu, Sep 17, 2015 at 06:48:50PM -0400, Davanum Srinivas wrote: > > In the fuel project, we recently ran into a couple of issues with Apache2 + > mod_wsgi as we switched Keystone to run . Please see [1] and [2]. > > Looking deep into Apache2 issues specifically around "apache2ctl graceful" > and module loading/unloading and the hooks used by mod_wsgi [3]. I started > wondering if Apache2 + mod_wsgi is the "right" solution and if there was > something else better that people are already using. > > One data point that keeps coming up is, all the CI jobs use Apache2 + > mod_wsgi so it must be the best solutionIs it? If not, what is? > > Disclaimer: it's been a while since I've cared about performance with a > web server in front of a Python app. > > IIRC, mod_wsgi was abandoned for a while, but I think it's being worked > on again. In general, I seem to remember it being thought of as a bit > old and crusty, but mostly working. > > > I am not aware of that. It has been the workhorse of the Python/wsgi > world for a while, and we use it heavily. > > > At a previous job, we switched from Apache2 + mod_wsgi to nginx + uwsgi[0] > and saw a significant performance increase. This was a Django app. uwsgi > is fairly straightforward to operate and comes loaded with a myriad of > options[1] to help folks make the most of it. I've played with Ironic > behind uwsgi and it seemed to work fine, though I haven't done any sort > of load testing. I'd encourage folks to give it a shot. :) > > > Again, switching web servers is as likely to introduce as to solve > problems. If there are performance issues: > > 1. Idenitfy what causes them > 2. Change configuration settings to deal with them > 3. Fix upstream bugs in the underlying system. > > > Keystone is not about performance. Keystone is about security. The cloud > is designed to scale horizontally first. Before advocating switching to a > difference web server, make sure it supports the technologies required. > > > 1. TLS at the latest level > 2. Kerberos/GSSAPI/SPNEGO > 3. X509 Client cert validation > 4. SAML > > OpenID connect would be a good one to add to the list; Its been requested > for a while. > > If Keystone is having performance issues, it is most likely at the > database layer, not the web server. > > > > "Programmers waste enormous amounts of time thinking about, or worrying > about, the speed of noncritical parts of their programs, and these attempts > at efficiency actually have a strong negative impact when debugging and > maintenance are considered. We *should* forget about small efficiencies, > say about 97% of the time: *premature optimization is the root of all > evil.* Yet we should not pass up our opportunities in that critical > 3%." --Donald Knuth > > > > > Of course, uwsgi can also be ran behind Apache2, if you'd prefer. > > gunicorn[2] is another good option that may be worth investigating; I > personally don't have any experience with it, but I seem to remember > hearing it has good eventlet support. > > // jim > > [0] https://uwsgi-docs.readthedocs.org/en/latest/ > [1] https://uwsgi-docs.readthedocs.org/en/latest/Options.html > [2] http://gunicorn.org/ > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___
Re: [openstack-dev] [fuel] PTL & Component Leads elections
Sergey, Fuelers This is awesome news! By the way, I have a question on who is eligible to vote and to nominate him/her-self for both PTL and Component Leads. Could you elaborate on that? And there is no such entity as Component Lead in OpenStack - so we are actually creating one. What are the new rights and responsibilities of CL? On Fri, Sep 18, 2015 at 5:39 AM, Sergey Lukjanov wrote: > Hi folks, > > I'd like to announce that we're running the PTL and Component Leads > elections. Detailed information available on wiki. [0] > > Project Team Lead: Manages day-to-day operations, drives the project > team goals, resolves technical disputes within the project team. [1] > > Component Lead: Defines architecture of a module or component in Fuel, > reviews design specs, merges majority of commits and resolves conflicts > between Maintainers or contributors in the area of responsibility. [2] > > Fuel has two large sub-teams, with roughly comparable codebases, that > need dedicated component leads: fuel-library and fuel-python. [2] > > Nominees propose their candidacy by sending an email to the > openstack-dev@lists.openstack.org mailing-list, which the subject: > "[fuel] PTL candidacy" or "[fuel] lead candidacy" > (for example, "[fuel] fuel-library lead candidacy"). > > Time line: > > PTL elections > * September 18 - September 28, 21:59 UTC: Open candidacy for PTL position > * September 29 - October 8: PTL elections > > Component leads elections (fuel-library and fuel-python) > * October 9 - October 15: Open candidacy for Component leads positions > * October 16 - October 22: Component leads elections > > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Fall_2015 > [1] https://wiki.openstack.org/wiki/Governance > [2] > http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html > [3] https://lwn.net/Articles/648610/ > > -- > Sincerely yours, > Sergey Lukjanov > Sahara Technical Lead > (OpenStack Data Processing) > Principal Software Engineer > Mirantis Inc. > > __ > 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 > > -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com <http://www.mirantis.ru/> www.mirantis.ru vkuk...@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] Remove MOS DEB repo from master node
Folks I guess I need to get you on-site to deploy something at our user's datacenter. I do want to be able to download an ISO which contains all packages. This may not be the primary artifact of our software suite, but we need to have this opportunity to build full ISO with ALL components. Please, do not narrow down our feature set just by thinking that users do not need something because we are reluctant to implement this. Just believe me - users need this opportunity in a lot of deployment cases. It is not hard to implement it. We do not need to set this as a default option, but we need to have it. That is my point. On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Vladimir, > > * We don't have full ISO anyway > * We don't require to create mirror. When you launch your browser, do you > mean to have mirror of the Internet locally? Probably, no. The same is > here. Internet connection is the common requirement nowadays, but if you > don't have one, you definitely need to have a kind of local copy. > > Vladimir Kozhukalov > > On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin > wrote: > >> Igor >> >> Having poor access to the internet is a regular use case which we must >> support. This is not a crazy requirement. Not having full ISO makes cloud >> setup harder to complete. Even more, not having hard requirement to create >> a mirror will detract newcomers. I can say that if I were a user and saw a >> requirement to create mirror I would not try the product with comparison to >> the case when I can get a full ISO with all the stuff I need. >> >> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov < >> vkozhuka...@mirantis.com> wrote: >> >>> Guys, >>> >>> I really appreciate your opinions on whether Fuel should be all >>> inclusive or not. But the original topic of this thread is different. I >>> personally think that in 2015 it is not a big deal to make the master node >>> able to access any online host (even taking into account paranoid security >>> policies). It is just a matter of network engineering. But it is completely >>> out of the scope. What I am suggesting is to align the way how we treat >>> different repos, whether upstream or MOS. What I am working on right now is >>> I am trying to make Fuel build and delivery approach really flexible. That >>> means we need to have as little non-standard ways/hacks/approaches/options >>> as possible. >>> >>> > Why can't we make this optional in the build system? It should be easy >>> to implement, is not it? >>> >>> That is exactly what I am trying to do (make it optional). But I don't >>> want it to be yet another boolean variable for this particular thing (MOS >>> repo). We have working approach for dealing with repos. Repos can either >>> online or local mirrors. We have a tool for making local mirrors >>> (fuel-createmirror). Even if we put MOS on the ISO, a user still can not >>> deploy OpenStack, because he/she still needs upstream to be available. >>> Anyway, the user is still forced to do some additional actions. Again, we >>> have plans to improve the quality and UX of fuel-createmirror. >>> >>> Yet another thing I don't want to be on the master node is a bunch of >>> MOS repos directories named like >>> /var/www/nailgun/2015.1-7.0 >>> /var/www/nailgun/2014.4-6.1 >>> with links like >>> /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0 >>> What does this link mean? Even Fuel developers can be confused. It is >>> scary to imagine what users think of it :-) Why should Nailgun and upgrade >>> script manage that kind of storage in this exact kind of format? A long >>> time ago people invented RPM/DEB repositories, tools to manage them and >>> structure for versioning them. We have Perestoika for that and we have >>> plans to put all package/mirror related tools in one place ( >>> github.com/stackforge/fuel-mirror) and make all these tools available >>> out of Fuel CI. So, users will be able to easily build their own packages, >>> clone necessary repos and manage them in the way which is standard in the >>> industry. However, it is out of the scope of the letter. >>> >>> I also don't like the idea of putting MOS repo on the ISO by default >>> because it encourages people thing that ISO is the way of distributing MOS. >>> ISO should be nothing more than just a way of installing Fuel from scratch. >>> MOS should be distributed via MOS
Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node
Igor Having poor access to the internet is a regular use case which we must support. This is not a crazy requirement. Not having full ISO makes cloud setup harder to complete. Even more, not having hard requirement to create a mirror will detract newcomers. I can say that if I were a user and saw a requirement to create mirror I would not try the product with comparison to the case when I can get a full ISO with all the stuff I need. On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Guys, > > I really appreciate your opinions on whether Fuel should be all inclusive > or not. But the original topic of this thread is different. I personally > think that in 2015 it is not a big deal to make the master node able to > access any online host (even taking into account paranoid security > policies). It is just a matter of network engineering. But it is completely > out of the scope. What I am suggesting is to align the way how we treat > different repos, whether upstream or MOS. What I am working on right now is > I am trying to make Fuel build and delivery approach really flexible. That > means we need to have as little non-standard ways/hacks/approaches/options > as possible. > > > Why can't we make this optional in the build system? It should be easy > to implement, is not it? > > That is exactly what I am trying to do (make it optional). But I don't > want it to be yet another boolean variable for this particular thing (MOS > repo). We have working approach for dealing with repos. Repos can either > online or local mirrors. We have a tool for making local mirrors > (fuel-createmirror). Even if we put MOS on the ISO, a user still can not > deploy OpenStack, because he/she still needs upstream to be available. > Anyway, the user is still forced to do some additional actions. Again, we > have plans to improve the quality and UX of fuel-createmirror. > > Yet another thing I don't want to be on the master node is a bunch of MOS > repos directories named like > /var/www/nailgun/2015.1-7.0 > /var/www/nailgun/2014.4-6.1 > with links like > /var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0 > What does this link mean? Even Fuel developers can be confused. It is > scary to imagine what users think of it :-) Why should Nailgun and upgrade > script manage that kind of storage in this exact kind of format? A long > time ago people invented RPM/DEB repositories, tools to manage them and > structure for versioning them. We have Perestoika for that and we have > plans to put all package/mirror related tools in one place ( > github.com/stackforge/fuel-mirror) and make all these tools available out > of Fuel CI. So, users will be able to easily build their own packages, > clone necessary repos and manage them in the way which is standard in the > industry. However, it is out of the scope of the letter. > > I also don't like the idea of putting MOS repo on the ISO by default > because it encourages people thing that ISO is the way of distributing MOS. > ISO should be nothing more than just a way of installing Fuel from scratch. > MOS should be distributed via MOS repos. Fuel is available as RPM package > in RPM MOS repo. > > > > > > > > Vladimir Kozhukalov > > On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky > wrote: > >> Mike, >> >> > still not exactly true for some large enterprises. Due to all the >> security, etc., >> > there are sometimes VPNs / proxies / firewalls with very low throughput. >> >> It's their problem, and their policies. We can't and shouldn't handle >> all possible cases. If some enterprise has "no Internet" policy, I bet >> it won't be a problem for their IT guys to create an intranet mirror >> for MOS packages. Moreover, I also bet they do have a mirror for >> Ubuntu or other Linux distributive. So it basically about approach how >> to consume our mirrors. >> >> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin >> wrote: >> > Folks >> > >> > I think, Mike is completely right here - we need an option to build >> > all-in-one ISO which can be tried-out/deployed unattendedly without >> internet >> > access. Let's let a user make a choice what he wants, not push him into >> > embarassing situation. We still have many parts of Fuel which make >> choices >> > for user that cannot be overriden. Let's not pretend that we know more >> than >> > user does about his environment. >> > >> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh >> > wrote: >> >> >> >> The reason people want offline d
Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node
Igor This is not the case to tell users if they are stupid are not. We are working for our users, not vice versa. On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky wrote: > Mike, > > > still not exactly true for some large enterprises. Due to all the > security, etc., > > there are sometimes VPNs / proxies / firewalls with very low throughput. > > It's their problem, and their policies. We can't and shouldn't handle > all possible cases. If some enterprise has "no Internet" policy, I bet > it won't be a problem for their IT guys to create an intranet mirror > for MOS packages. Moreover, I also bet they do have a mirror for > Ubuntu or other Linux distributive. So it basically about approach how > to consume our mirrors. > > On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin > wrote: > > Folks > > > > I think, Mike is completely right here - we need an option to build > > all-in-one ISO which can be tried-out/deployed unattendedly without > internet > > access. Let's let a user make a choice what he wants, not push him into > > embarassing situation. We still have many parts of Fuel which make > choices > > for user that cannot be overriden. Let's not pretend that we know more > than > > user does about his environment. > > > > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh > > wrote: > >> > >> The reason people want offline deployment feature is not because of poor > >> connection, but rather the enterprise intranets where getting subnet > with > >> external access sometimes is a real pain in various body parts. > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> > >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky < > ikalnit...@mirantis.com> > >> wrote: > >>> > >>> Hello, > >>> > >>> I agree with Vladimir - the idea of online repos is a right way to > >>> move. In 2015 I believe we can ignore this "poor Internet connection" > >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux > >>> distributives - most of them fetch needed packages from the Internet > >>> during installation, not from CD/DVD. The netboot installers are > >>> popular, I can't even remember when was the last time I install my > >>> Debian from the DVD-1 - I use netboot installer for years. > >>> > >>> Thanks, > >>> Igor > >>> > >>> > >>> On Thu, Sep 10, 2015 at 3:58 AM, Yaguang Tang > wrote: > >>> > > >>> > > >>> > On Thu, Sep 10, 2015 at 3:29 AM, Alex Schultz > > >>> > wrote: > >>> >> > >>> >> > >>> >> Hey Vladimir, > >>> >> > >>> >>> > >>> >>> > >>> >>>>> > >>> >>>>> 1) There won't be such things in like [1] and [2], thus less > >>> >>>>> complicated flow, less errors, easier to maintain, easier to > >>> >>>>> understand, > >>> >>>>> easier to troubleshoot > >>> >>>>> 2) If one wants to have local mirror, the flow is the same as in > >>> >>>>> case > >>> >>>>> of upstream repos (fuel-createmirror), which is clrear for a user > >>> >>>>> to > >>> >>>>> understand. > >>> >>>> > >>> >>>> > >>> >>>> From the issues I've seen, fuel-createmirror isn't very straight > >>> >>>> forward and has some issues making it a bad UX. > >>> >>> > >>> >>> > >>> >>> I'd say the whole approach of having such tool as fuel-createmirror > >>> >>> is a > >>> >>> way too naive. Reliable internet connection is totally up to > network > >>> >>> engineering rather than deployment. Even using proxy is much better > >>> >>> that > >>> >>> creating local mirror. But this discussion is totally out of the > >>> >>> scope of > >>> >>> this letter. Currently, we have fuel-createmirror and it is pretty > >>> >>> straightforward (installed as rpm, has just a couple of command > line > >>> >>> options). The quality of this script is also out of the scope of
