[openstack-dev] [Fuel] Beta milestone of Fuel 5.1 now available!

[David Easter]

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/
> 
> * 
> * 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/
> 
* 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
>  :
> 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 
> * 
> * 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

[David Easter]

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 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Thursday, August 21, 2014 at 12:11 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

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 
wrote:
> 
> On Thu, Aug 21, 2014 at 5:02 PM, Mike Scherbakov 
> 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

[David Easter]

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 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Friday, July 11, 2014 at 2:36 PM
To:  "OpenStack Development Mailing List (not for usage questions)"

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 
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 :
> 
>> 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 
>> 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 :
>>> 
 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  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
>  wrote:
>> > +1 for #2.
>> >
>> > ~Sergii
>> >
>> >
>> > On Fri, Jun 20, 2014 at 1:21 AM, Andrey Danin 
>> 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
>>> >>  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
 >>>  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.o

Re: [openstack-dev] [Fuel-dev] access-control-master-node

[David Easter]

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 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, May 27, 2014 at 7:43 AM
To:  "OpenStack Development Mailing List (not for usage questions)"

Subject:  Re: [openstack-dev] [Fuel-dev] access-control-master-node

On 27 May 2014 13:42, Lukasz Oles  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!

[David Easter]

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
  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

[David Easter]

Hi Fernando,

  Yes – we do want to re-introduce a monitoring solution back into Fuel.
Zabbix is the front runner right now.

Thanks,

- David J. Easter
  Product Line Manager,  Mirantis

From:  FERNANDO LOPEZ AGUILAR 
Reply-To:  "OpenStack Development Mailing List (not for usage questions)"

Date:  Tuesday, January 21, 2014 at 11:45 PM
To:  "openstack-dev@lists.openstack.org" 
Subject:  Re: [openstack-dev] [fuel-dev] monitoring openstack services with
nagios

Hello David,

Are you planning to use others, like zabbix, collectd or whatever?


Enviado de Samsung Mobile



 Original message 
Subject: Re: [openstack-dev] [fuel-dev] monitoring openstack services with
nagios 
From: David Easter 
To: "OpenStack Development Mailing List (not for usage questions)"

CC: 


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"
 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 <http://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



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
___ 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-dev] monitoring openstack services with nagios

[David Easter]

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"
 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

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

[David Easter]

Right now, Fuel deploys Ceilometer to use the OpenStack mySQL DB for
Ceilometer data, although we’re expecting to utilize MongoDB in the 4.1
Fuel version.  This is, as you mention, primarily to address the
performance issues with a shared mySQL DB.  That said, I don’t know that
it really changes the situation.  It’s not the OSTF info that’s being
stored, it’s the actual results of Ceilometer running against a
short-lived VM.  Those will still go into the Ceilometer DB, I believe, so
they’d have to be removed from there.

If, as Julian mentioned, there's a time-to-live mechanism in Ceilometer to
delete old samples then I would think we could just go with that.  When
OSTF runs the action, set the TTL against that sample.

Does that address the issue?

Thanks,

- David J. Easter
  Product Line Manager,  Mirantis



On 1/20/14, 4:48 AM, "Bogdan Dobrelya"  wrote:

>On 01/20/2014 01:29 PM, Dmitry Iakunchikov wrote:
>> David,
>> 
>> You're completely right,
>> 
>> The main problem is that ceilometer has possibility to create samples,
>> but not to delete. Because of that there is no possibility to remove
>> OSTF created data.
>1) What is current DB backend for Ceilometer? Can we use the separate
>database for OSTF and just drop while doing teardown?
>2) IIRC from Ceilometer PoC performance results, the main DB with Galera
>must never be used as backend for ceilometer because of performance
>issues?
>> 
>> Actually another way is to use time_to_live, but as you sad "As an
>> operator, I¹d expect that my data is retained even for items that have
>> been removed"(c)
>> 
>> 
>> 2014/1/17 David Easter ><mailto:deas...@mirantis.com>>
>> 
>> I¹d like to make sure I understand the question.  Is this the
>>scenario?
>> 
>>   * A user installs OpenStack
>>   * The user runs the OpenStack Health Check (OSTF) against
>> Ceilometer
>>   * The Health Check creates a VM against which ceilometer can
>> collect data
>>   * Ceilometer collects the data from this VM for an amount of time
>> and stores the data in mySQL
>>   * The Health Check then ends the test, removing the VM
>>   * The data collected about this sample VM is retained in mySQL and
>> is not removed.
>> 
>> Is this basically correct?
>> 
>> If so, I¹d ask if Ceilometer removes data from VM¹s or nodes that
>> have been deleted from OpenStack during normal operation or if the
>> data is retained in the run-time scenarios as well?  If so, wouldn¹t
>> this be a general requirement to remove data about entities that no
>> longer exist in the environment vs. an issue specific to Health
>> Check (OSTF)?
>> 
>> As an operator, I¹d expect that my data is retained even for items
>> that have been removed, but I agree that there should be a way for
>> an operator to make a decision to remove stale data ­ either based
>> on time or as a manually executed operation.  Removing data
>> automatically right away could lead to a loss of historical
>> information that could be used for longer term analysis and billing.
>> 
>> Or am I misinterpreting the situation and Ceilometer already allows
>> for deletion of data ­ and the question is just whether we should
>> remove the data collected during the test?  If that is the only
>> question, then yes ­ we should remove the data after the test is
>>done.
>> 
>> Thanks,
>> 
>> -Dave Easter
>> 
>> From: Dmitry Iakunchikov > <mailto:diakunchi...@mirantis.com>>
>> Date: Friday, January 17, 2014 at 5:10 AM
>> To: Nadya Privalova > <mailto:nprival...@mirantis.com>>, "OpenStack Development Mailing
>> List (not for usage questions)" > <mailto:openstack-dev@lists.openstack.org>>, Dmitry Iakunchikov
>> mailto:diakunchi...@mirantis.com>>, Mike
>> Scherbakov > <mailto:mscherba...@mirantis.com>>, Vladimir Kuklin
>> mailto:vkuk...@mirantis.com>>,
>> "fuel-...@lists.launchpad.net <mailto:fuel-...@lists.launchpad.net>"
>> mailto:fuel-...@lists.launchpad.net>>
>> Subject: Re: [Fuel-dev] [openstack-dev] [OSTF][Ceilometer]
>> ceilometer meters and samples delete
>> 
>> For now in Fuel we keep samples forever
>> 
>> In case if we will use time_to_live, how long we should keep this
>>data?
>> 
>> 
>> 2014/1/17 Julien Danjou ><mailto:jul...@danjou.info>&

