[openstack-dev] [Fuel] Beta milestone of Fuel 5.1 now available!
Hi All, I¹m thrilled to announce that we¹ve reached the beta milestone for the Fuel Project. This beta release is made available to allow a broad user base to test and evaluate the next minor version of Fuel, but is not recommended for production use at this stage. What¹s New in Fuel 5.1? The primary new features of Fuel 5.1 are: * An upgrade path from 5.0 or 5.0.1 to 5.1 * Automated updating an existing OpenStack environment (e.g. from 2014.1 to 2014.1.1) * * Access control to the Fuel UI and API * * Deployment of the ML2 Open vSwitch plug-in for Neutron * * The Fuel Master Node can be backed-up and restored * * VMWare NSX is supported as a network option for KVM hypervisors * * VMWare vCenter integration supports multiple vCenter clusters * * Mellanox hardware support for ISER SR-IOV based networking * * The Zabbix monitoring solution can be deployed by Fuel (experimental) * * Experimental features can now be explicitly enabled or disabled How you can participate To join us in the beta program, please follow these guidelines: * You can download the latest beta build from the public jenkins repository: * https://fuel-jenkins.mirantis.com/view/ISO/ https://fuel-jenkins.mirantis.com/view/ISO/ * * Look for the latest build that has passed the standard BVT tests. * * You can choose to download the ISO, IMG or Upgrade (UPGD) file by clicking on these links next to the build name. UPGD is for those folks upgrading from Fuel 5.0 or 5.0.1 to 5.1. Download the ISO or IMG if you¹re installing fresh. * For this beta, we¹re making the files available via BitTorrent, so please be sure to have a BitTorrent compatible client to download the files. * Beta documentation for the release is available: * http://docs.mirantis.com/openstack/fuel/master/ http://docs.mirantis.com/openstack/fuel/master/ * If you have questions, want to provide feedback or encounter issues with the beta release, you can contact the community developers in a couple of ways: * IRC at freenode.net: #fuel-dev * * OpenStack developers mailing list http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev : Obviously, if you¹re receiving this message, you¹re already signed up but if you want to forward this info to someone else, just let them know to sign up for this openstack-dev mailing list and send E-mails with the subject starting with [Fuel]. * If you find a reproducible bug, you can log it on Launchpad here: * https://bugs.launchpad.net/fuel https://bugs.launchpad.net/fuel * * Please be sure to run the Diagnostic Snapshot to collect the logs and configuration files needed by our dev team to troubleshoot the issue. We welcome any and all levels of participation in this Beta and we look forward to making this release of Fuel the best ever! Thanks, - David J. Easter Director of Product Management, Mirantis, Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Enable SSL between client and API exposed via public URL with HAProxy
Hi Adam, Just to clarify the subtlety of this change - you can still install a single controller, but that controller will be ³HA-ready² by deploying all the projects needed for HA onto that controller. In other words, Fuel will still be able to support smaller deployments along side larger ones for those who only need one controller and a few compute nodes. This also enables an environment to grow overtime without redeployment. Since everything is in place for HA, adding another controller just extends that HA (and removes the single-controller single-point-of-failure). - David J. Easter Director of Product Management, Mirantis, Inc. http://openstacksv.com/ From: Adam Lawson alaw...@aqorn.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, August 21, 2014 at 12:11 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel] Enable SSL between client and API exposed via public URL with HAProxy IMHO, removing non-HA mode in Fuel would be a mistake as Fuel is also used for smaller deployments. HA is required for Production sure but removing support for smaller deployments would drive consumers of smaller clouds elsewhere for orchestration. Maintaining support for smaller clouds probably isn't a priority for Mirantis but I think it should be a priority for the general community consumer base. This also goes for all of the orchestrators out there whether it's SUSE, Juju, Piston, Nebulous, etc etc. Just my two cents. Adam Lawson AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Thu, Aug 21, 2014 at 7:24 AM, Guillaume Thouvenin thouv...@gmail.com wrote: On Thu, Aug 21, 2014 at 5:02 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Guillaume, do I understand right that without implementation of https://blueprints.launchpad.net/fuel/+spec/ca-deployment, SSL support will not be fully automated? And, consequently, we can not call it as complete production ready feature for Fuel users? Yes you are right. Without the implementation of the CA deployment we can not consider it as ready to use. To test my deployment I manually copy a self-signed certificate on all controllers on a predefined location according to what I have in the puppet manifest. So it's really just for testing. I also write a small puppet manifest to generate a self signed certificate to deploy it automatically but it works only for one controller so this solution is also only for testing. So to have the feature ready for production we need to manage certificate maybe as a new option into the fuel dashboard. Best Regards, Guillaume ___ 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] [OSTF] OSTF stops working after password is changed
I think showing this only upon failure is good if the user is also given the option to sore the credentials in the browser. That way, you only have to re-enter the credentials once if you want convenience, or do it every time if you want improved security. One downside would be that if you don¹t cache the credentials, you¹ll have to ³fail² the auth every time to be given the chance to re-enter the credentials. It may not be obvious that clicking ³run tests² will then let you enter new credentials. I was thinking that having a button you can press to enter the credentials would make it more obvious, but wouldn¹t reduce the number of clicks I.e. either run tests and fail or click ³Enter credentials² and enter new ones. The ³Enter credential² option would obviously be a little faster - David J. Easter Director of Product Management, Mirantis, Inc. From: Mike Scherbakov mscherba...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Friday, July 11, 2014 at 2:36 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel] [OSTF] OSTF stops working after password is changed I'm wondering if we can show all these windows ONLY if there is authz failure with existing credentials from Nailgun. So the flow would be: user clicks on Run tests button, healthcheck tries to access OpenStack and fails. It shows up text fields to enter tenant/user/pass with the message similar to Default administrative credentials to OpenStack were changed since the deployment time. Please provide current credentials so HealthCheck can access OpenStack and run verification tests. I think it should be more obvious this way... Anyone, it must be a choice for a user, if he wants to store creds in a browser. On Fri, Jul 11, 2014 at 8:50 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Hi, In the current implementation we store provided credentials in browser local storage. What's your opinion on that? Maybe we shouldn't store new credentials at all even in browser? So users have to enter them manually every time they want to run OSTF. 2014-06-25 13:47 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com: It is possible to change everything so username, password and tenant fields Also this way we will be able to run tests not only as admin user On Wed, Jun 25, 2014 at 12:29 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Dmitry, Fields or field? Do we need to provide password only or other credentials are needed? 2014-06-25 13:02 GMT+04:00 Dmitriy Shulyak dshul...@mirantis.com: Looks like we will stick to #2 option, as most reliable one. - we have no way to know that openrc is changed, even if some scripts relies on it - ostf should not fail with auth error - we can create ostf user in post-deployment stage, but i heard that some ceilometer tests relied on admin user, also operator may not want to create additional user, for some reasons So, everybody is ok with additional fields on HealthCheck tab? On Fri, Jun 20, 2014 at 8:17 PM, Andrew Woodward xar...@gmail.com wrote: The openrc file has to be up to date for some of the HA scripts to work, we could just source that. On Fri, Jun 20, 2014 at 12:12 AM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: +1 for #2. ~Sergii On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin ada...@mirantis.com wrote: +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 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: Create a separate user just for OSTF during OpenStack installation 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
Re: [openstack-dev] [Fuel-dev] access-control-master-node
The other challenge of utilizing Keystone is which one to use. Fuel enables the deployment of multiple cloud environments from one UI; so when accessing the Fuel Master Node, it would be ambiguous which already deployed Keystone to contact for authentication. If/When Triple-O is utilized, one could perhaps see designating the Keystone of the undercloud; but that¹s more a future requirement. For now, I¹d suggest an internal authentication in the immediate short term. External auth sources can be added in future milestones most likely an LDAP source that¹s outside the deployed clouds and designated by IT. Thanks, - David J. Easter Director of Product Management, Mirantis From: Jesse Pretorius jesse.pretor...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, May 27, 2014 at 7:43 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel-dev] access-control-master-node On 27 May 2014 13:42, Lukasz Oles lo...@mirantis.com wrote: Hello fuelers, we(I and Kamil) would like start discussion about Enforce access control for Fuel UI blueprint https://blueprints.launchpad.net/fuel/+spec/access-control-master-node. First question to David, as he proposed this bp. Do you want to add more requirements? To all. What do you think about using keystone as authorization tool? We described all pros/cons in the specification. I would suggest both an internal authentication database and the option of plugging additional options in, with keystone being one of them and perhaps something like oauth being another. Keystone may not be available at the time of the build, or accessible from the network that's used for the initial build. ___ 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] [fuel-dev] [Fuel] Fuel Project 4.1 milestone reached!
Hi All, Just wanted to let everyone know that the Fuel Project met it¹s 4.1 milestone on Monday March 7th. This latest version includes (among other things): * Support for the OpenStack Havana 2013.2.2 https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.2 release. * Ability to stop a deployment before completion * Ability to reset an environment back to pre-deployment state without losing original configuration settings * NIC Bonding configuration in the Fuel UI * Ceph acting as a backend for ephemeral volumes is no longer experimental * The Ceilometer section within Horizon is now enabled by default * Multiple network roles can share a single physical NIC * Hundreds of defect fixes Please feel free to visit https://launchpad.net/fuel/4.x/4.1 to view the blueprints implemented and defects fixed. Thanks to everyone in the community who contributed to hitting this milestone! - David J. Easter Product Line Manager, Mirantis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel-dev] monitoring openstack services with nagios
Thanks for sharing this, Federico. Nagios was removed from the Fuel project in an earlier release so nice to see it back as an option. - David J. Easter Product Line Manager On 1/21/14, 4:43 PM, Federico Michele Facca federico.fa...@create-net.org wrote: Hi, for whoever may be interested for the version 3.2.1 of Fuel we documented a process to extend the set-up of fuel and related puppet scripts to deploy nagios services and use nagios to monitor ³openstack² infrastructure status. We are working out also and iso (but will include also other internal project specific tools - so not so much of general interest). https://blog.fi-xifi.eu/extending-fuel-3-2-to-support-nagios-based-monitor ing/ Best Regards, Federico -- Dr. Federico M. Facca CREATE-NET Via alla Cascata 56/D 38123 Povo Trento (Italy) T +39 0461 408400 (1669) F +39 0461 421157 M +39 334 6049758 E federico.fa...@create-net.org W www.create-net.org ___ 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] [Fuel] Fuel project 4.0 has reached its GA milestone
Hi All, Just a quick note to let folks know that the Fuel project https://launchpad.net/fuel has reached its 4.0 GA milestone. This version of Fuel has been updated to deploy Havana 2013.2.1 https://wiki.openstack.org/wiki/ReleaseNotes/2013.2.1 including OpenStack Orchestration (Heat) and optionally OpenStack Telemetry (Ceilometer). It also deploys the newest version of the Murano project https://wiki.openstack.org/wiki/Murano . Just a few of the other changes made include: * The Puppet Master server has been removed from the Fuel Master Node. Puppet modules and manifests are now synchronized between the master node and the managed nodes. The modules and manifests are then applied locally. * The Fuel project has added a framework that enables partners and community members to localize the Fuel UI by modifying the translate.json https://github.com/stackforge/fuel-web/blob/master/nailgun/static/i18n/tran slation.json file. A sample that translates the UI into zh-CN (Simplified Chinese) has been created by a community partner, 99cloud, and can be found in the file. * Previously, It was only possible to specify a subnet for a public network on the Networks tab of the Fuel UI. In this release, it is now possible to set a flexible range for Fuel use, for example 12.0.0.10 to 12.0.0.20. * Additional error checking has been added to the Fuel UI when entering information into the network settings under the Network tab. A full list of the limitations that are checked can be found on OpenStack Etherpad https://etherpad.openstack.org/p/limitations-of-networking-configuration . * In earlier releases, Fuel deployed the operating system and OpenStack components in a single action. Now, it is possible to deploy the operating system and OpenStack components in separate actions. This option is not expected to be used for typical deployments but may be useful in focused development or testing scenarios like OpenStack scalability testing as part of the OpenStack Rally https://wiki.openstack.org/wiki/Rally project. * Documentation http://docs.mirantis.com/fuel/fuel-4.0/reference-architecture.html#advanced -network-configuration-using-open-vswitch on how to enable NIC Bonding has been made more complete and thorough. * The default value for the Swift ring partition power is now being calculated according to https://answers.launchpad.net/swift/+question/211929. I¹m looking forward to continued involvement from the community on the Fuel project plus I¹m very excited as we continue discussions around leveraging pieces of the Fuel project into OpenStack Deployment (TripleO https://wiki.openstack.org/wiki/TripleO ) as we enter the new year. Happy Holidays to everyone, - David J. Easter Product Line Manager, Mirantis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications
Support for deploying the Neutron LBaaS is on the roadmap for the Fuel project, yes but most likely not before IceHouse at current velocity. - David J. Easter Product Line Manager, Mirantis -- Forwarded message -- From: Serg Melikyan smelik...@mirantis.com Date: Wed, Nov 27, 2013 at 6:52 PM Subject: Re: [openstack-dev] [Murano] [Neutron] [Fuel] Implementing Elastic Applications To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, fuel-...@lists.launchpad.net I had added Neutron and Fuel teams to this e-mail thread: Guys what is your thoughts on the subject? We see three possible ways to implement Elastic Applications in Murano: using Heat Neutron LBaaS, Heat AWS::ElasticLoadBalancing::LoadBalancer resource and own solution using HAProxy directly (see more details in the mail-thread). Previously we was using Heat and AWS::ElasticLoadBalancing::LoadBalancer resource, but this way have certain limitations. Does Fuel team have plans to implement support for Neutron LBaaS any time soon? Guys from Heat suggest Neutron LBaaS as a best long-term solution. Neutron Team - what is your thoughts? On Fri, Nov 15, 2013 at 6:53 PM, Thomas Hervé the...@gmail.com wrote: On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan smelik...@mirantis.com wrote: Murano has several applications which support scaling via load-balancing, this applications (Internet Information Services Web Farm, ASP.NET http://ASP.NET Application Web Farm) currently are based on Heat, particularly on resource called AWS::ElasticLoadBalancing::LoadBalancer, that currently does not support specification of any network related parameters. Inability to specify network related params leads to incorrect behavior during deployment in tenants with advanced Quantum deployment configuration, like Per-tenant Routers with Private Networks and this makes deployment of our * Web Farm applications to fail. We need to resolve issues with our * Web Farm, and make this applications to be reference implementation for elastic applications in Murano. This issue may be resolved in three ways: via extending configuration capabilities of AWS::ElasticLoadBalancing::LoadBalancer, using another implementation of load balancing in Heat - OS::Neutron::LoadBalancer or via implementing own load balancing application (that going to balance other apllications), for example based on HAProxy (as all previous ones). Please, respond with your thoughts on the question: Which implementation we should use to resolve issue with our Web Farm applications and why?. Below you can find more details about each of the options. AWS::ElasticLoadBalancing::LoadBalancer AWS::ElasticLoadBalancing::LoadBalancer is Amazon Cloud Formation compatible resource that implements load balancer via hard-coded nested stack that deploys and configures HAProxy. This resource requires specific image with CFN Tools and specific name F17-x86_64-cfntools available in Glance. It's look like we miss implementation of only one property in this resource - Subnets. OS::Neutron::LoadBalancer OS::Neutron::LoadBalancer is another Heat resource that implements load balancer. This resource is based on Load Balancer as a Service feature in Neutron. OS::Neutron::LoadBalancer is much more configurable and sophisticated but underlying implementation makes usage of this resource quite complex. LBaaS is a set of services installed and configured as a part of Neutron. Fuel does not support LBaaS; Devstack has support for LBaaS, but LBaaS not installed by default with Neutron. Own, Based on HAProxy We may implement load-balancer as a regular application in Murano using HAProxy. This service may look like our Active Directory application with almost same user-expirience. User may create load-balancer inside of the environment and join any web-application (with any number of instances) directly to load-balancer. Load-balancer may be also implemented on Conductor workflows level, this implementation strategy not going to change user-experience (in fact we changing only underlying implementation details for our * Web Farm applications, without introducing new ones). Hi, I would strongly encourage using OS::Neutron::LoadBalancer. The AWS resource is supposed to mirror Amazon capabilities, so any extension, while not impossible, is frowned upon. On the other hand the Neutron load balancer can be extended to your need, and being able to use an API gives you much more flexibility. It also in active development and will get more interesting features in the future. If you're having concerns about deploying Neutron LBaaS, you should bring it up with the team, and I'm sure they can improve the situation. My limited experience with it in devstack has been really good. Cheers, -- Thomas ___
