Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard
Hi, Let's call this hypervisor type "Qemu-KVM". So it will be a separate HV like vCenter, Xen, or HyperV. The actual selection between qemu and kvm will be a HV specific option in this case. On Mon, Dec 21, 2015 at 1:24 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Hello, > > Agree with Kevin. libvirt itself isn't a hypervisor. It's an API (or > single entry point) for dealing with other hypervisors, including qemu > and kvm. > > So it's kinda confusing, I'd prefer to find another solution. > > Thanks, > Igor > > On Fri, Dec 18, 2015 at 7:24 PM, Fox, Kevin M <kevin@pnnl.gov> wrote: > > I think it may be confusing to a fair number of the users you are > targeting. > > libvirt supports more then just qemu/kvm. xen, virtualbox, and others. > > saying libvirt makes people have to know that when you say libvirt you > mean > > just the qemu/kvm that nova supports using the implementation detail of > > using libvirt. > > > > Thanks, > > Kevin > > > > From: Aleksandr Didenko [adide...@mirantis.com] > > Sent: Friday, December 18, 2015 4:16 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt > on > > Wizard > > > > Hi, > > > > looks good to me. > > > > Regards, > > Alex > > > > On Fri, Dec 18, 2015 at 10:17 AM, Andriy Popovych < > apopov...@mirantis.com> > > wrote: > >> > >> Hi fuelers, > >> > >> We want to throw KVM/QEMU options from Wizard and instead of them leave > >> only one: Libvirt [0]. Libvirt option enables QEMU by default and there > are > >> still be possibility to change it on KVM in settings. It looks more > >> logically because both QEMU\KVM are options for libvirt which manage > them. > >> > >> What are you think about it? > >> > >> [0] https://review.openstack.org/#/c/258690 > >> > >> > __ > >> 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
Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard
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 <ikalnit...@mirantis.com> 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 <sgreg...@mirantis.com> > 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) > > <openstack-dev@lists.openstack.org> > > 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 > >> <ikalnit...@mirantis.com> > >> 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
Re: [openstack-dev] [Fuel][Plugins] add health check for plugins
OSTF was designed to be a post-deployment test framework. We may introduce pre- and post-deployment tests in Fuel, but from an implementation point of view the "pre-" should be done by Nailgun/Astute and the "post-" by OSTF. I don't think we should mix both in OSTF. On Tue, Sep 29, 2015 at 10:02 AM, Samuel Bartel <samuel.bartel@gmail.com > wrote: > it makes sense. > We have two intersting use cases here: > -to extend sanity test to validate plugins (see example in my previous > email) > -to extend OSTF test to add pre-deployment check. verify network tests are > not enough to ensure that a deployment will be successfull or not. there > are lot of other external parameters which can impact the deployment. > VMWare credentials as mentionned by sheena is a good example but there is > also check DNS, NTP, Netapp credentials , Netapp or NFS server ip is > reachable, external Elasticsearch or Influxdb server is reachable (in case > of using external servers for LMA) and so one. It would be very > interesting to be able to add those tests for core components and plugins. > it would help us to ensure user that if your tests are ok so no external > elements would interfere with you deployment. it can be a verify settings > test as the verify network one > > > > 2015-09-28 11:06 GMT+02:00 Sheena Gregson <sgreg...@mirantis.com>: > >> I just realized I missed this thread when Andrey responded to it – >> apologies! >> >> >> >> I was thinking of things like – confirming VMware username and password >> are accurate, confirming that SSL certificate chain is valid, etc. – some >> of these are not plugin based, but I think there is value in enabling both >> core components and plugins to specify tests that can be run prior to >> deployment that will help ensure the deployment will not fail. >> >> >> >> Does that make sense? In this case, it is not confirming the deployment >> was successful (post-deployment), it is checking known parameters for >> validity prior to attempting to deploy (pre-deployment). >> >> >> >> *From:* Samuel Bartel [mailto:samuel.bartel@gmail.com] >> *Sent:* Monday, September 28, 2015 11:13 AM >> >> *To:* OpenStack Development Mailing List (not for usage questions) < >> openstack-dev@lists.openstack.org> >> *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for >> plugins >> >> >> >> Hi, >> >> Totally agree with you Andrey, >> >> other use cases could be : >> >> -for Ironic plugin, add test to validate that Ironic is properly deploy >> >> -for LMA plugin check that metric and log are properly collect, that elk, >> nagios or grafana dashboard are accessible >> >> -for cinder netapp multi backend, check that different type of backend >> can be crreated >> >> and so on >> >> So it would be very intersting to have enxtensibility ofr OSTF test >> >> >> >> >> >> Samuel >> >> >> >> 2015-09-08 0:05 GMT+02:00 Andrey Danin <ada...@mirantis.com>: >> >> Hi. >> >> Sorry for bringing this thread back from the grave but it look quite >> interesting to me. >> >> Sheena, could you please explain how pre-deployment sanity checks should >> look like? I don't get what it is. >> >> From the Health Check point of view plugins may be divided to two groups: >> >> >> 1) A plugin that doesn't change an already covered functionality thus >> doesn't require extra tests implemented. Such plugins may be Contrail and >> almost all SDN plugins, Glance or Cinder backend plugins, and others which >> don't bring any changes in OSt API or any extra OSt components. >> >> >> 2) A plugin that adds new elements into OSt or changes API or a standard >> behavior. Such plugins may be Contrail (because it actually adds Contrail >> Controller which may be covered by Health Check too), Cisco ASR plugin >> (because it always creates HA routers), some Swift plugins (we don't have >> Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because >> they require special network preparation and extra drivers to be presented >> in an image), when a combination of different ML2 plugins or hypervisors >> deployed (because you need to test all network underlayers or HVs). >> >> So, all that means we need to make OSTF extendible by Fuel plugin's tests >> eventually. >> >> >> >> On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <sgreg...@mirantis.com> >> wrote: >> >>
Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes
we cannot move to just packages. >>> >>> >>>> Regarding flexibility: having several versioned directories with puppet >>>> modules on the master node, having several fuel-libraryX.Y packages >>>> installed on the master node makes things "exquisitely convoluted" rather >>>> than flexible. Like I said, it is flexible enough to use mcollective, plain >>>> rsync, etc. if you really need to do things manually. But we have >>>> convenient service (Perestroika) which builds packages in minutes if you >>>> need. Moreover, In the nearest future (by 8.0) Perestroika will be >>>> available as an application independent from CI. So, what is wrong with >>>> building fuel-library package? What if you want to troubleshoot nova (we >>>> install it using packages)? Should we also use rsync for everything else >>>> like nova, mysql, etc.? >>>> >>>> >>> Yes, we do have a service like Perestroika to build packages for us. >>> That doesn't mean everyone else does or has access to do that today. >>> Setting up a build system is a major undertaking and making that a hard >>> requirement to interact with our product may be a bit much for some >>> customers. In speaking with some support folks, there are times when files >>> have to be munged to get around issues because there is no package or >>> things are on fire so they can't wait for a package to become available for >>> a fix. We need to be careful not to impose limits without proper >>> justification and due diligence. We already build the fuel-library >>> package, so there's no reason you couldn't try switching the rsync to >>> install the package if it's available on a mirror. I just think you're >>> going to run into the issues I mentioned which need to be solved before we >>> could just mark it done. >>> >>> -Alex >>> >>> >>> >>>> Vladimir Kozhukalov >>>> >>>> On Wed, Sep 9, 2015 at 4:39 PM, Alex Schultz <aschu...@mirantis.com> >>>> wrote: >>>> >>>>> I agree that we shouldn't need to sync as we should be able to just >>>>> update the fuel-library package. That being said, I think there might be a >>>>> few issues with this method. The first issue is with plugins and how to >>>>> properly handle the distribution of the plugins as they may also include >>>>> puppet code that needs to be installed on the other nodes for a >>>>> deployment. >>>>> Currently I do not believe we install the plugin packages anywhere except >>>>> the master and when they do get installed there may be some post-install >>>>> actions that are only valid for the master. Another issue is being >>>>> flexible enough to allow for deployment engineers to make custom changes >>>>> for a given environment. Unless we can provide an improved process to >>>>> allow for people to provide in place modifications for an environment, we >>>>> can't do away with the rsync. >>>>> >>>>> If we want to go completely down the package route (and we probably >>>>> should), we need to make sure that all of the other pieces that currently >>>>> go together to make a complete fuel deployment can be updated in the same >>>>> way. >>>>> >>>>> -Alex >>>>> >>>>> >>> >>> __ >>> 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 > > -- 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
Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes
I disagree from the development point of view. Now I just change manifests on Fuel node and redeploy cluster to apply that changes. With your proposal I'll need to build a new package and add it to a repo every time I change something. On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > Currently, we install fuel-libraryX.Y package(s) on the master node and > then right before starting actual deployment we rsync [1] puppet modules > (one of installed versions) from the master node to slave nodes. Such a > flow makes things much more complicated than they could be if we installed > puppet modules on slave nodes as rpm/deb packages. Deployment itself is > parameterized by repo urls (upstream + mos) and this pre-deployment task > could be nothing more than just installing fuel-library package from mos > repo defined for a cluster. We would not have several versions of > fuel-library on the master node, we would not need that complicated upgrade > stuff like we currently have for puppet modules. > > Please give your opinions on this. > > > [1] > https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218 > > 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 > > -- 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
Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes
I don't think juggling with repos and pull requests is easier than direct editing of files on Fuel node. Do we have Perestorika installed on Fuel node in 7.0? On Wed, Sep 9, 2015 at 3:47 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Andrey, > > This change is going to make things even easier. Currently you don't need > to build fuel-library package manually, Perestroika is going to do it for > you. It builds necessary packages during minutes for every review request > and packaging ci even tests it for you. You just need to make necessary > changes not on master node but on your MACBOOK using your favorite editor. > Then you need to commit this change and send this patch on review. If you > want to test this patch manually, you just need to append this CR repo > (example is here [1]) to the list of repos you define for your cluster and > start deployment. Anyway, you still have rsync, mcollective and other old > plain tools to run deployment manually. > > [1] http://perestroika-repo-tst.infra.mirantis.net/review/CR-221719/ > > > > Vladimir Kozhukalov > > On Wed, Sep 9, 2015 at 2:48 PM, Dmitry Pyzhov <dpyz...@mirantis.com> > wrote: > >> Vladimir, >> >> thanks for bringing this up. It greatly correlates with the idea of >> modularity. Everything related to an openstack release should be put in one >> place and should be managed as a solid bundle on the master node. Package >> repository is the first solution that comes to the mind and it looks pretty >> good. Puppet modules, openstack.yaml and maybe even serialisers should be >> stored in packages in the openstack release repository. And eventually >> every other piece of our software should get rid of release-specific logic. >> >> On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov < >> vkozhuka...@mirantis.com> wrote: >> >>> Dear colleagues, >>> >>> Currently, we install fuel-libraryX.Y package(s) on the master node and >>> then right before starting actual deployment we rsync [1] puppet modules >>> (one of installed versions) from the master node to slave nodes. Such a >>> flow makes things much more complicated than they could be if we installed >>> puppet modules on slave nodes as rpm/deb packages. Deployment itself is >>> parameterized by repo urls (upstream + mos) and this pre-deployment task >>> could be nothing more than just installing fuel-library package from mos >>> repo defined for a cluster. We would not have several versions of >>> fuel-library on the master node, we would not need that complicated upgrade >>> stuff like we currently have for puppet modules. >>> >>> Please give your opinions on this. >>> >>> >>> [1] >>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218 >>> >>> 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 > > -- 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
Re: [openstack-dev] [Fuel][Plugins] add health check for plugins
Hi. Sorry for bringing this thread back from the grave but it look quite interesting to me. Sheena, could you please explain how pre-deployment sanity checks should look like? I don't get what it is. >From the Health Check point of view plugins may be divided to two groups: 1) A plugin that doesn't change an already covered functionality thus doesn't require extra tests implemented. Such plugins may be Contrail and almost all SDN plugins, Glance or Cinder backend plugins, and others which don't bring any changes in OSt API or any extra OSt components. 2) A plugin that adds new elements into OSt or changes API or a standard behavior. Such plugins may be Contrail (because it actually adds Contrail Controller which may be covered by Health Check too), Cisco ASR plugin (because it always creates HA routers), some Swift plugins (we don't have Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because they require special network preparation and extra drivers to be presented in an image), when a combination of different ML2 plugins or hypervisors deployed (because you need to test all network underlayers or HVs). So, all that means we need to make OSTF extendible by Fuel plugin's tests eventually. On Mon, Aug 10, 2015 at 5:17 PM, Sheena Gregson <sgreg...@mirantis.com> wrote: > I like that idea a lot – I also think there would be value in adding > pre-deployment sanity checks that could be called from the Health Check > screen prior to deployment. Thoughts? > > > > *From:* Simon Pasquier [mailto:spasqu...@mirantis.com] > *Sent:* Monday, August 10, 2015 9:00 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for > plugins > > > > Hello Samuel, > > This looks like an interesting idea. Do you have any concrete example to > illustrate your point (with one of your plugins maybe)? > > BR, > > Simon > > > > On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel < > samuel.bartel@gmail.com> wrote: > > Hi all, > > > > actually with fuel plugins there are test for the plugins used by the > CICD, but after a deployment it is not possible for the user to easily test > if a plugin is crrectly deploy or not. > > I am wondering if it could be interesting to improve the fuel plugin > framework in order to be able to define test for each plugin which would ba > dded to the health Check. the user would be able to test the plugin when > testing the deployment test. > > > > What do you think about that? > > > > > > Kind regards > > > > Samuel > > > __ > 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
Re: [openstack-dev] [Fuel] Number of IP addresses in a public network
+1 to Igor. It's definitely not a High bug. The biggest problem I see here is a confusing error message with a wrong number of required IPs. AFAIU we cannot fix it easily now so let's postpone it to 8.0 but change a message itself [0] in 7.0. [0] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/task/task.py#L1160-L1163 On Tue, Sep 1, 2015 at 1:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Hello, > > My 5 cents on it. > > I don't think it's really a High or Critical bug for 7.0. If there's > not enough IPs the CheckBeforeDeploymentTask will fail. And that's > actually Ok, it may fail by different reason without starting actual > deployment (sending message to Astute). > > But I agree it's kinda strange that we don't check IPs during network > verification step. The good fix in my opinion is to move this check > into network checker (perhaps keep it here either), but that > definitely shouldn't be done in 7.0. > > Thanks, > Igor > > > On Mon, Aug 31, 2015 at 2:54 PM, Roman Prykhodchenko <m...@romcheg.me> > wrote: > > Hi folks! > > > > Recently a problem that network check does not tell whether there’s > enough IP addresses in a public network [1] was reported. That check is > performed by CheckBeforeDeployment task, but there is two problems that > happen because this verification is done that late: > > > > - A deployment fails, if there’s not enough addresses in specified > ranges > > - If a user wants to get network configuration they will get an error > > > > The solution for this problems seems to be easy and a straightforward > patch [2] was proposed. However, there is a hidden problem which is that > patch does not address which is that installed plugins may reserve VIPs for > their needs. The issue is that they do it just before deployment and so > it’s not possible to get those reservations when a user wants to check > their network set up. > > > > The important issue we have to address here is that network > configuration generator will fail, if specified ranges don’t fit all VIPs. > There were several proposals to fix that, I’d like to highlight two of them: > > > > a) Allow VIPs to not have an IP address assigned, if network config > generator works for API output. > > That will prevent GET requests from failure, but since IP addresses > for VIPs are required, generator will have to fail, if it generates a > configuration for the orchestrator. > > b) Add a release note that users have to calculate IP addresses > manually and put sane ranges in order to not shoot their own legs. Then > it’s also possible to change network verification output to remind users to > check the ranges before starting a deployment. > > > > In my opinion we cannot follow (a) because it only masks a problem > instead of providing a fix. Also it requires to change the API which is not > a good thing to do after the SCF. If we choose (b), then we can work on a > firm solution in 8.0 and fix the problem for real. > > > > > > P. S. We can still merge [2], because it checks, if IP ranges can at > least fit the basic configuration. If you agree, I will update it soon. > > > > [1] https://bugs.launchpad.net/fuel/+bug/1487996 > > [2] https://review.openstack.org/#/c/217267/ > > > > > > > > - 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 > > > > __ > 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
Re: [openstack-dev] [Fuel] How much do we rely on dnsmasq?
My biggest concern is about 4to6 translations. I would prefer to avoid them as longer as it possible. From my point of view pure ipv6 is easier to implement than dual stack. I see it like when you install Fuel node you decide once and forever what IP version you are go with. We will have two implementations of Fuel - v4 and v6 - and then will try to merge them together. Another option may be if PXE, management, and storage networks are still v4, but OSt API endpoints and Neutron are configured to use IPv6. But some problems may hide there. On Fri, Aug 28, 2015 at 9:07 PM, Sean M. Collins s...@coreitpro.com wrote: On Thu, Aug 27, 2015 at 08:27:24PM EDT, Andrey Danin wrote: Hi, Sean, Dnsmasq is managed by Cobbler. Cobbler may also manage isc-dhcpd + BIND [0]. Great - thanks for the link. So, switching from dnsmasq requires 2 more services been installed. I think it's not a big deal to a update Cobbler container. The most work will be in adding ipv6 support into everything: fuelmenu, Nailgun/UI, a lot of Puppet modules, especially L23network module, OSTF. Also, it doubles QA efforts. Thanks - I agree there is a lot of places we'll have to cover. Other questions come up. Do we want to support dual stack too? When a user will choose an IP version: once during master node installation or it'll be allowed to switch over in any moment? I think probably in the first iteration it'll be dualstack, since we'll mostly just be working on enabling IPv6 in all the components. Stretch goal will be for Fuel to not require IPv4 at all so that in the future we can deploy it in IPv6 only environments. -- Sean M. Collins __ 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
Re: [openstack-dev] [Fuel] How much do we rely on dnsmasq?
Hi, Sean, Dnsmasq is managed by Cobbler. Cobbler may also manage isc-dhcpd + BIND [0]. So, switching from dnsmasq requires 2 more services been installed. I think it's not a big deal to a update Cobbler container. The most work will be in adding ipv6 support into everything: fuelmenu, Nailgun/UI, a lot of Puppet modules, especially L23network module, OSTF. Also, it doubles QA efforts. Other questions come up. Do we want to support dual stack too? When a user will choose an IP version: once during master node installation or it'll be allowed to switch over in any moment? [0] http://cobbler.github.io/manuals/2.6.0/3/4/2_-_Managing_DNS.html On Thu, Aug 27, 2015 at 10:06 PM, Sean M. Collins s...@coreitpro.com wrote: Hi, I wanted to ask if we have any opinions on dnsmasq, since I am doing some hacking on adding IPv6 support to fuel, for the provisioning stage. https://review.openstack.org/#/c/216787/ Depending on if dnsmasq supports DHCPv6 options for PXE booting, we may need to investigate replacing it with isc-dhcpd. Which is no small task, I can imagine. The spec review has links to a post I made on the dnsmasq mailing list to see if there is anyone there that can answer my question. -- Sean M. Collins __ 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
I apologize for my hasty email earlier. Thank you all who tried to help me but I have to revoke my additions to this feature. I completely missed the fact that labels may be changed after the deployment is done. It creates inconsistency between label values and actual values in astute.yaml on the nodes. It's bad UX and it may break a cluster in some circumstances. Merging my code we just add a new tech dept into Fuel and it's not we want to do. So, thank you again, and I'll come up later with a better proposal for 8.0. On Fri, Jul 24, 2015 at 11:49 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Fuelers, I'm ok to go with CLI part of this story. It's already implemented and was actively reviewed yesterday. As for labels serialisation to astute.yaml.. I don't know it seems pretty easy to implement, but we must be strict and do not accept any exceptions because it's easy to implement. Otherwise, we'll start to accept exceptions for all small changes and the story of 6.1 will happened again. Thanks, Igor On Fri, Jul 24, 2015 at 8:58 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: This feature is of a High priority, not Essential [1] We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have
Re: [openstack-dev] [Fuel] version.yaml in the context of packages
__ 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
Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main
+1 On Fri, Jul 24, 2015 at 2:00 AM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: +1 2015-07-24 1:56 GMT+03:00 Sergey Vasilenko svasile...@mirantis.com: +1 __ 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 -- 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
/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 __ 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
Re: [openstack-dev] [Fuel][Plugins] differenciate node with the same role
Hi, Samuel, We use magic words in node names for Fuel Contrail plugin. It uses the bare role to deploy Contrail controllers. Unfortunately, we don't have node tags in 6.1, but we are going to implement custom roles from a plugin in 7.0. Please see a spec https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin On Wednesday, June 24, 2015, Samuel Bartel samuel.bartel@gmail.com wrote: Hi folks I am wondering if it is possible to differenciate nodes within a same role. Is it possible for example to apply aplugin to a compute node A but not a compute node B? It will be more clear with examples : 1) for the nfs plugin I want to use nfs storage backend for compute node A but LVM for compute node B 2) I was thinking of a plugin to define Availability zone and setup compute node A and B in AZ1 and compute node C in AZ2 I think it would possible to check according to specific value in the name of the node. But it doesn't seems to me to be very clean. And if we hav many plugins built in that way, name of the node would become very complicated soon and it is not very flexible. I was more looking a way to put a tag in the node (without needed to manually edit deployement yaml files) Anyone has already done something like this or has a tips on that topic? regards Samuel -- 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
Re: [openstack-dev] [Fuel] vxlan support
Hi, Sean, A plugin cannot modify Fuel UI but it actually can change a segmentation type after deployment. On UI it's still GRE but in fact it will be VxLAN. I know, it's ugly, but should work. On Thu, May 28, 2015 at 7:47 PM, Sean M. Collins s...@coreitpro.com wrote: VxLAN support cannot be made as a plugin because plugins cannot modify the initial networking wizard (based on conversations I've had in #fuel-dev) where the choices between Neutron VLAN, Neutron GRE, and nova-network are shown to the user. I am currently working on this blueprint and have a WIP patch for fuel-web. Please contact me if you want to help contribute to the work. -- Sean M. Collins __ 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
Re: [openstack-dev] [Fuel] Infiniband support in Fuel
Hi, Sylwester, Fuel-plugin-mellanox is in development stage now, so no one can use it. I think, a longer MAC field may be helpful for other plugin developers in future. On Tue, Apr 28, 2015 at 12:50 AM, Sylwester Brzeczkowski sbrzeczkow...@mirantis.com wrote: We have a bug in fuel [1] which concerns infiniband support. It's mostly about expanding the size of mac field in db from 17 to 59. But I've email Aviram Bar-Haim who was working on for infiniband support [2] for fuel-plugin-mellanox [3] and he said that they use eIPoIB mac (mapping between ETH to IB) instead of IB Guid so it fits to our current mac field size. Does anyone have ever used fuel-plugin-mellanox with IB? I'm trying to find out if the bug is still valid? [1] https://bugs.launchpad.net/fuel/+bug/1398882 [2] https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/db/sqlalchemy/models/node.py#L103 [3] https://github.com/stackforge/fuel-plugin-mellanox Regards -- *Sylwester Brzeczkowski* Junior Python Software Engineer Product Development-Core : Product Engineering __ 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
[openstack-dev] [Fuel] [plugins] A simple network to interface mapping in astute.yaml
Hi, fuelers, As you may know, we have a rich and complex network_transformations section in astute.yaml. We use it to describe which OVS/Linux network primitives should be created and how they should be connected together. This section is used by l23network Puppet module during the deployment stage. The problem is that from plugin developer's stand point it's hard to parse a full transformation graph to find which interface/vlan is used for each network (Public, Private, etc.). I see two ways to fix that. 1) Add a new structure to astute.yaml with a simple mapping of networks to interfaces/vlans. Example: http://paste.openstack.org/show/181466/ (see roles_meta section). Pros: it's very easy for plugin developers. Cons: there are two sources of truth (roles_meta and transformations). If one plugin patch transformations but forget to patch roles_meta, another plugin, which relies on roles_meta, fails the deployment. 2) Provide a some kind of SDK - functions/libraries for Puppet/Python/Bash, which can be used in plugin's tasks to operate with graph of transformations. Pros: single point of truth. One and controlled way to do things right. Cons: a new piece of software will be issued. It must be written, tested, documented, and incorporated into CI/CD infrastructure. I prefer the second way. Do you? -- 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
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
...@mirantis.com javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com'); wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com www.mirantis.ru vkuk...@mirantis.com javascript:_e(%7B%7D,'cvml','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 -- Andrew 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: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 Mirantis Fuel community ambassador Ceph community -- 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
Re: [openstack-dev] [fuel] [vmware] Two hypervisors in one cloud
I agree. But, as far as I know [2], there should be a some kind of ML2 integration layer for each plugin, and it should be in Neutron code base (see [1] for example). There is no vDS ML2 driver in Neutron at all and FF will become soon. So, it seems we cannot manage to adjust a blueprint spec [3], make it approved, refactor a code of the driver and provide a 3rd party CI for that in such a short period before FF. [1] thin Mellanox ML2 driver https://review.openstack.org/#/c/148614/ [2] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/core-vendor-decomposition.html [3] https://blueprints.launchpad.net/neutron/+spec/ml2-dvs-mech-driver On Sat, Jan 24, 2015 at 12:45 AM, Kevin Benton blak...@gmail.com wrote: It's worth noting that all Neutron ML2 drivers are required to move to their own repos starting in Kilo so installing an extra python package to use a driver will become part of the standard Neutron installation workflow. So I would suggest creating a stackforge project for the vDS driver and packaging it up. On Fri, Jan 23, 2015 at 11:39 AM, Andrey Danin ada...@mirantis.com wrote: Hi, all, As you may know, Fuel 6.0 has an ability to deploy either a KVM-oriented environment or a VMware vCenter-oriented environment. We wants to go further and mix them together. A user should be able to run both hypervisors in one OpenStack environment. We want to get it in Fuel 6.1. Here is how we gonna do this. * When vCenter is used as a hypervisor the only way to use volumes with it is to use Cinder VMDK backend. And vise versa, KVM cannot operate with the volumes provided by Cinder VMDK backend. All that means that we should have two separe infrastructures (a hypervisor + a volume service) for each HV presented in environment. To do that we decided to place corresponding nova-compute and cinder-volume instances into different Availability Zones. Also we want to disable 'cross_az_attach' option in nova.conf to restrict a user to mount a volume to an instance which doesn't support this volume type. * A cinder-volume service is just a proxy between vCenter Datastore and Glance when used with VMDK. It means that the service itself doesn't need a local hard drive but sometimes can significantly consume network. That's why it's not a good idea to always put it to a Controller node. So, we want to add a new role called 'cinder-vmdk'. A user will be able to put this role to whatever node he wants: a separate node or combine with other roles. HA will be achieved by placing the role on two or more nodes. Cinder-volume services on each node will be configured identicaly, including 'host' stanza. We have the same approach now for Cinder+Ceph. * Nova-compute services for vCenter are kept running on Controller nodes. They are managed by Corosync. * There are two options for network backend exist. A good old Nova-network and a modern Neutron with ML2 DVS driver enabled. The problem with Nova-network is that we have to run it in 'singlehost' mode. It means, that the only nova-network service will be running for the whole environment. It makes the service a single point of failure, prevents a user to use Security Groups, and increases a network consuming for the node where the service is running. The problem with Neutron is that there is no ML2 DVS driver in an upstream Neutron for Juno and even Kilo. The is an unmerged patch [1] with almost no chances to get in Kilo. Good news are that we managed to run a PoC lab with this driver and both HVs enabled. So, we can build the driver as a package but it'll be a little ugly. That's why we picked the Nova-network approach as a basis. In Cluster creation wizard will be something to choose if you want to use vCenter in a cluster or not. Depending on it the nova-network service will be run in the 'singlenode' or 'multinode' mode. May be, if we have enough resources we'll implement a Neutron + vDS support also. * We are going to move all VMWare-specific settings to a separate UI tab. On the Settings tab we will keep a Glance backend switch (Swift, Ceph, VMware) and a libvirt_type switch (KVM, qemu). At the cluster creation wizard there will be a checkbox called 'add a VMware vCenter support into your cloud'. When it's enabled a user can choose nova-network only. * OSTF test suit will be extended to support separate sets of tests for each HV. [1] Neutron ML2 vDS driver https://review.openstack.org/#/c/111227/ Links to blueprints: https://blueprints.launchpad.net/fuel/+spec/vmware-ui-settings https://blueprints.launchpad.net/fuel/+spec/cinder-vmdk-role https://blueprints.launchpad.net/fuel/+spec/vmware-dual-hypervisor I would appreciate to see your thoughts about all that. -- Andrey Danin ada...@mirantis.com skype: gcon.monolake __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ
[openstack-dev] [fuel] [vmware] Two hypervisors in one cloud
Hi, all, As you may know, Fuel 6.0 has an ability to deploy either a KVM-oriented environment or a VMware vCenter-oriented environment. We wants to go further and mix them together. A user should be able to run both hypervisors in one OpenStack environment. We want to get it in Fuel 6.1. Here is how we gonna do this. * When vCenter is used as a hypervisor the only way to use volumes with it is to use Cinder VMDK backend. And vise versa, KVM cannot operate with the volumes provided by Cinder VMDK backend. All that means that we should have two separe infrastructures (a hypervisor + a volume service) for each HV presented in environment. To do that we decided to place corresponding nova-compute and cinder-volume instances into different Availability Zones. Also we want to disable 'cross_az_attach' option in nova.conf to restrict a user to mount a volume to an instance which doesn't support this volume type. * A cinder-volume service is just a proxy between vCenter Datastore and Glance when used with VMDK. It means that the service itself doesn't need a local hard drive but sometimes can significantly consume network. That's why it's not a good idea to always put it to a Controller node. So, we want to add a new role called 'cinder-vmdk'. A user will be able to put this role to whatever node he wants: a separate node or combine with other roles. HA will be achieved by placing the role on two or more nodes. Cinder-volume services on each node will be configured identicaly, including 'host' stanza. We have the same approach now for Cinder+Ceph. * Nova-compute services for vCenter are kept running on Controller nodes. They are managed by Corosync. * There are two options for network backend exist. A good old Nova-network and a modern Neutron with ML2 DVS driver enabled. The problem with Nova-network is that we have to run it in 'singlehost' mode. It means, that the only nova-network service will be running for the whole environment. It makes the service a single point of failure, prevents a user to use Security Groups, and increases a network consuming for the node where the service is running. The problem with Neutron is that there is no ML2 DVS driver in an upstream Neutron for Juno and even Kilo. The is an unmerged patch [1] with almost no chances to get in Kilo. Good news are that we managed to run a PoC lab with this driver and both HVs enabled. So, we can build the driver as a package but it'll be a little ugly. That's why we picked the Nova-network approach as a basis. In Cluster creation wizard will be something to choose if you want to use vCenter in a cluster or not. Depending on it the nova-network service will be run in the 'singlenode' or 'multinode' mode. May be, if we have enough resources we'll implement a Neutron + vDS support also. * We are going to move all VMWare-specific settings to a separate UI tab. On the Settings tab we will keep a Glance backend switch (Swift, Ceph, VMware) and a libvirt_type switch (KVM, qemu). At the cluster creation wizard there will be a checkbox called 'add a VMware vCenter support into your cloud'. When it's enabled a user can choose nova-network only. * OSTF test suit will be extended to support separate sets of tests for each HV. [1] Neutron ML2 vDS driver https://review.openstack.org/#/c/111227/ Links to blueprints: https://blueprints.launchpad.net/fuel/+spec/vmware-ui-settings https://blueprints.launchpad.net/fuel/+spec/cinder-vmdk-role https://blueprints.launchpad.net/fuel/+spec/vmware-dual-hypervisor I would appreciate to see your thoughts about all that. -- 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
Re: [openstack-dev] [Fuel] [Scale] [UI] Improvements to handle 200+ nodes
Definitely, it should be a form-based filter. It's much more simpler than a pure query. Also, you can translate a user selection to a query and add to a location string (like it's done now for the Logs tab [1], for instance). It would allow a user to use a full power of queries. [1] http://demo.fuel-infra.org:8000/#cluster/874/logs/type:local;source:api;level:info On Fri, Jan 16, 2015 at 3:50 PM, Nikolay Markov nmar...@mirantis.com wrote: It's also should be mentioned that these are several changes to do on backend in order for UI to work faster, not on UI itself. For example, these are: - Custom filters, as Vitaly mentioned - Pagination of collections - PATCH requests support - Probably both short and /full representations for some entities On Fri, Jan 16, 2015 at 8:48 AM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, Currently Fuel UI can handle large amounts of nodes due to a recent refactoring - rendering and operations with nodes became much faster. But that large amount of nodes also requires UX improvement, I'd love to hear your ideas and opinions on these proposals: Introduce compact node representation and let users switch between standart and compact view. Compact view will display only node name and status and will allow to display 4-8 nodes in a row instead of only one. Currently it is only possible to filter node by names. Filtering feature could be extended to allow filtering by other parameters: status, roles, manufacturer, RAM, disk space. There are 2 options (I'd like to hear which one you prefer): Form-based filter (beside a single input for name there will be controls for other parameters) Query language-based filter (like one used in Gerrit) Add ability to add arbitrary tags with values to nodes and also allow filtering by them. -- Vitaly Kramskikh, 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 -- Best regards, Nick Markov __ 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
Re: [openstack-dev] [Fuel] Empty role - status
Answers inline. On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com wrote: Hi, Empty role is ready [1], thanks to granular deployment feature I didn't have to hardcode some hacks in Astute again. But there are several things which I want to mention/discuss: 1. in the patch you can see the name of the role and its description I would like to ask you to verify it and provide some other options if you have any 2. we have a minor problem with the progress bar, we will figure out how to fix it in Astute with Vladimir S. 3. and the biggest problem is an old bug [2], the bug is Ubuntu specific and it doesn't allow us to make efficient partitioning schema, e.g. it means that we cannot allocate root partition for all of the disks (provisioning will fail), the current workaround is to allocate root partition with minimal size (about 15G) and leave the rest of the space as is (unallocated). As far as I can see from the bug it's not so easy to fix the problem, actually image based provisioning fixes the problem, but it's not an option for the current release. Maybe you have some other ideas how to fix this problem? I would leave it as is - 15 GB. A user or plugin can adjust it for its needs. Thanks, [1] https://review.openstack.org/#/c/147230/ [2] https://bugs.launchpad.net/fuel/+bug/1278964 __ 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
Re: [openstack-dev] [Fuel] Adding code to add node to fuel UI
It's enough for you to just create a new role in openstack.yaml and maybe
some descriptions in UI components.
Then you should capture this role in Puppet manifests. Look at the 'case'
operator [1]. Just add a new case for your role and call your 'vim' class
here.
[1]
https://github.com/stackforge/fuel-library/blob/master/deployment/puppet/osnailyfacter/manifests/cluster_simple.pp#L227
On Thu, Dec 18, 2014 at 10:03 PM, Satyasanjibani Rautaray
engg.s...@gmail.com wrote:
Hi Mike
this Document helped a lot
I may be missing something thing for which i need some help below is the
details for which i require some help.
i have a vim.pp file for testing which will install vim on the particular
node which is not a part of controller or compute or any openstack
component nodes
The current zabbix-server under the manager.py did something as below
snip
from nailgun.utils.zabbix import ZabbixManager
@classmethod
def get_zabbix_url(cls, cluster):
zabbix_node = ZabbixManager.get_zabbix_node(cluster)
if zabbix_node is None:
return None
ip_cidr = cls.get_node_network_by_netname(
zabbix_node, 'public'
)['ip']
ip = ip_cidr.split('/')[0]
return 'http://{0}/zabbix'.format(ip)
/snip
at receiver.py
snip
zabbix_url = objects.Cluster.get_network_manager(
task.cluster
).get_zabbix_url(task.cluster)
if zabbix_url:
zabbix_suffix = Access Zabbix dashboard at {0}.format(
zabbix_url
)
message += zabbix_suffix
/snip
at task.py
snip
from nailgun.utils.zabbix import ZabbixManager
# check if there's a zabbix server in an environment
# and if there is, remove hosts
if ZabbixManager.get_zabbix_node(task.cluster):
zabbix_credentials = ZabbixManager.get_zabbix_credentials(
task.cluster
)
logger.debug(Removing nodes %s from zabbix % (nodes_to_delete))
try:
ZabbixManager.remove_from_zabbix(
zabbix_credentials, nodes_to_delete
)
except (errors.CannotMakeZabbixRequest,
errors.ZabbixRequestError) as e:
logger.warning(%s, skipping removing nodes from Zabbix, e)
/snip
and
https://review.openstack.org/#/c/84408/39/nailgun/nailgun/utils/zabbix.py
i am not able to get how can i connect to the vim.pp file
Thanks
Satya
On Wed, Dec 17, 2014 at 7:27 AM, Mike Scherbakov mscherba...@mirantis.com
wrote:
Hi,
did you come across
http://docs.mirantis.com/fuel-dev/develop/addition_examples.html ?
I believe it should cover your use case.
Thanks,
On Tue, Dec 16, 2014 at 11:43 PM, Satyasanjibani Rautaray
engg.s...@gmail.com wrote:
I just need to deploy the node and install my required packages.
On 17-Dec-2014 1:31 am, Andrey Danin ada...@mirantis.com wrote:
Hello.
What version of Fuel do you use? Did you reupload openstack.yaml into
Nailgun? Do you want just to deploy an operating system and configure a
network on a new node?
I would really appreciate if you use a period at the end of sentences.
On Tuesday, December 16, 2014, Satyasanjibani Rautaray
engg.s...@gmail.com wrote:
Hi,
*i am in a process of creating an additional node by editing the code
where the new node will be solving a different propose than installing
openstack components just for testing currently the new node will install
vim for me please help me what else i need to look into to create the
complete setup and deploy with fuel i have edited openstack.yaml at
/root/fuel-web/nailgun/nailgun/fixtures http://pastebin.com/P1MmDBzP
http://pastebin.com/P1MmDBzP*
--
Thanks
Satya
Mob:9844101001
No one is the best by birth, Its his brain/ knowledge which make him
the best.
--
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Mike Scherbakov
#mihgen
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks
Satya
Mob:9844101001
No one is the best by birth, Its his brain/ knowledge which make him the
best.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Andrey Danin
ada...@mirantis.com
skype: gcon.monolake
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Adding code to add node to fuel UI
Hello. What version of Fuel do you use? Did you reupload openstack.yaml into Nailgun? Do you want just to deploy an operating system and configure a network on a new node? I would really appreciate if you use a period at the end of sentences. On Tuesday, December 16, 2014, Satyasanjibani Rautaray engg.s...@gmail.com wrote: Hi, *i am in a process of creating an additional node by editing the code where the new node will be solving a different propose than installing openstack components just for testing currently the new node will install vim for me please help me what else i need to look into to create the complete setup and deploy with fuel i have edited openstack.yaml at /root/fuel-web/nailgun/nailgun/fixtures http://pastebin.com/P1MmDBzP http://pastebin.com/P1MmDBzP* -- Thanks Satya Mob:9844101001 No one is the best by birth, Its his brain/ knowledge which make him the best. -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Image based provisioning
On Tuesday, December 16, 2014, Dmitry Pyzhov dpyz...@mirantis.com wrote: Guys, we are about to enable image based provisioning in our master by default. I'm trying to figure out requirement for this change. As far as I know, it was not tested on scale lab. Is it true? Have we ever run full system tests cycle with this option? Do we have any other pre-requirements? -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Image based provisioning
Adding Mellanox team explicitly. Gil, Nurit, Aviram, can you confirm that you tested that feature? It can be enabled on every fresh ISO. You just need to enable the Experimental mode (please, see the documentation for instructions). On Tuesday, December 16, 2014, Dmitry Pyzhov dpyz...@mirantis.com wrote: Guys, we are about to enable image based provisioning in our master by default. I'm trying to figure out requirement for this change. As far as I know, it was not tested on scale lab. Is it true? Have we ever run full system tests cycle with this option? Do we have any other pre-requirements? -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] NTP settings.
Yes, it does. On Sat, Nov 15, 2014 at 3:15 AM, Rick Jones rick.jon...@hp.com wrote: On 11/14/2014 04:01 PM, Dmitry Borodaenko wrote: If NTP server is not reachable on the first boot of the master node, it should be disabled by bootstrap_admin_node, that eliminates the possibility of it spontaneously coming to life and changing the clock for fuel master node and all target nodes in the middle of a deployment. Then all Nailgun needs to do is pop a warning notification that no NTP server is configured on the master node, and it should be fixed manually before starting any deployments. No need to block deployment altogether: if the user doesn't need need global time at all (e.g. in an off-the-grid bunker 2 miles beneath Fort Knox), synchronizing clocks on all environments just to the Fuel master will still work. I thought NTP (well ntpd) had an option to tell it to only ever slew the clock, never step it? Or is that only some implementations of NTP? rick jones ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Support for plugins in fuel client
Cool. I have no objections. On Jun 25, 2014 9:27 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: As i mentioned cliff uses similar approach, extending app by means of entry points, and written by same author. So i think stevedore will be used in cliff, or maybe already used in newer versions. But apart of stevedore-like dynamic extensions - cliff provides modular layers for cli app, it is kindof framework for wrtiting cli applications. On Tue, Jun 24, 2014 at 11:15 PM, Andrey Danin ada...@mirantis.com wrote: Why not to use stevedore? On Wed, Jun 18, 2014 at 1:42 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi guys, Actually, I'm not a fun of cliff, but I think it's a good solution to use it in our fuel client. Here some pros: * pluggable design: we can encapsulate entire command logic in separate plugin file * builtin output formatters: we no need to implement various formatters to represent received data * interactive mode: cliff makes possible to provide a shell mode, just like psql do Well, I vote to use cliff inside fuel client. Yeah, I know, we need to rewrite a lot of code, but we can do it step-by-step. - Igor On Wed, Jun 18, 2014 at 9:14 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi folks, I am wondering what our story/vision for plugins in fuel client [1]? We can benefit from using cliff [2] as framework for fuel cli, apart from common code for building cli applications on top of argparse, it provides nice feature that allows to dynamicly add actions by means of entry points (stevedore-like). So we will be able to add new actions for fuel client simply by installing separate packages with correct entry points. Afaik stevedore is not used there, but i think it will be - cause of same author and maintainer. Do we need this? Maybe there is other options? Thanks [1] https://github.com/stackforge/fuel-web/tree/master/fuelclient [2] https://github.com/openstack/cliff ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Removing old node logs
When nailgun remove a node it can gzip all the logs of this node to a special file, like: /var/log/remote/archive/node-3-timestamp.tgz And logrotate can keep these files for month, then delete them. Master node health monitor is another big discussion. On Thu, Jun 26, 2014 at 1:25 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Making diagnostic snapshot for a particular environment is a good idea. But the issue is still there. We often have the situation when user actually doesn't care of old logs at all. He downloads ISO, installs it and tries various installation options (Ubuntu, Centos, HA, Ceph, etc.). Sooner or later his hard drive is full and he even can not make the diagnostic snapshot. Dealing with that stuff about taking care of available free space inside shotgun seems to be not a good idea. But we still need to address this. The easiest way to do that is to delete old log directories (logrotate or nailgun itself). In this case the issue at least will be rather seldom. But, of course, the right way is to have a kind of monitoring system on the master node and notify user when disk is full or launch a kind of cleaning task. Ok, right place where we should deal with that stuff about removing old logs is logrotate. Currently it just moves files like this /var/log/remote/old-node.example.com/some.log - /var/log/remote/ old-node.example.com/some.log.1.gz. But what it actually should do is to remove the whole directories which are related to nonexistent nodes, right? Vladimir Kozhukalov On Tue, Jun 24, 2014 at 9:19 PM, Andrey Danin ada...@mirantis.com wrote: +1 to @Aleksandr On Tue, Jun 24, 2014 at 8:32 PM, Aleksandr Didenko adide...@mirantis.com wrote: Yes, of course, snapshot for all nodes at once (like currently) should also be available. On Tue, Jun 24, 2014 at 7:27 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hello, @Aleks, it's a good idea to make snapshot per environment, but I think we can keep functionality to make snapshot for all nodes at once too. - Igor On Tue, Jun 24, 2014 at 6:38 PM, Aleksandr Didenko adide...@mirantis.com wrote: Yeah, I thought about diagnostic snapshot too. Maybe it would be better to implement per-environment diagnostic snapshots? I.e. add diagnostic snapshot generate/download buttons/links in the environment actions tab. Such snapshot would contain info/logs about Fuel master node and nodes assigned to the environment only. On Tue, Jun 24, 2014 at 6:27 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi guys, What about our diagnostic snapshot? I mean we're going to make snapshot of entire /var/log and obviously this old logs will be included in snapshot. Should we skip theem or such situation is ok? - Igor On Tue, Jun 24, 2014 at 5:57 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, If user runs some experiments with creating/deleting clusters, then taking care of old logs is under user's responsibility, I suppose. Fuel configures log rotation with compression for remote logs, so old logs will be gzipped and will not take much space. In case of additional boolean parameter, the default value should be 0-don't touch old logs. -- Regards, Alex On Tue, Jun 24, 2014 at 4:07 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Guys, What do you think of removing node logs on master node right after removing node from cluster? The issue is when user do experiments he creates and deletes clusters and old unused directories remain and take disk space. On the other hand, it is not so hard to imaging the situation when user would like to be able to take a look in old logs. My suggestion here is to add a boolean parameter into settings which will manage this piece of logic (1-remove old logs, 0-don't touch old logs). Thanks for your opinions. Vladimir Kozhukalov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo
Re: [openstack-dev] [Fuel] Removing old node logs
What about to gzip old logs by Astute and place them to a special directory, which will be managed under logrotate.d, and logrotate will remove untouched logs after 1 month. On Tue, Jun 24, 2014 at 6:57 PM, Aleksandr Didenko adide...@mirantis.com wrote: Hi, If user runs some experiments with creating/deleting clusters, then taking care of old logs is under user's responsibility, I suppose. Fuel configures log rotation with compression for remote logs, so old logs will be gzipped and will not take much space. In case of additional boolean parameter, the default value should be 0-don't touch old logs. -- Regards, Alex On Tue, Jun 24, 2014 at 4:07 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Guys, What do you think of removing node logs on master node right after removing node from cluster? The issue is when user do experiments he creates and deletes clusters and old unused directories remain and take disk space. On the other hand, it is not so hard to imaging the situation when user would like to be able to take a look in old logs. My suggestion here is to add a boolean parameter into settings which will manage this piece of logic (1-remove old logs, 0-don't touch old logs). Thanks for your opinions. Vladimir Kozhukalov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Support for plugins in fuel client
Why not to use stevedore? On Wed, Jun 18, 2014 at 1:42 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi guys, Actually, I'm not a fun of cliff, but I think it's a good solution to use it in our fuel client. Here some pros: * pluggable design: we can encapsulate entire command logic in separate plugin file * builtin output formatters: we no need to implement various formatters to represent received data * interactive mode: cliff makes possible to provide a shell mode, just like psql do Well, I vote to use cliff inside fuel client. Yeah, I know, we need to rewrite a lot of code, but we can do it step-by-step. - Igor On Wed, Jun 18, 2014 at 9:14 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Hi folks, I am wondering what our story/vision for plugins in fuel client [1]? We can benefit from using cliff [2] as framework for fuel cli, apart from common code for building cli applications on top of argparse, it provides nice feature that allows to dynamicly add actions by means of entry points (stevedore-like). So we will be able to add new actions for fuel client simply by installing separate packages with correct entry points. Afaik stevedore is not used there, but i think it will be - cause of same author and maintainer. Do we need this? Maybe there is other options? Thanks [1] https://github.com/stackforge/fuel-web/tree/master/fuelclient [2] https://github.com/openstack/cliff ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] OpenStack patching and FUEL upgrade follow-up meeting minutes
I think, Vladimir means, that we need to improve our scheduling of the CI jobs over available CI resources. As I know, now we have a dedicated server groups for separate tests and we cannot use free resources of other server groups in case of overbalanced load. On Thu, Jun 5, 2014 at 6:52 PM, Jesse Pretorius jesse.pretor...@gmail.com wrote: On 5 June 2014 16:27, Vladimir Kuklin vkuk...@mirantis.com wrote: 1. We need strict EOS and EOL rules to decide how many maintenance releases there will be for each series or our QA team and infrastructure will not ever be available to digest it. Agreed. Would it not be prudent to keep with the OpenStack support standard - support latest version and the -1 version? 3. We need to clearly specify the restrictions which patching and upgrade process we support: a. New environments can only be deployed with the latest version of OpenStack and FUEL Library supported b. Old environments can only be updated within the only minor release (e.g. 5.0.1-5.0.2 is allowed, 5.0.1-5.1 is not) Assuming that the major upgrades will be handled in https://blueprints.launchpad.net/fuel/+spec/upgrade-major-openstack-environment then I agree. If not, then we have a sticking point here. I would agree that this is a good start, but in the medium to long term it is important to be able to upgrade from perhaps the latest minor version of the platform to the next available major version. 4. We have some devops tasks we need to finish to feel more comfortable in the future to make testing of patching much easier: a. we need to finish devops bare metal and distributed enviroments setup to make CI and testing process easier b. we need to implement elastic-recheck like feature to analyze our CI results in order to allow developers to retrigger checks in case of floating bugs c. we need to start using more sophisticated scheduler I find the scheduler statement a curiosity. Can you elaborate? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed
+1 to Mike. Let the user provide actual credentials and use them in place. On Fri, Jun 20, 2014 at 2:01 AM, Mike Scherbakov mscherba...@mirantis.com wrote: I'm in favor of #2. I think users might not want to have their password stored in Fuel Master node. And if so, then it actually means we should not save it when user provides it on HealthCheck tab. On Thu, Jun 19, 2014 at 8:05 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Hi folks, We have a bug https://bugs.launchpad.net/fuel/+bug/1281838 which prevents OSTF from working if user changes a password which was using for the initial installation. I skimmed through the comments and it seems there are 2 viable options: 1. Create a separate user just for OSTF during OpenStack installation 2. Provide a field for a password in UI so user could provide actual password in case it was changed What do you guys think? Which options is better? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] how to install fuel on a esxi vm
Hi, Wang. Could you provide a network topology of your installation (incliding hardware and virtual L2/L3 parts of it)? Also, please, check this instruction http://vbyron.com/blog/deploy-openstack-on-vsphere-with-fuel/ On Thu, Jun 12, 2014 at 8:20 AM, Wang Liming wan...@certusnet.com.cn wrote: hi all: I install openstack with the fuel which version is 5.0 on a vmware esxi vm the network is configed correctly ,but when deployed the openstack all service not install is there any error action ? Best Regards Wang Liming ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Nova][vmware] Multiple vCenter backends support in Fuel
Hi, All. In next Fuel release we want to implement a support of multiple vCenters under one OpenStack. Practically it means that we need to set up multiple instances of Nova-Compute each connected to its own vCenter. In Fuel 5.0 we already have support of one vCenter, but it's implemented by running the Nova-Compute and Nova-Network services on the Controller node. So, we have to decide how we will set up multiple instances of Nova-Compute? And how we can provide an HA for them? I see three way to do that. 1.1 Always use a separate Compute node to run each Nova-Compute/Network pair. 1.2 Run one pair on the Controller node and other pairs on the dedicated Compute nodes. The problem is how to decide which one of vCenters should be conneted to the Controller node's services. Also it's a question about system load of the Controller node. 1.3 Run all the nova-compute/network services on the Controller nodes. Actually, Fuel architecture doesn't allow to set up multiple identical roles to one host but we in this case we can break the restriction. What about HA? 2.1 If we run any services on the Controller nodes we can easily move them under Pacemaker control (we already have it on Controller nodes). 2.2 If we run services on the dedicated Compute nodes we can do no HA, but one can run these Compute nodes inside of vCenter Cluster and provide an HA by vSphere HA feature. 2.3 Also, if we run services on the dedicated Compute nodes we can set up a separate Pacemaker/Corosync cluster between these nodes to handle the Nova-Compute/Network services only. As I know, there is a way to run multiple Nova-Compute instances on one node, but I'm not sure about Nova-Network (Multihosts mode) behaviour in this case. I would really appreciate any your thoughts and suggestions about that. -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Neutron] Networking Discussions last week
://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][TripleO] NIC bonding for OpenStack
Hi Openstackers, We are working on link aggregation support in Fuel. We wonder what are the most desirable types of bonding now in datacenters. We had some issues (see below) with OVS bond in LACP mode, and it turned out that standard Linux bonding (attached to OVS bridges) was a better option in our setup. I want to hear your opinion, guys. What types of bonding do you think are better now in terms of stability and performance, so that we can properly support them for OpenStack installations. Also, we are wondering if there any plans to support bonding in TripleO, and how you guys would like to see it be implemented? What is the general approach for such complex network configurations for TripleO? We would love to extract this piece from Fuel and make it fully independent, so that the larger community can use it and we could work collaboratively on it. Right now it is actually already granular and can be reused in other projects, and implemented as a separated puppet module: https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network . Some links with our design considerations: https://etherpad.openstack.org/p/fuel-bonding-design https://blueprints.launchpad.net/fuel/+spec/nics-bonding-enabled-from-ui https://blueprints.launchpad.net/fuel/+spec/nics-bonding-enabled-from-ui UI mockups: https://drive.google.com/file/d/0Bw6txZ1qvn9CaDdJS0ZUcW1DeDg/edit?usp=sharing Description of the problem with LACP we ran into: https://etherpad.openstack.org/p/LACP_issue Thanks, -- Andrey Danin ada...@mirantis.com skype: gcon.monolake ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