Re: [openstack-dev] [Fuel-dev] [OSTF][Ceilometer] ceilometer meters and samples delete

[David Easter]

I¹d like to make sure I understand the question.  Is this the scenario?
* A user installs Mirantis OpenStack
* The user runs the Mirantis OpenStack Health Check (OSTF) against
Ceilometer
* The Health Check creates a VM against which ceilometer can collect data
* Ceilometer collects the data from this VM for an amount of time and stores
the data in mySQL
* The Health Check then ends the test, removing the VM
* The data collected about this sample VM is retained in mySQL and is not
removed.
Is this basically correct?

If so, I¹d ask if Ceilometer removes data from VM¹s or nodes that have been
deleted from OpenStack during normal operation or if the data is retained in
the run-time scenarios as well?  If so, wouldn¹t this be a general
requirement to remove data about entities that no longer exist in the
environment vs. an issue specific to Health Check (OSTF)?

As an operator, I¹d expect that my data is retained even for items that have
been removed, but I agree that there should be a way for an operator to make
a decision to remove stale data ­ either based on time or as a manually
executed operation.  Removing data automatically right away could lead to a
loss of historical information that could be used for longer term analysis
and billing.

Or am I misinterpreting the situation and Ceilometer already allows for
deletion of data ­ and the question is just whether we should remove the
data collected during the test?  If that is the only question, then yes ­ we
should remove the data after the test is done.

Thanks,

-Dave Easter

From:  Dmitry Iakunchikov 
Date:  Friday, January 17, 2014 at 5:10 AM
To:  Nadya Privalova , "OpenStack Development
Mailing List (not for usage questions)" ,
Dmitry Iakunchikov , Mike Scherbakov
, Vladimir Kuklin ,
"fuel-...@lists.launchpad.net" 
Subject:  Re: [Fuel-dev] [openstack-dev] [OSTF][Ceilometer] ceilometer
meters and samples delete

For now in Fuel we keep samples forever

In case if we will use time_to_live, how long we should keep this data?


2014/1/17 Julien Danjou 
> On Fri, Jan 17 2014, Nadya Privalova wrote:
> 
>> > I would ask in another way.
>> > Ceilometer has a mechanism to add a sample through POST. So it looks not
>> > consistent not to allow user to delete a sample.
>> > IMHO, insertion and deletion through REST looks a little bit hacky: user
>> > always has an ability to fake data collected from OpenStack services. But
>> > maybe I don't see any valuable usecases.
>> > Anyway, it seems reasonable to have both add_sample and delete_sample in
>> > API or not to have neither.
> 
> From the user PoV, that totally makes sense, agreed.
> 
> --
> Julien Danjou
> # Free Software hacker # independent consultant
> # http://julien.danjou.info



-- 
With Best Regards
QA engineer Dmitry Iakunchikov
-- Mailing list: https://launchpad.net/~fuel-dev Post to :
fuel-...@lists.launchpad.net Unsubscribe : https://launchpad.net/~fuel-dev
More help   : https://help.launchpad.net/ListHelp

___
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

[David Easter]

Hi All,

  Just a quick note to let folks know that the Fuel project
  has reached its 4.0 GA milestone.  This
version of Fuel has been updated to deploy Havana 2013.2.1
  including OpenStack
Orchestration (Heat) and optionally OpenStack Telemetry (Ceilometer).  It
also deploys the newest version of the Murano project
 .  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
  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
 .
* 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   project.
* Documentation 
  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
 ) 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

[David Easter]

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 
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)"
, 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é  wrote:
> On Fri, Nov 15, 2013 at 12:56 PM, Serg Melikyan 
> wrote:
>> > Murano has several applications which support scaling via load-balancing,
>> > this applications (Internet Information Services Web Farm, 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 devst