Re: [openstack-dev] [Fuel] removing single mode

[Evgeniy L]

Hi Andrew,

I have some comments regarding to you action items

>> 2) Removing simple mode from the ui and tests
>> 3) Removing simple mode support from nailgun (maybe we leave it) and cli

We shouldn't do it, because nailgun should handle both versions of cluster.
What we have to do here is to use openstack.yaml to keep all possible modes.
For new release there will be only ha, to manage previous releases we have
to create data migrations in nailgun to create the filed with modes i.e.
multinode
and ha.

Also fixes for ui are required too, I think it mostly related to wizard,
'mode' tab
where use can chose ha or non ha cluster in case of new release there should
be only ha, and in case of old releases there should be ha and multinode.

Thanks,



On Mon, Aug 25, 2014 at 8:19 PM, Andrew Woodward  wrote:

> Started a new thread so that we don't hijack the older thread.
>  as
>
>
>> Andrew, will you work on it in 6.0? What are remaining items there? Also,
>> it might affect our tests - simple mode runs faster so we use it for smoke
>> ISO test. Anastasia, please confirm that we can switch smoke to
>> one-ha-controller model, or even drop smoke at all and use BVT only
>> (running CentOS 3 HA controllers and same with Ubuntu).
>>
>
> The primary reason that we haven't disabled single yet is was due to [0]
> where we where having problems adding additional controllers. With the
> changes to galera and rabbit clustering it appears that we ended up fixing
> it already.
>
> The remaining issues are:
> 1) Ensuring we have good test coverage for the cases we expect to support
> [1]
> 2) Removing simple mode from the ui and tests
> 3) Removing simple mode support from nailgun (maybe we leave it) and cli
> 4) Updating documentation
>
> [0] https://bugs.launchpad.net/fuel/+bug/1350266
> [1] https://bugs.launchpad.net/fuel/+bug/1350266/comments/7
>
> --
> Andrew
> Mirantis
> Ceph community
>
> ___
> 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] Pre-5.1 and master builds ISO are available for download

[Evgeniy L]

Hi guys, I have to say something about beta releases.

As far as I know our beta release has the same version
5.1 as our final release.

I think this versions should be different, because in case
of some problem it will be much easier to identify what
version we are trying to debug.

Also from the irc channel I've heard that somebody wanted
to upgrade his system to stable version, right now it's impossible
because upgrade system uses this version for names of
containers/images/temporary directories and we have
validation which prevents the user to run upgrade to the
same version.

In upgrade script we use python module [1] to compare versions
for validation.
Let me give an example how development versions can look like

5.1a1 # alpha
5.1b1 # beta 1
5.1b1 # beta 2
5.1b1 # beta 3
5.1# final release

[1]
http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html

Thanks,


On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov 
wrote:

> Igor,
> thanks a lot for improving UX over it - this table allows me to see which
> ISO passed verification tests.
>
>
> On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin 
> wrote:
>
>> I would also like to add that you can use our library called devops along
>> with system tests we use for QA and CI. These tests use libvirt and kvm so
>> that you can easily fire up an environment with specific configuration
>> (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the documentation
>> how to use this library is here:
>> http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or
>> gaps in documentation, please feel free to file bugs to
>> https://launchpad.net/fuel.
>>
>>
>> On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin 
>> wrote:
>>
>>> Hi all,
>>> along with building your own ISO following instructions [1], you can
>>> always download nightly build [2] and run it, by using virtualbox scripts
>>> [3], for example.
>>>
>>> For your conveniency, you can see a build status table on CI [4]. First
>>> tab now refers to pre-5.1 builds, and second - to master builds.
>>> BVT columns stands for Build Verification Test, which is essentially
>>> full HA deploy deployment test.
>>>
>>> Currently pre-5.1 and master builds are actually built from same master
>>> branch. As soon as we call for Hard Code Freeze, pre-5.1 builds will be
>>> reconfigured to use stable/5.1 branch.
>>>
>>> Thanks,
>>>
>>> [1]
>>> http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
>>> [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds
>>> [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox
>>> [4] https://fuel-jenkins.mirantis.com/view/ISO/
>>> --
>>> Igor Shishkin
>>> DevOps
>>>
>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> 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
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> ___
>> 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

Re: [openstack-dev] [Fuel] master access control - future work

[Evgeniy L]

Hi Lukasz,

Regarding to 'Node agent authorization' do you have some ideas how it could
be done?
For me it looks really complicated, because we don't upgrade agents on
slave nodes and
I'm not sure if we will be able to do it in the nearest future.

Thanks,

On Tue, Sep 9, 2014 at 1:50 PM, Lukasz Oles  wrote:

> Dear Fuelers,
>
> I have some ideas and questions to share regarding Fuel Master access
> control.
>
> During 5,1 cycle we made some non optimal decision which we have to fix.
> The following blueprint describes required changes:
>
>
> https://blueprints.launchpad.net/fuel/+spec/access-control-master-node-improvments
>
> The next step to improve security is to introduce secure connection using
> HTTPS, it is described here:
>
> https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints
>
> And now, there is question about next stages from original blueprint:
>
> https://blueprints.launchpad.net/fuel/+spec/access-control-master-node
>
> For example, from stage 3:
> - Node agent authorization, which will increase security. Currently, any
> one can change node data.
> What do you think do we need it now?
>
> Please read and comment first two blueprints.
>
> --
> Łukasz Oleś
>
> ___
> 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] SSL in Fuel

[Evgeniy L]

Hi,

We definitely need a person who will help with design for the feature.

Here is the list of open questions:

1. UI design for certificates uploading
2. CLI
3. diagnostic snapshot sanitising
4. REST API/DB design
5. background tasks for nailgun (?)
6. do we need separate container to certificates signing? I don't think
that we need if it's
not separate service. If it command line tool, it can be installed in
nailgun container, in
case if we implement background tasks for nailgun, or in mcollective
container.

Thanks,

On Tue, Sep 9, 2014 at 2:09 PM, Guillaume Thouvenin 
wrote:

> I think that the management of certificates should be discussed in the
> ca-deployment blueprint [3]
>
> We had some discussions and it seems that one idea is to use a docker
> container as the root authority. By doing this we should be able to sign
> certificate from Nailgun and distribute the certificate to the
> corresponding controllers. So one way to see this is:
>
> 1) a new environment is created
> 2) Nailgun generates a key pair that will be used for the new env.
> 3) Nailgun sends a CSR that contains the VIP used by the new environment
> and signed by the newly created private key to the docker "root CA".
> 4) the docker "CA" will send back a signed certificate.
> 5) Nailgun distribute this signed certificate and the env private key to
> the corresponding controller through mcollective.
>
> It's not clear to me how Nailgun will interact with docker CA and I aslo
> have some concerns about the storage of different private key of
> environments but it is the idea...
> If needed I can start to fill the ca-deployment according to this scenario
> but I guess that we need to approve the BP [3].
>
> So I think that we need to start on [3]. As this is required for OSt
> public endpoint SSL and also for Fuel SSL it can be quicker to make a first
> stage where a self-signed certificate is managed from nailgun and a second
> stage with the docker CA...
>
> Best regards,
> Guillaume
>
> [3] https://blueprints.launchpad.net/fuel/+spec/ca-deployment
>
> ___
> 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] Plugable solution for running abstract commands on nodes

[Evgeniy L]

Hi,

In most cases for plugin developers or fuel users it will be much
easier to just write command which he wants to run on nodes
instead of describing some abstract task which doesn't have
any additional information/logic and looks like unnecessary complexity.

But for complicated cases user will have to write some code for tasklib.

Thanks,

On Wed, Sep 10, 2014 at 8:10 PM, Dmitriy Shulyak 
wrote:

> Hi,
>
> you described transport mechanism for running commands based on facts, we
> have another one, which stores
> all business logic in nailgun and only provides orchestrator with set of
> tasks to execute. This is not a problem.
>
> I am talking about API for plugin writer/developer. And how implement it
> to be more "friendly"
>
> On Wed, Sep 10, 2014 at 6:46 PM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> as for execution of arbitrary code across the OpenStack cluster - I was
>> thinking of mcollective + fact filters:
>>
>> 1) we need to start using mcollective facts [0] [2] - we don't
>> use/configure this currently
>> 2) use mcollective execute_shell_command agent (or any other agent) with
>> fact filter [1]
>>
>> So, for example, if we have mcollective fact called "node_roles":
>> node_roles: "compute ceph-osd"
>>
>> Then we can execute shell cmd on all compute nodes like this:
>>
>> mco rpc execute_shell_command execute cmd="/some_script.sh" -F
>> "node_role=/compute/"
>>
>> Of course, we can use more complicated filters to run commands more
>> precisely.
>>
>> [0]
>> https://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML
>> [1]
>> https://docs.puppetlabs.com/mcollective/reference/ui/filters.html#fact-filters
>> [2] https://docs.puppetlabs.com/mcollective/reference/plugins/facts.html
>>
>>
>> On Wed, Sep 10, 2014 at 6:04 PM, Dmitriy Shulyak 
>> wrote:
>>
>>> Hi folks,
>>>
>>> Some of you may know that there is ongoing work to achieve kindof
>>> data-driven orchestration
>>> for Fuel. If this is new to you, please get familiar with spec:
>>>
>>> https://review.openstack.org/#/c/113491/
>>>
>>> Knowing that running random command on nodes will be probably most
>>> usable type of
>>> orchestration extension, i want to discuss our solution for this problem.
>>>
>>> Plugin writer will need to do two things:
>>>
>>> 1. Provide custom task.yaml (i am using /etc/puppet/tasks, but this is
>>> completely configurable,
>>> we just need to reach agreement)
>>>
>>>   /etc/puppet/tasks/echo/task.yaml
>>>
>>>   with next content:
>>>
>>>type: exec
>>>cmd: echo 1
>>>
>>> 2. Provide control plane with orchestration metadata
>>>
>>> /etc/fuel/tasks/echo_task.yaml
>>>
>>> controller:
>>>  -
>>>   task: echo
>>>   description: Simple echo for you
>>>   priority: 1000
>>> compute:
>>> -
>>>   task: echo
>>>   description: Simple echo for you
>>>   priority: 1000
>>>
>>> This is done in order to separate concerns of orchestration logic and
>>> tasks.
>>>
>>> From plugin writer perspective it is far more usable to provide exact
>>> command in orchestration metadata itself, like:
>>>
>>> /etc/fuel/tasks/echo_task.yaml
>>>
>>> controller:
>>>  -
>>>   task: echo
>>>   description: Simple echo for you
>>>   priority: 1000
>>>   cmd: echo 1
>>>   type: exec
>>>
>>> compute:
>>> -
>>>  task: echo
>>>   description: Simple echo for you
>>>   priority: 1000
>>>   cmd: echo 1
>>>   type: exec
>>>
>>> I would prefer to stick to the first, because there is benefits of using
>>> one interface between all tasks executors (puppet, exec, maybe chef), which
>>> will improve debuging and development process.
>>>
>>> So my question is first - good enough? Or second is essential type of
>>> plugin to support?
>>>
>>> If you want additional implementation details check:
>>> https://review.openstack.org/#/c/118311/
>>> https://review.openstack.org/#/c/113226/
>>>
>>>
>>>
>>>
>>> ___
>>> 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

Re: [openstack-dev] [Fuel] Fuel Plugins, First look; Whats Next?

[Evgeniy L]

Hi Andrew,

Comments inline.
Also could you please provide a link on OpenStack upgrade feature?
It's not clear why do you need it as a plugin and how you are going
to deliver this feature.

On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward  wrote:

> So as part of the pumphouse integration, I've started poking around
> the Plugin Arch implementation as an attempt to plug it into the fuel
> master.
>
> This would require that the plugin install a container, and some
> scripts into the master node.
>
> First look:
> I've looked over the fuel plugins spec [1] and see that the install
> script was removed from rev 15 ->16 (line 134) This creates problems
> do to the need of installing the container, and scripts so I've
> created a bug [2] for this so that we can allow for an install script
> to be executed prior to HCF for 6.0.
>

Yes, it was removed, but nothing stops you from creating the install
script and putting it in tarball, you don't need any changes in the
current implementation.

The reasons why it was done this way, see in separate mailing thread [1].

[1]
http://lists.openstack.org/pipermail/openstack-dev/2014-October/049073.html


>
> Looking into the implementation of the install routine [3] to
> implement [2], I see that the fuelclient is extracting the tar blindly
> (more on that at #3) on the executor system that fuelclient is being
> executed from. Problems with this include 1) the fuelclient may not
> root be privileged (like in Mirantis OpenStack Express) 2) the
> fuelclient may not be running on the same system as nailgun 3) we are
> just calling .extractall on the tarball, this means that we haven't
> done any validation on the files coming out of the tarball. We need to
> validate that 3.a) the tarball was actually encoded with the right
> base path 3.b) that the tasks.yaml file is validated and all the noted
> scripts are found. Really, the install of the plugin should be handled
> by the nailgun side to help with 1,2.
>

1. if you have custom installation you have to provide custom permissions
for /var/www/nailgun/plugins directory
2. you are absolutely right, see the thread from above why we decided to add
this feature even if it was a wrong decision from architecture point of
view
3. "haven't done any validation" - not exactly, validation is done on plugin
building stage, also we have simple validation on plugin installation
stage on
Nailgun side (that data are consistent from nailgun point of view).
There are
several reasons why it was done mainly on fuel-plugin-builder side:
  a. plugin is validated before it's installed (it dramatically
simplifies development)
  b. also you can check that plugin is valid without plugin building,
  use 'fpb --check fuel_plugin_name' parameter
  c. faster fixes delivery, if there is a bug in validation (we had
several of them
  during the development in fuel-plugin-builder), we cannot just
release new
  version of fuel, but we can do it with fuel-plugin-builder, we
had 2 releases [1].
  For more complicated structures you will have bugs in validation
for sure.
  d. if we decide to support validations on both sides, we will come up
with a lot of bugs
  which are related to desynchronization of validators between
Nailgun and fuel-plugin-builder

[1]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md


>
> Whats next?
> There are many parts of PA that need to be extended, I think that
> these are the ones that we must tackle next to cover the most cases
> a) plugin packaging: it appears that non of the "core plugins" (those
> in fuel-plugins) are bundled into the iso.
> b) plugin signing: we cant have "core plugins" with out some method of
> testing, certifying, and signing them so that we can know that they
> are trusted.
>
> with the help of granular roles:
> c) the ability to replace or add new granular roles
> d) the ability to add or modify real roles
>
> with the help of advanced networks:
> e) add new network roles
>
> At some point soon, we also need to discuss making it easier to find a
> catalog of modules and pull them from it, but this is less important
> than the above
>
> [1]
> https://review.openstack.org/#/c/125608/15..16/specs/6.0/cinder-neutron-plugins-in-fuel.rst
> [2] https://bugs.launchpad.net/fuel/+bug/1395228
> [3]
> https://github.com/stackforge/fuel-web/blob/master/fuelclient/fuelclient/objects/plugins.py#L49
>
> --
> Andrew
> Mirantis
> Ceph community
>
> ___
> 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] Plugins improvement

[Evgeniy L]

Hi Dmitry,

Our current validation implementation is based on jsonschema,
we will figure out how to hack/configure it to provide more human
readable message

Thanks,

On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov  wrote:

> That was my fault. I did not expect that timeout parameter is a mandatory
> requirement for task. Every thing works perfectly fine.
> Thanks for the help.
>
> On Mon, Nov 24, 2014 at 3:05 PM, Tatyana Leontovich <
> tleontov...@mirantis.com> wrote:
>
>> Guys,
>> task like
>> - role: ['controller']
>> stage: post_deployment
>> type: puppet
>> parameters:
>> puppet_manifest: puppet/site.pp
>> puppet_modules: puppet/modules/
>> timeout: 360
>> works fine for me, so  I believe your task should looks like
>>
>> cat tasks.yaml
>> # This tasks will be applied on controller nodes,
>> # here you can also specify several roles, for example
>> # ['cinder', 'compute'] will be applied only on
>> # cinder and compute nodes
>> - role: ['controller']
>>   stage: post_deployment
>>   type: puppet
>>   parameters:
>> puppet_manifest: install_keystone_ldap.pp
>> puppet_modules: /etc/puppet/modules/"
>>
>> And be sure that install_keystone_ldap.pp thos one invoke other manifests
>>
>> Best,
>> Tatyana
>>
>> On Mon, Nov 24, 2014 at 12:49 PM, Dmitry Ukov  wrote:
>>
>>> Unfortunately this does not work
>>>
>>> cat tasks.yaml
>>> # This tasks will be applied on controller nodes,
>>> # here you can also specify several roles, for example
>>> # ['cinder', 'compute'] will be applied only on
>>> # cinder and compute nodes
>>> - role: ['controller']
>>>   stage: post_deployment
>>>   type: puppet
>>>   parameters:
>>> puppet_manifest: install_keystone_ldap.pp
>>> puppet_modules: "puppet/:/etc/puppet/modules/"
>>>
>>>
>>> fpb --build .
>>> /home/dukov/dev/.plugins_ldap/local/lib/python2.7/site-packages/pkg_resources.py:1045:
>>> UserWarning: /home/dukov/.python-eggs is writable by group/others and
>>> vulnerable to attack when used with get_resource_filename. Consider a more
>>> secure location (set with .set_extraction_path or the PYTHON_EGG_CACHE
>>> environment variable).
>>>   warnings.warn(msg, UserWarning)
>>> 2014-11-24 13:48:32 ERROR 15026 (cli) Wrong value format "0 ->
>>> parameters", for file "./tasks.yaml", {'puppet_modules':
>>> 'puppet/:/etc/puppet/modules/', 'puppet_manifest':
>>> 'install_keystone_ldap.pp'} is not valid under any of the given schemas
>>> Traceback (most recent call last):
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/cli.py",
>>> line 90, in main
>>> perform_action(args)
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/cli.py",
>>> line 77, in perform_action
>>> actions.BuildPlugin(args.build).run()
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/actions/build.py",
>>> line 42, in run
>>> self.check()
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/actions/build.py",
>>> line 99, in check
>>> self._check_structure()
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/actions/build.py",
>>> line 111, in _check_structure
>>> ValidatorManager(self.plugin_path).get_validator().validate()
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/validators/validator_v1.py",
>>> line 39, in validate
>>> self.check_schemas()
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/validators/validator_v1.py",
>>> line 46, in check_schemas
>>> self.validate_file_by_schema(v1.TASKS_SCHEMA, self.tasks_path)
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/validators/base.py",
>>> line 47, in validate_file_by_schema
>>> self.validate_schema(data, schema, path)
>>>   File
>>> "/home/dukov/git/fuel/fuel-plugins/fuel_plugin_builder/fuel_plugin_builder/validators/base.py",
>>> line 43, in validate_schema
>>> value_path, path, exc.message))
>>> ValidationError: Wrong value format "0 -> parameters", for file
>>> "./tasks.yaml", {'puppet_modules': 'puppet/:/etc/puppet/modules/',
>>> 'puppet_manifest': 'install_keystone_ldap.pp'} is not valid under any of
>>> the given schemas
>>>
>>>
>>> On Mon, Nov 24, 2014 at 2:34 PM, Aleksandr Didenko <
>>> adide...@mirantis.com> wrote:
>>>
 Hi,

 according to [1] you should be able to use:

 puppet_modules: "puppet/:/etc/puppet/modules/"

 This is valid string yaml parameter that should be parsed just fine.

 [1]
 https://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62

 Regards
 --
 Alex


 On Mon, Nov 24, 2014 at 12:07 PM, Dmitry Ukov 
 wrote:

> Hello All,
> Current implementation of plugins in Fuel unpacks plugin tarball
> into /var/www/nailgun/plugins/.
> If we implement deplo

Re: [openstack-dev] [Fuel] Fuel Plugins, First look; Whats Next?

[Evgeniy L]

On Tue, Nov 25, 2014 at 10:40 AM, Andrew Woodward  wrote:

> On Mon, Nov 24, 2014 at 4:40 AM, Evgeniy L  wrote:
> > Hi Andrew,
> >
> > Comments inline.
> > Also could you please provide a link on OpenStack upgrade feature?
> > It's not clear why do you need it as a plugin and how you are going
> > to deliver this feature.
> >
> > On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward 
> wrote:
> >>
> >> So as part of the pumphouse integration, I've started poking around
> >> the Plugin Arch implementation as an attempt to plug it into the fuel
> >> master.
> >>
> >> This would require that the plugin install a container, and some
> >> scripts into the master node.
> >>
> >> First look:
> >> I've looked over the fuel plugins spec [1] and see that the install
> >> script was removed from rev 15 ->16 (line 134) This creates problems
> >> do to the need of installing the container, and scripts so I've
> >> created a bug [2] for this so that we can allow for an install script
> >> to be executed prior to HCF for 6.0.
> >
> >
> > Yes, it was removed, but nothing stops you from creating the install
> > script and putting it in tarball, you don't need any changes in the
> > current implementation.
>
> how would it be executed? the plugin loading done by fuel-client
> doesn't cover this.
>

Manually untar and run your script, as it was designed before we implemented
more user friendly approach.


> >
> > The reasons why it was done this way, see in separate mailing thread [1].
> >
> > [1]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2014-October/049073.html
> >
> >>
> >>
> >> Looking into the implementation of the install routine [3] to
> >> implement [2], I see that the fuelclient is extracting the tar blindly
> >> (more on that at #3) on the executor system that fuelclient is being
> >> executed from. Problems with this include 1) the fuelclient may not
> >> root be privileged (like in Mirantis OpenStack Express) 2) the
> >> fuelclient may not be running on the same system as nailgun 3) we are
> >> just calling .extractall on the tarball, this means that we haven't
> >> done any validation on the files coming out of the tarball. We need to
> >> validate that 3.a) the tarball was actually encoded with the right
> >> base path 3.b) that the tasks.yaml file is validated and all the noted
> >> scripts are found. Really, the install of the plugin should be handled
> >> by the nailgun side to help with 1,2.
> >
> >
> > 1. if you have custom installation you have to provide custom permissions
> > for /var/www/nailgun/plugins directory
> > 2. you are absolutely right, see the thread from above why we decided to
> add
> > this feature even if it was a wrong decision from architecture point
> of
> > view
> > 3. "haven't done any validation" - not exactly, validation is done on
> plugin
> > building stage, also we have simple validation on plugin installation
> > stage on
> > Nailgun side (that data are consistent from nailgun point of view).
> > There are
> > several reasons why it was done mainly on fuel-plugin-builder side:
> >   a. plugin is validated before it's installed (it dramatically
> > simplifies development)
> >   b. also you can check that plugin is valid without plugin building,
> >   use 'fpb --check fuel_plugin_name' parameter
> >   c. faster fixes delivery, if there is a bug in validation (we had
> > several of them
> >   during the development in fuel-plugin-builder), we cannot just
> > release new
> >   version of fuel, but we can do it with fuel-plugin-builder, we
> had
> > 2 releases [1].
> >   For more complicated structures you will have bugs in
> validation
> > for sure.
> >   d. if we decide to support validations on both sides, we will come
> up
> > with a lot of bugs
> >   which are related to desynchronization of validators between
> > Nailgun and fuel-plugin-builder
>
> the main validation points that should be done by nailgun is to verify
> that the paths are correct. i.e.
> * the tar ./ == metadata.yaml['name']
> * tasks.yaml + metadata.yaml refer to valid paths for "cmd",
> "deployment_scripts_path", "repository_path"
>
> Rright now there is no contract between the user building the plugin
> with fpb, vs addi

Re: [openstack-dev] [Fuel] About deployment progress calculation

[Evgeniy L]

Hi Dmitry,

I totally agree that the current approach won't work (and doesn't work
well).

I have several comments:

>> Each task will provide estimated time

1. Each task has timeout, lets use it as an estimate, I don't think
that we should ask to provide both of this fields, execution
estimate depends on hardware, my suggestion is to keep it
simple and solve the problem internally with information from
timeout field.
2. I would like to clarify implementation a bit more, what is
"time delta of the task"? I think that Task executor (
orchestrator/astute/mistral)
shouldn't provide any information except status of the task,
it should be simple interface, like "task_uuid: 1, status: running"
and Nailgun on its side should do all of the magic with progress
calculation.

Thanks,

On Tue, Oct 28, 2014 at 10:29 AM, Dmitriy Shulyak 
wrote:

> Hello everyone,
>
> I want to raise concerns about progress bar, and its usability.
> In my opinion current approach has several downsides:
> 1. No valuable information
> 2. Very fragile, you need to change code in several places not to break it
> 3. Will not work with plugable code
>
> Log parsing works under one basic assumption - that we are in control of
> all tasks,
> so we can use mappings to logs with certain pattern.
>  It wont work with plugable architecture, and i am talking not about
> fuel-plugins, and the
> way it will be done in 6.0, but the whole idea of plugable architecture,
> and i assume that internal features will be implemented as granular
> self-contained plugins,
> and it will be possible to accomplish not only with puppet, but with any
> other tool that suits you.
> Asking person who will provide plugin (extension) to add mappings to logs
> - feels like weirdeist thing ever.
>
> *What can be done to improve usability of progress calculation?*
> I see here several requirements:
> 1.Provide valuable information
>   - Correct representation of time that task takes to run
>   - What is going on target node in any point of the deployment?
> 2. Plugin friendly, it means that approach we will take should be flexible
> and extendable
>
> *Implementation:*
> In nearest future deployment will be splitted into tasks, they are will be
> big, not granular
> (like deploy controller, deploy compute), but this does not matter,
> because we can start to estimate them.
> Each task will provide estimated time.
> At first it will be manually setted by person who develops plugin (tasks),
> but it can be improved,
> so this information automatically (or semi-auto) will be provided by
> fuel-stats application.
> It will require orchestrator to report 2 simple entities:
> - time delta of the task
> - task identity
> UI will be able to show percents anyway, but additionally it will show
> what is running on target node.
>
> Ofcourse it is not about 6.0, but please take a look, and lets try to agree
> on what is right way to solve this task, because log parsing will not work
> with data-driven
> orchestrator and plugable architecture.
> Thank you
>
> ___
> 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] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Hi Vitaly,

I agree with you that conditions can be useful in case of complicated
plugins, but
at the same time in case of simple cases it adds a huge amount of
complexity.
I would like to avoid forcing user to know about any conditions if he wants
to add several text fields on the UI.

I have several reasons why we shouldn't do that:
1. conditions are described with yet another language with it's own syntax
2. the language is not documented (solvable)
3. complicated interface will lead to a lot of bugs for the end user, and
it will be
a Fuel team's problem
4. in case of several checkboxes you'll have to write a huge conditions with
a lot of "and" statements and it'll be really easy to forget about some
of them

As result in simple cases plugin developer will have to specify the same
condition of every task in tasks.yaml file, add it to metadata.yaml.
If you add new checkbox, you should go through all of this files,
add "and lbaas:new_checkbox_name" statement.

Thanks,

On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh 
wrote:

> Folks,
>
> In the 6.0 release we'll support simple plugins for Fuel. The current
> architecture allows to create only very simple plugins and doesn't allow to
> "pluginize" complex features like Ceph, vCenter, etc. I'd like to propose
> some changes to make it possible. They are subtle enough and the plugin
> template still can be autogenerated by Fuel Plugin Builder. Here they are:
>
>
> https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf
>
>1. environment_config.yaml should contain exact config which will be
>mixed into cluster_attributes. No need to implicitly generate any controls
>like it is done now.
>2. metadata.yaml should also contain "is_removable" field. This field
>is needed to determine whether it is possible to remove installed plugin.
>It is impossible to remove plugins in the current implementation. This
>field should contain an expression written in our DSL which we already use
>in a few places. The LBaaS plugin also uses it to hide the checkbox if
>Neutron is not used, so even simple plugins like this need to utilize it.
>This field can also be autogenerated, for more complex plugins plugin
>writer needs to fix it manually. For example, for Ceph it could look like
>"settings:storage.volumes_ceph.value == false and
>settings:storage.images_ceph.value == false".
>3. For every task in tasks.yaml there should be added new "condition"
>field with an expression which determines whether the task should be run.
>In the current implementation tasks are always run for specified roles. For
>example, vCenter plugin can have a few tasks with conditions like
>"settings:common.libvirt_type.value == 'vcenter'" or
>"settings:storage.volumes_vmdk.value == true". Also, AFAIU, similar
>approach will be used in implementation of Granular Deployment feature.
>
> These simple changes will allow to write much more complex plugins. What
> do you think?
> --
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

>> Yes, but is already used in a few places. I want to notice once again -
even a simple LBaaS plugin with a single checkbox needed to utilize this
functionality.

Yes, but you don't need to specify it in each task.

>> So, you're still calling this interface complicated. Ok, I'm looking
forward to seeing your proposal about dealing with complex plugins.

All my concerns were related to simple plugins and that we should
find a way not to force a plugin developer to do this copy-paste work.

>> If you have several checkboxes, then it is a complex plugin with complex
configuration ...

Here we need a definition of s simple plugins, in the current
release with simple plugins you can define some fields on the UI (not a
single checkbox) and run several tasks if plugin is enabled.

Thanks,

>
On Fri, Nov 28, 2014 at 7:01 PM, Vitaly Kramskikh 
wrote:

> Evgeniy,
>
> Responses inline:
>
> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>
>> Hi Vitaly,
>>
>> I agree with you that conditions can be useful in case of complicated
>> plugins, but
>> at the same time in case of simple cases it adds a huge amount of
>> complexity.
>> I would like to avoid forcing user to know about any conditions if he
>> wants
>> to add several text fields on the UI.
>>
>> I have several reasons why we shouldn't do that:
>> 1. conditions are described with yet another language with it's own syntax
>>
> Yes, but is already used in a few places. I want to notice once again -
> even a simple LBaaS plugin with a single checkbox needed to utilize this
> functionality.
>
>> 2. the language is not documented (solvable)
>>
> It is documented:
> http://docs.mirantis.com/fuel-dev/develop/nailgun/customization/settings.html#expression-syntax
>
>> 3. complicated interface will lead to a lot of bugs for the end user, and
>> it will be
>> a Fuel team's problem
>>
> So, you're still calling this interface complicated. Ok, I'm looking
> forward to seeing your proposal about dealing with complex plugins.
>
>> 4. in case of several checkboxes you'll have to write a huge conditions
>> with
>> a lot of "and" statements and it'll be really easy to forget about
>> some of them
>>
> If you have several checkboxes, then it is a complex plugin with complex
> configuration, so I see no problem here. There will be many more places
> where you can "forget" stuff.
>
>>
>> As result in simple cases plugin developer will have to specify the same
>> condition of every task in tasks.yaml file, add it to metadata.yaml.
>> If you add new checkbox, you should go through all of this files,
>> add "and lbaas:new_checkbox_name" statement.
>>
> Once again, in simple cases checkbox and the conditions (one for task and
> one for is_removable) can be easily pregenerated by FPB, so plugin
> developer has to do nothing more. If you add a new checkbox which doesn't
> affect plugin removeability and tasks, you have to change nothing in plugin
> metadata.
>
>>
>> Thanks,
>>
>> On Thu, Nov 27, 2014 at 7:57 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>> Folks,
>>>
>>> In the 6.0 release we'll support simple plugins for Fuel. The current
>>> architecture allows to create only very simple plugins and doesn't allow to
>>> "pluginize" complex features like Ceph, vCenter, etc. I'd like to propose
>>> some changes to make it possible. They are subtle enough and the plugin
>>> template still can be autogenerated by Fuel Plugin Builder. Here they are:
>>>
>>>
>>> https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf
>>>
>>>1. environment_config.yaml should contain exact config which will be
>>>mixed into cluster_attributes. No need to implicitly generate any 
>>> controls
>>>like it is done now.
>>>2. metadata.yaml should also contain "is_removable" field. This
>>>field is needed to determine whether it is possible to remove installed
>>>plugin. It is impossible to remove plugins in the current implementation.
>>>This field should contain an expression written in our DSL which we 
>>> already
>>>use in a few places. The LBaaS plugin also uses it to hide the checkbox 
>>> if
>>>Neutron is not used, so even simple plugins like this need to utilize it.
>>>This field can also be autogenerated, for more complex plugins plugin
>>>writer needs to 

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Hi,

First let me describe what our plans for the nearest release. We want to
deliver
role as a simple plugin, it means that plugin developer can define his own
role
with yaml and also it should work fine with our current approach when user
can
define several fields on the settings tab.

Also I would like to mention another thing which we should probably discuss
in separate thread, how plugins should be implemented. We have two types
of plugins, simple and complicated, the definition of simple - I can do
everything
I need with yaml, the definition of complicated - probably I have to write
some
python code. It doesn't mean that this python code should do absolutely
everything it wants, but it means we should implement stable, documented
interface where plugin is connected to the core.

Now lets talk about UI flow, our current problem is how to get the
information
if plugins is used in the environment or not, this information is required
for
backend which generates appropriate tasks for task executor, also this
information can be used in the future if we decide to implement plugins
deletion
mechanism.

I didn't come up with a some new solution, as before we have two options to
solve the problem:

# 1

Use conditional language which is currently used on UI, it will look like
Vitaly described in the example [1].
Plugin developer should:

1. describe at least one element for UI, which he will be able to use in
task

2. add condition which is written in our own programming language

Example of the condition for LBaaS plugin:

condition: settings:lbaas.metadata.enabled == true

3. add condition to metadata.yaml a condition which defines if plugin is
enabled

is_enabled: settings:lbaas.metadata.enabled == true

This approach has good flexibility, but also it has problems:

a. It's complicated and not intuitive for plugin developer.
b. It doesn't cover case when the user installs 3rd party plugin
which doesn't have any conditions (because of # a) and
user doesn't have a way to disable it for environment if it
breaks his configuration.

# 2

As we discussed from the very beginning after user selects a release he can
choose a set of plugins which he wants to be enabled for environment.
After that we can say that plugin is enabled for the environment and we send
tasks related to this plugin to task executor.

>> My approach also allows to eliminate "enableness" of plugins which will
cause UX issues and issues like you described above. vCenter and Ceph also
don't have "enabled" state. vCenter has hypervisor and storage, Ceph
provides backends for Cinder and Glance which can be used simultaneously or
only one of them can be used.

Both of described plugins have enabled/disabled state, vCenter is enabled
when vCenter is selected as hypervisor. Ceph is enabled when it's selected
as a backend for Cinder or Glance.

If you don't like the idea of having Ceph/vCenter checkboxes on the first
page,
I can suggest as an idea (research is required) to define groups like
Storage Backend,
Network Manager and we will allow plugin developer to embed his option in
radiobutton
field on wizard pages. But plugin developer should not describe conditions,
he should
just write that his plugin is a Storage Backend, Hypervisor or new Network
Manager.
And the plugins e.g. Zabbix, Nagios, which don't belong to any of this
groups
should be shown as checkboxes on the first page of the wizard.

>
[1]
https://github.com/vkramskikh/fuel-plugins/commit/1ddb166731fc4bf614f502b276eb136687cb20cf

On Sun, Nov 30, 2014 at 3:12 PM, Vitaly Kramskikh 
wrote:

>
>
> 2014-11-28 23:20 GMT+04:00 Dmitriy Shulyak :
>
>>
>>>- environment_config.yaml should contain exact config which will be
>>>mixed into cluster_attributes. No need to implicitly generate any 
>>> controls
>>>like it is done now.
>>>
>>>  Initially i had the same thoughts and wanted to use it the way it is,
>> but now i completely agree with Evgeniy that additional DSL will cause a lot
>> of problems with compatibility between versions and developer experience.
>>
> As far as I understand, you want to introduce another approach to describe
> UI part or plugins?
>
>> We need to search for alternatives..
>> 1. for UI i would prefer separate tab for plugins, where user will be
>> able to enable/disable plugin explicitly.
>>
> Of course, we need a separate page for plugin management.
>
>> Currently settings tab is overloaded.
>> 2. on backend we need to validate plugins against certain env before
>> enabling it,
>>and for simple case we may expose some basic entities like
>> network_mode.
>> For case where you need complex logic - python code is far more flexible
>> that new DSL.
>>
>>>
>>>- metadata.yaml should also contain "is_removable" field. This field
>>>is needed to determine whether it is possible to remove installed plugin.
>>>It is impossible to remove plugins in the current implementation.
>>>This field should contain an expression written in

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh 
wrote:

>
>
> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>
>> Hi,
>>
>> First let me describe what our plans for the nearest release. We want to
>> deliver
>> role as a simple plugin, it means that plugin developer can define his
>> own role
>> with yaml and also it should work fine with our current approach when
>> user can
>> define several fields on the settings tab.
>>
>> Also I would like to mention another thing which we should probably
>> discuss
>> in separate thread, how plugins should be implemented. We have two types
>> of plugins, simple and complicated, the definition of simple - I can do
>> everything
>> I need with yaml, the definition of complicated - probably I have to
>> write some
>> python code. It doesn't mean that this python code should do absolutely
>> everything it wants, but it means we should implement stable, documented
>> interface where plugin is connected to the core.
>>
>> Now lets talk about UI flow, our current problem is how to get the
>> information
>> if plugins is used in the environment or not, this information is
>> required for
>> backend which generates appropriate tasks for task executor, also this
>> information can be used in the future if we decide to implement plugins
>> deletion
>> mechanism.
>>
>> I didn't come up with a some new solution, as before we have two options
>> to
>> solve the problem:
>>
>> # 1
>>
>> Use conditional language which is currently used on UI, it will look like
>> Vitaly described in the example [1].
>> Plugin developer should:
>>
>> 1. describe at least one element for UI, which he will be able to use in
>> task
>>
>> 2. add condition which is written in our own programming language
>>
>> Example of the condition for LBaaS plugin:
>>
>> condition: settings:lbaas.metadata.enabled == true
>>
>> 3. add condition to metadata.yaml a condition which defines if plugin is
>> enabled
>>
>> is_enabled: settings:lbaas.metadata.enabled == true
>>
>> This approach has good flexibility, but also it has problems:
>>
>> a. It's complicated and not intuitive for plugin developer.
>>
> It is less complicated than python code
>

I'm not sure why are you talking about python code here, my point
is we should not force developer to use this conditions in any language.

Anyway I don't agree with the statement there are more people who know
python than "fuel ui conditional language".


> b. It doesn't cover case when the user installs 3rd party plugin
>> which doesn't have any conditions (because of # a) and
>> user doesn't have a way to disable it for environment if it
>> breaks his configuration.
>>
> If plugin doesn't have conditions for tasks, then it has invalid metadata.
>

Yep, and it's a problem of the platform, which provides a bad interface.


>
>> # 2
>>
>> As we discussed from the very beginning after user selects a release he
>> can
>> choose a set of plugins which he wants to be enabled for environment.
>> After that we can say that plugin is enabled for the environment and we
>> send
>> tasks related to this plugin to task executor.
>>
>> >> My approach also allows to eliminate "enableness" of plugins which
>> will cause UX issues and issues like you described above. vCenter and Ceph
>> also don't have "enabled" state. vCenter has hypervisor and storage, Ceph
>> provides backends for Cinder and Glance which can be used simultaneously or
>> only one of them can be used.
>>
>> Both of described plugins have enabled/disabled state, vCenter is enabled
>> when vCenter is selected as hypervisor. Ceph is enabled when it's selected
>> as a backend for Cinder or Glance.
>>
> Nope, Ceph for Volumes can be used without Ceph for Images. Both of these
> plugins can also have some granular tasks which are enabled by various
> checkboxes (like VMware vCenter for volumes). How would you determine
> whether tasks which installs VMware vCenter for volumes should run?
>

Why "nope"? I have "Cinder OR Glance".
It can be easily handled in deployment script.


>> If you don't like the idea of having Ceph/vCenter checkboxes on the first
>> page,
>> I can suggest as an idea (research is required) to define groups like
>> Storage Backend,
>> Network Manager and we will allow plugin developer to embed his option in
>> radio

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Hi,

I don't agree with many of your statements but, I would like to
continue discussion about really important topic i.e. UI flow, my
suggestion was to add groups, for plugin in metadata.yaml plugin
developer can have description of the groups which it belongs to:

groups:
  - id: storage
subgroup:
  - id: cinder

With this information we can show a new option on UI (wizard),
if option is selected, it means that plugin is enabled, if plugin belongs
to several groups, we can use OR statement.

The main point is, for environment creation we must specify
ids of plugins. Yet another reason for that is plugins multiversioning,
we must know exactly which plugin with which version
is used for environment, and I don't see how "conditions" can help
us with it.

Thanks,

>
>>
>>
On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh 
wrote:
>
>
>
> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>
>>
>>
>> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>>
>>>
>>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>>
>>>> Hi,
>>>>
>>>> First let me describe what our plans for the nearest release. We want
>>>> to deliver
>>>> role as a simple plugin, it means that plugin developer can define his
>>>> own role
>>>> with yaml and also it should work fine with our current approach when
>>>> user can
>>>> define several fields on the settings tab.
>>>>
>>>> Also I would like to mention another thing which we should probably
>>>> discuss
>>>> in separate thread, how plugins should be implemented. We have two types
>>>> of plugins, simple and complicated, the definition of simple - I can do
>>>> everything
>>>> I need with yaml, the definition of complicated - probably I have to
>>>> write some
>>>> python code. It doesn't mean that this python code should do absolutely
>>>> everything it wants, but it means we should implement stable, documented
>>>> interface where plugin is connected to the core.
>>>>
>>>> Now lets talk about UI flow, our current problem is how to get the
>>>> information
>>>> if plugins is used in the environment or not, this information is
>>>> required for
>>>> backend which generates appropriate tasks for task executor, also this
>>>> information can be used in the future if we decide to implement plugins
>>>> deletion
>>>> mechanism.
>>>>
>>>> I didn't come up with a some new solution, as before we have two
>>>> options to
>>>> solve the problem:
>>>>
>>>> # 1
>>>>
>>>> Use conditional language which is currently used on UI, it will look
>>>> like
>>>> Vitaly described in the example [1].
>>>> Plugin developer should:
>>>>
>>>> 1. describe at least one element for UI, which he will be able to use
>>>> in task
>>>>
>>>> 2. add condition which is written in our own programming language
>>>>
>>>> Example of the condition for LBaaS plugin:
>>>>
>>>> condition: settings:lbaas.metadata.enabled == true
>>>>
>>>> 3. add condition to metadata.yaml a condition which defines if plugin
>>>> is enabled
>>>>
>>>> is_enabled: settings:lbaas.metadata.enabled == true
>>>>
>>>> This approach has good flexibility, but also it has problems:
>>>>
>>>> a. It's complicated and not intuitive for plugin developer.
>>>>
>>> It is less complicated than python code
>>>
>>
>> I'm not sure why are you talking about python code here, my point
>> is we should not force developer to use this conditions in any language.
>>
>> But that's how current plugin-like stuff works. There are various tasks
> which are run only if some checkboxes are set, so stuff like Ceph and
> vCenter will need conditions to describe tasks.
>
>> Anyway I don't agree with the statement there are more people who know
>> python than "fuel ui conditional language".
>>
>>
>>> b. It doesn't cover case when the user installs 3rd party plugin
>>>> which doesn't have any conditions (because of # a) and
>>>> user doesn't have a way to disable it for environment if it
>>>> breaks his configuration.
>>>>
&g

Re: [openstack-dev] [Fuel] [Plugins] Further development of plugin metadata format

[Evgeniy L]

Vitaly, what do you think about that?

On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L  wrote:
>
> Hi,
>
> I don't agree with many of your statements but, I would like to
> continue discussion about really important topic i.e. UI flow, my
> suggestion was to add groups, for plugin in metadata.yaml plugin
> developer can have description of the groups which it belongs to:
>
> groups:
>   - id: storage
> subgroup:
>   - id: cinder
>
> With this information we can show a new option on UI (wizard),
> if option is selected, it means that plugin is enabled, if plugin belongs
> to several groups, we can use OR statement.
>
> The main point is, for environment creation we must specify
> ids of plugins. Yet another reason for that is plugins multiversioning,
> we must know exactly which plugin with which version
> is used for environment, and I don't see how "conditions" can help
> us with it.
>
> Thanks,
>
>>
>>>
>>>
> On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh  > wrote:
>>
>>
>>
>> 2014-12-10 19:31 GMT+03:00 Evgeniy L :
>>
>>>
>>>
>>> On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh <
>>> vkramsk...@mirantis.com> wrote:
>>>
>>>>
>>>>
>>>> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>>>>
>>>>> Hi,
>>>>>
>>>>> First let me describe what our plans for the nearest release. We want
>>>>> to deliver
>>>>> role as a simple plugin, it means that plugin developer can define his
>>>>> own role
>>>>> with yaml and also it should work fine with our current approach when
>>>>> user can
>>>>> define several fields on the settings tab.
>>>>>
>>>>> Also I would like to mention another thing which we should probably
>>>>> discuss
>>>>> in separate thread, how plugins should be implemented. We have two
>>>>> types
>>>>> of plugins, simple and complicated, the definition of simple - I can
>>>>> do everything
>>>>> I need with yaml, the definition of complicated - probably I have to
>>>>> write some
>>>>> python code. It doesn't mean that this python code should do absolutely
>>>>> everything it wants, but it means we should implement stable,
>>>>> documented
>>>>> interface where plugin is connected to the core.
>>>>>
>>>>> Now lets talk about UI flow, our current problem is how to get the
>>>>> information
>>>>> if plugins is used in the environment or not, this information is
>>>>> required for
>>>>> backend which generates appropriate tasks for task executor, also this
>>>>> information can be used in the future if we decide to implement
>>>>> plugins deletion
>>>>> mechanism.
>>>>>
>>>>> I didn't come up with a some new solution, as before we have two
>>>>> options to
>>>>> solve the problem:
>>>>>
>>>>> # 1
>>>>>
>>>>> Use conditional language which is currently used on UI, it will look
>>>>> like
>>>>> Vitaly described in the example [1].
>>>>> Plugin developer should:
>>>>>
>>>>> 1. describe at least one element for UI, which he will be able to use
>>>>> in task
>>>>>
>>>>> 2. add condition which is written in our own programming language
>>>>>
>>>>> Example of the condition for LBaaS plugin:
>>>>>
>>>>> condition: settings:lbaas.metadata.enabled == true
>>>>>
>>>>> 3. add condition to metadata.yaml a condition which defines if plugin
>>>>> is enabled
>>>>>
>>>>> is_enabled: settings:lbaas.metadata.enabled == true
>>>>>
>>>>> This approach has good flexibility, but also it has problems:
>>>>>
>>>>> a. It's complicated and not intuitive for plugin developer.
>>>>>
>>>> It is less complicated than python code
>>>>
>>>
>>> I'm not sure why are you talking about python code here, my point
>>> is we should not force developer to use this conditions in any language.
>>>
>>> But that's how current plugin-like stuff works. There are various tasks
>> which are run only if so

[openstack-dev] [Fuel][Plugins] UI workflow, plugins enabling/disabling

[Evgeniy L]

Hi,

Recently we've discussed what plugins should look like from user point of
view [1].
On one of the meeting it was decided to have the next flow:

1. user installs fuel plugin (as usually with `fuel plugins install
fuel-plugin-name-1.0.0.fp`)
2. after that plugin can be seen on Plugins page, the button for this page
will be placed
somewhere between Environments and Releases buttons
3. each plugin on the page has checkbox, the checkbox represents the
default state of
plugin for new environments, if checkbox is checked, when user creates
environment,
he can see all of the buttons which are related to plugin, e.g. in case
of Contrail
he can see new option in the list of network providers on Network tab
in the wizard
4. during the environment configuration user should select options which
are related to the plugin,
the information about the list of options and where they should be
placed is described by
plugin developer
5. when user starts deployment, Nailgun parses tasks and depending on
conditions
sends them to Astute, the conditions are described for each task by
plugin developer,
example of condition "cluster:net_provider != 'contrail' ", if task
doesn't have conditions,
we always execute it

Any comments on that?

Thanks,

[1]
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg40878.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

[Evgeniy L]

Hi,

Agree with Igor, I think we cannot just drop compatibility for fuel client
with 2.6 python, the reason is we have old master nodes which have
2.6 python, and the newer fuel client should work fine on these
environments.

Or we can try to install python 2.7 on the master during the upgrade.

As for Nailgun I don't see any problems to use 2.7.

Thanks,

On Mon, Jan 12, 2015 at 7:32 PM, Igor Kalnitsky 
wrote:

> Hi, Roman,
>
> Indeed, we have to go forward and drop python 2.6 support. That's how
> it supposed to be, but, unfortunately, it may not be as easy as it
> seems at first glance.
>
> Fuel Master is flying on top of Cent OS 6.5 which doesn't have python
> 2.7 at all. So we must either run master node on Cent OS 7 or build
> python2.7 for Cent OS 6.5. The first case, obviously, requires a lot
> of work, while the second one is not. But I may wrong, since I have no
> idea what dependencies python 2.7 requires and what we have in our
> repos.
>
> - Igor
>
> On Mon, Jan 12, 2015 at 4:55 PM, Roman Prykhodchenko 
> wrote:
> > Folks,
> >
> > as it was planned and then announced at the OpenStack summit OpenStack
> services deprecated Python-2.6 support. At the moment several services and
> libraries are already only compatible with Python>=2.7. And there is no
> common sense in trying to get back compatibility with Py2.6 because
> OpenStack infra does not run tests for that version of Python.
> >
> > The point of this email is that some components of Fuel, say, Nailgun
> and Fuel Client are still only tested with Python-2.6. Fuel Client in it’s
> turn is about to use OpenStack CI’s python-jobs for running unit tests.
> That means that in order to make it compatible with Py2.6 there is a need
> to run a separate python job in FuelCI.
> >
> > However, I believe that forcing the things being compatible with 2.6
> when the rest of ecosystem decided not to go with it and when Py2.7 is
> already available in the main CentOS repo sounds like a battle with the
> common sense. So my proposal is to drop 2.6 support in Fuel-6.1.
> >
> >
> > - romcheg
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping Python-2.6 support

[Evgeniy L]

Hi Dmitry,

>> Client uses REST API to interact with Fuel, how is Python version a
factor?

Fuel client is written in python it means it won't work on the master node
with 2.6 python if you drop compatibility with it.

>> What exactly is the use cases that requires a new client deployed on an
old Fuel master node (or vice versa)?

Fuel master node upgrade, we install newer client during the upgrade.

>> It's not that hard ...

It looks not so hard, but it should be well tested before it's merged,
and it's risky because fuel client is installed on the host system, not
into the container, hence in case if something goes wrong we cannot
make automatic rollback.

Thanks,

On Mon, Jan 12, 2015 at 8:24 PM, Dmitry Borodaenko  wrote:

> On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L  wrote:
> > Agree with Igor, I think we cannot just drop compatibility for fuel
> client
> > with 2.6 python,
>
> Hm, didn't Igor say in his email that "we have to drop python 2.6 support"?
>
> > the reason is we have old master nodes which have
> > 2.6 python, and the newer fuel client should work fine on these
> > environments.
>
> Client uses REST API to interact with Fuel, how is Python version a factor?
>
> What exactly is the use cases that requires a new client deployed on
> an old Fuel master node (or vice versa)?
>
> > Or we can try to install python 2.7 on the master during the upgrade.
>
> Lets do this. It's not that hard, see the link in an email from Ihar
> Hrachyshka on this thread.
>
> > As for Nailgun I don't see any problems to use 2.7.
> >
> > Thanks,
> >
> > On Mon, Jan 12, 2015 at 7:32 PM, Igor Kalnitsky  >
> > wrote:
> >>
> >> Hi, Roman,
> >>
> >> Indeed, we have to go forward and drop python 2.6 support. That's how
> >> it supposed to be, but, unfortunately, it may not be as easy as it
> >> seems at first glance.
> >>
> >> Fuel Master is flying on top of Cent OS 6.5 which doesn't have python
> >> 2.7 at all. So we must either run master node on Cent OS 7 or build
> >> python2.7 for Cent OS 6.5. The first case, obviously, requires a lot
> >> of work, while the second one is not. But I may wrong, since I have no
> >> idea what dependencies python 2.7 requires and what we have in our
> >> repos.
> >>
> >> - Igor
> >>
> >> On Mon, Jan 12, 2015 at 4:55 PM, Roman Prykhodchenko 
> >> wrote:
> >> > Folks,
> >> >
> >> > as it was planned and then announced at the OpenStack summit OpenStack
> >> > services deprecated Python-2.6 support. At the moment several
> services and
> >> > libraries are already only compatible with Python>=2.7. And there is
> no
> >> > common sense in trying to get back compatibility with Py2.6 because
> >> > OpenStack infra does not run tests for that version of Python.
> >> >
> >> > The point of this email is that some components of Fuel, say, Nailgun
> >> > and Fuel Client are still only tested with Python-2.6. Fuel Client in
> it’s
> >> > turn is about to use OpenStack CI’s python-jobs for running unit
> tests. That
> >> > means that in order to make it compatible with Py2.6 there is a need
> to run
> >> > a separate python job in FuelCI.
> >> >
> >> > However, I believe that forcing the things being compatible with 2.6
> >> > when the rest of ecosystem decided not to go with it and when Py2.7 is
> >> > already available in the main CentOS repo sounds like a battle with
> the
> >> > common sense. So my proposal is to drop 2.6 support in Fuel-6.1.
> >> >
> >> >
> >> > - romcheg
> >> >
> >> >
> >> >
> __
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> __
> >> OpenStack Development Mailing 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
> >
>
>
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Empty role - status

[Evgeniy L]

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?

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

Re: [openstack-dev] [Fuel] Empty role - status

[Evgeniy L]

Hi Andrew,

What you described is exactly what we were going to do [1],
and everybody understand all of the cons which you described.
Also if you take a look at the blueprint it's not about plugins at all.
Scope of improvements was reduced for the current release and
"Role as a plugin" was postponed.

[1] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin
[2] https://blueprints.launchpad.net/fuel/+spec/blank-role-node

On Thu, Jan 15, 2015 at 11:17 PM, Andrew Woodward  wrote:

> [from another thread]
> On Wed, Jan 14, 2015 at 2:24 AM, Igor Kalnitsky 
> wrote:
> >
> > Guys,
> >
> > We want to introduce an "empty role" as a basis for plugins. For
> > instance, the user select nodes, assign empty role and names it
> > somehow like "CONTRAIL". In this step, vanilla fuel will just
> > provision a node (since it's an empty role) and the plugin (in post
> > hooks) can select all empty roles with node.name == "CONTRAIL" and
> > deploy some stuff on that node.
> >
> > Obviously, it's hackish. But it's a simple approach that requires a
> > minimum time. In future, we'll introduce pluggable roles, but that's
> > another story.
>
>
> So far from the review we simply added an role with a base OS, this
> provides a nearly useless experience for plugin developers. This is
> heavy on hacking even for plugin-devs
>
> issues:
> 1) you get one role
> 2) you have to come up with some random way to identify nodes from
> each other if you do. We can't set hostname, and node.name in the
> nailgun is never in astute.yaml (which is a tech debt that we have
> code to fix)
> 3) disk layout is fixed, and uselessly small, plugin-author will have
> a lot of rework to do here
> 4) multiple plugins that need roles will effectively fight with each other
>
> We can add roles in the releases API as it is, a plugin should be able
> to leverage this, the only gap currently is [1] which is not an API
> currently (new from granular deployments).
>
> Because of this, it would be more useful to just call these API's
> during installing the plugin. Worse case, the plugin author can do
> this themselves if we add the install_script support [2]
>
> [1]
> https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py
> [2] https://review.openstack.org/#/c/137301/
>
> On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin  wrote:
> > Answers inline.
> >
> > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L  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
> >>
> >
> >
> >
> &

Re: [openstack-dev] [Fuel] Empty role - status

[Evgeniy L]

>> The whole-disk allocator we use for ceph-osd should be proper to work
around this problem in a way.

Our current constraint for Ubuntu is it cannot be allocated on several
disks,
as far as I remember for ceph-osd Fuel allocates from 1 to N disks, and it
doesn't
allocate any other volumes on the same disk with Ceph's volumes. So I don't
see
how it can help here.

On Thu, Jan 15, 2015 at 11:47 PM, Andrew Woodward  wrote:

> On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin  wrote:
> > Answers inline.
> >
> > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L  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.
>
> Seriously? NO the 15G Min / Max 50G "min" for the OS allocation is too
> small for a default value and not using the rest of the disk. While
> the user may easily change this (by the way, most users don't they
> expect better allocations), how do you expect the plugin-dev to deal
> with this? The way this seams to push the plugin-dev is to do it
> pre-deployment via code. We know already working with the disk
> allocation is very painful, why are we pushing them to 'duplicate'
> code. We need proper support of dynamically adding roles so they can
> re-use our code
>
> Is [2] the correct bug for the ubuntu OS volume issue? It's clearly
> talking about small root disk values being wrong for all real
> deployments.
>
> I'll try to look for the proper bug w/regards to ubuntu OS, but the
> gist is the limitation is that the OS volume can not span multiple
> disks. The whole-disk allocator we use for ceph-osd should be proper
> to work around this problem in a way.
>
> >>
> >> 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
> >
>
>
>
> --
> Andrew
> Mirantis
> 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

Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments

[Evgeniy L]

Hi,

1) +1 for warning

2) I don't think that we should delete tasks, it's a history which can be
useful,
for example for stats feature, also it's useful for debugging, but each task
should have created_at and updated_at fields, and from api you will be able
to get the latest tasks for specific env.

Thanks,

On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh 
wrote:

> Folks,
>
> I want to discuss possibility to add network verification status field for
> environments. There are 2 reasons for this:
>
> 1) One of the most frequent reasons of deployment failure is wrong network
> configuration. In the current UI network verification is completely
> optional and sometimes users are even unaware that this feature exists. We
> can warn the user before the start of deployment if network check failed of
> wasn't performed.
>
> 2) Currently network verification status is partially tracked by status of
> the last network verification task. Sometimes its results become stale, and
> the UI removes the task. There are a few cases when the UI does this, like
> changing network settings, adding a new node, etc (you can grep
> "removeFinishedNetworkTasks" to see all the cases). This definitely should
> be done on backend.
>
> What is your opinion on this?
>
> --
> 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
>
>
__
OpenStack Development Mailing 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] Generic linux role and priorities

[Evgeniy L]

Hi Dmitry,

We have plans to implement role as a plugin [1], but it
was decided to reduce the scope for 6.1 release and
the feature was postponed.

As a workaround you can use pre deployment hook
to perform some actions before any node is deployed.

Thanks,

[1] https://blueprints.launchpad.net/fuel/+spec/role-as-a-plugin


On Fri, Jan 16, 2015 at 5:32 PM, Dmitry Ukov  wrote:

> Hi all,
> I've figured out that generic linux role had been implemended (
> https://blueprints.launchpad.net/fuel/+spec/blank-role-node). It seems
> very important feature in terms of further extension for puggable
> architecture.
> In order to implement more complex plugins (e.g. for Zabbix or another
> monitoring system) we need to change role priorities (e.g. to deploy some
> node types before OpenStack Cluster).
> Are there any plans to implement custom roles prioritization?
> Thanks in advance.
>
> --
> Kind regards
> Dmitry Ukov
> IT 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
>
>
__
OpenStack Development Mailing 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] Cluster replaced deployment of provisioning information

[Evgeniy L]

Hi Dmitry,

The problem with merging is usually it's not clear how system performs
merging.
For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
3}]}, and I want
{'list': [{'k': 4}]} to be merged, what system should do? Replace the list
or add {'k': 4}?
Both cases should be covered.

Most of the users don't remember all of the keys, usually user gets the
defaults, and
changes some values in place, in this case we should ask user to remove the
rest
of the fields.

The only solution which I see is to separate the data from the graph, not
to send
this information to user.

Thanks,

On Thu, Jan 22, 2015 at 5:18 PM, Dmitriy Shulyak 
wrote:

> Hi guys,
>
> I want to discuss the way we are working with deployment configuration
> that were redefined for cluster.
>
> In case it was redefined by API - we are using that information instead of
> generated.
> With one exception, we will generate new repo sources and path to manifest
> if we are using update (patching feature in 6.0).
>
> Starting from 6.1 this configuration will be populated by tasks, which is
> a part of granular deployment
> workflow and replacement of configuration will lead to inability to use
> partial graph execution API.
> Ofcourse it is possible to hack around and make it work, but imo we need
> generic solution.
>
> Next problem - if user will upload replaced information, changes on
> cluster attributes, or networks, wont be reflected in deployment anymore
> and it constantly leads to problems for deployment engineers that are using
> fuel.
>
> What if user want to add data, and use generated of networks, attributes,
> etc?
> - it may be required as a part of manual plugin installation (ha_fencing
> requires a lot of configuration to be added into astute.yaml),
> - or you need to substitute networking data, e.g add specific parameters
> for linux bridges
>
> So given all this, i think that we should not substitute all information,
> but only part that is present in
> redefined info, and if there is additional parameters they will be simply
> merged into generated info
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Plugins for Fuel: repo, doc, spec - where?

[Evgeniy L]

Hi Mike,

All of the items look nice. I have a small comment regarding to the docs.
I don't think that we should force plugin developer to write the docs in
Sphinx compatible format, I vote for Github compatible docs format,
and in case if we want to show this information somewhere else,
we can use Github's engine [1] to convert the docs into html pages.

Thanks,

[1] https://github.com/github/markup/tree/master

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov 
wrote:

> Hi Fuelers,
> we've implemented pluggable architecture piece in 6.0, and got a number of
> plugins already. Overall development process for plugins is still not fully
> defined.
> We initially thought that having all the plugins in one repo on stackforge
> is Ok, we also put some docs into existing fuel-docs repo, and specs to
> fuel-specs.
>
> We might need a change here. Plugins are not tight to any particular
> release date, and they can also be separated each from other in terms of
> committers and core reviewers. Also, it seems to be pretty natural to keep
> all docs and design specs associated with particular plugin.
>
> With all said, following best dev practices, it is suggested to:
>
>1. Have a separate stackforge repo per Fuel plugin in format
>"fuel-plugin-", with separate core-reviewers group which should have
>plugin contributor initially
>2. Have docs folder in the plugin, and ability to build docs out of it
>   - do we want Sphinx or simple Github docs format is Ok? So people
>   can just go to github/stackforge to see docs
>3. Have specification in the plugin repo
>   - also, do we need Sphinx here?
>4. Have plugins tests in the repo
>
> Ideas / suggestions / comments?
> Thanks,
> --
> 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

Re: [openstack-dev] [Fuel] Core rights in Fuel repositories

[Evgeniy L]

+1

On Fri, Jan 23, 2015 at 7:45 PM, Igor Kalnitsky 
wrote:

> +1, no objections from my side.
>
> On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko 
> wrote:
> > Hi folks!
> >
> > After moving python-fuelclient to its own repo some of you started
> asking a good question which is How do we manage core rights in different
> Fuel repositories. The problem is that there is a single fuel-core group
> which is used for all fuel-* repos, except for python-fuelclient.
> >
> > The approach mentioned above does not work very well at the moment and
> so I’d like to propose a different one:
> >
> > - Every new or separated project shoud introduce it’s own -core group.
> >  -  That group vill only contain active core reviewers for only that
> project.
> >  -  Removing or adding people will be done according to Approved
> OpenStack rules.
> > - fuel-core group will be reduced to the smallest possible number of
> people and only include the guys
> >  who must have decision making powers according to Fuel project’s rules.
> >  - fuel-core will be included to any other fuel-*core group
> >  - elections to the fuel-core group will take place according to Fuel’s
> policies
> >  - fuel-core group members are required for supervising reasons and
> taking an action in emergency cases
> >
> >
> > - 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
>
__
OpenStack Development Mailing 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] [UI] Deploy Changes dialog redesign

[Evgeniy L]

Hi,

I agree that this information is useless, but it's not really clear what
you are going
to show instead, will you completely remove the information about nodes for
deployment?
I think the list of nodes for deployment (without detailed list of changes)
can be useful
for the user.

Thanks,

On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh 
wrote:

> +1 for removing "changes" attribute. It's useless now. If there are no
> plans to add something else there, let's remove it.
>
> 2015-01-26 11:39 GMT+03:00 Julia Aranovich :
>
>> Hi All,
>>
>> Since we changed Deploy Changes pop-up and added processing of role
>> limits and restrictions  I
>> would like to raise a question of it's subsequent refactoring.
>>
>> In particular, I mean 'changes' attribute of cluster model. It's
>> displayed in Deploy Changes dialog in the following format
>> :
>>
>>- Changed disks configuration on the following nodes:
>>- 
>>- Changed interfaces configuration on the following nodes:
>>   - 
>>- Changed network settings
>>- Changed OpenStack settings
>>
>> This list looks absolutely useless.
>>
>> It doesn't make any sense to display lists of new, not deployed nodes
>> with changed disks/interfaces. It's obvious I think that new nodes
>> attributes await deployment. At the same time user isn't able to change
>> disks/interfaces on deployed nodes (at least in UI). So, such node name
>> lists are definitely redundant.
>> Networks and settings are also locked after deployment finished.
>>
>>
>> I tend to get rid of cluster model 'changes' attribute at all.
>>
>> It is important for me to know your opinion, to make a final decision.
>> Please feel free and share your ideas and concerns if any.
>>
>>
>> Regards,
>> Julia
>>
>> --
>> Kind Regards,
>> Julia Aranovich,
>> Software Engineer,
>> Mirantis, Inc
>> +7 (905) 388-82-61 (cell)
>> Skype: juliakirnosova
>> www.mirantis.ru
>> jaranov...@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
>>
>>
>
>
> --
> 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
>
>
__
OpenStack Development Mailing 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] [UI] Deploy Changes dialog redesign

[Evgeniy L]

To be more specific, +1 for removing this information from UI, not from
backend.

On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L  wrote:

> Hi,
>
> I agree that this information is useless, but it's not really clear what
> you are going
> to show instead, will you completely remove the information about nodes
> for deployment?
> I think the list of nodes for deployment (without detailed list of
> changes) can be useful
> for the user.
>
> Thanks,
>
> On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh  > wrote:
>
>> +1 for removing "changes" attribute. It's useless now. If there are no
>> plans to add something else there, let's remove it.
>>
>> 2015-01-26 11:39 GMT+03:00 Julia Aranovich :
>>
>>> Hi All,
>>>
>>> Since we changed Deploy Changes pop-up and added processing of role
>>> limits and restrictions <https://review.openstack.org/#/c/126930/> I
>>> would like to raise a question of it's subsequent refactoring.
>>>
>>> In particular, I mean 'changes' attribute of cluster model. It's
>>> displayed in Deploy Changes dialog in the following format
>>> <http://s2.postimg.org/ak9inonhl/deploy_changes_dialog.png>:
>>>
>>>- Changed disks configuration on the following nodes:
>>>- 
>>>- Changed interfaces configuration on the following nodes:
>>>   - 
>>>- Changed network settings
>>>- Changed OpenStack settings
>>>
>>> This list looks absolutely useless.
>>>
>>> It doesn't make any sense to display lists of new, not deployed nodes
>>> with changed disks/interfaces. It's obvious I think that new nodes
>>> attributes await deployment. At the same time user isn't able to change
>>> disks/interfaces on deployed nodes (at least in UI). So, such node name
>>> lists are definitely redundant.
>>> Networks and settings are also locked after deployment finished.
>>>
>>>
>>> I tend to get rid of cluster model 'changes' attribute at all.
>>>
>>> It is important for me to know your opinion, to make a final decision.
>>> Please feel free and share your ideas and concerns if any.
>>>
>>>
>>> Regards,
>>> Julia
>>>
>>> --
>>> Kind Regards,
>>> Julia Aranovich,
>>> Software Engineer,
>>> Mirantis, Inc
>>> +7 (905) 388-82-61 (cell)
>>> Skype: juliakirnosova
>>> www.mirantis.ru
>>> jaranov...@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
>>>
>>>
>>
>>
>> --
>> 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
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Using saltstack as orchestrator for fuel

[Evgeniy L]

Hi,

As far as I remember we wanted to replace Astute with Mistral [1], do we
really want to have some intermediate steps (I mean salt) to do it?

[1] https://wiki.openstack.org/wiki/Mistral


On Wed, Jun 11, 2014 at 10:38 AM, Dmitriy Shulyak 
wrote:

> Yes, in my opinion salt can completely replace astute/mcollective/rabbitmq.
> Listen and respond to the events generated by nailgun, or any other plugin
> - not a problem.
> There is already some kind of plugin for salt that adds ability to execute
> puppet on minions (agents) [1]
>
> [1]
> http://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.puppet.html
>
>
> On Tue, Jun 10, 2014 at 4:06 PM, Mike Scherbakov  > wrote:
>
>> Interesting stuff.
>> Do you think that we can get rid of Astute at some point being purely
>> replaced by Salt?
>> And listening for the commands from Fuel?
>>
>> Can you please clarify, does the suggested approach implies that we can
>> have both puppet & SaltStack? Even if you ever switch to anything
>> different, it is important to provide a smooth and step-by-step way for it.
>>
>>
>>
>> On Mon, Jun 9, 2014 at 6:05 AM, Dmitriy Shulyak 
>> wrote:
>>
>>> Hi folks,
>>>
>>> I know that sometime ago saltstack was evaluated to be used as
>>> orchestrator in fuel, so I've prepared some initial specification, that
>>> addresses basic points of integration, and general requirements for
>>> orchestrator.
>>>
>>> In my opinion saltstack perfectly fits our needs, and we can benefit
>>> from using mature orchestrator, that has its own community. I still dont
>>> have all the answers, but , anyway, i would like to ask all of you to start
>>> a review for specification
>>>
>>>
>>> https://docs.google.com/document/d/1uOHgxM9ZT_2IdcmWvgpEfCMoV8o0Fk7BoAlsGHEoIfs/edit?usp=sharing
>>>
>>> I will place it in fuel-docs repo as soon as specification will be full
>>> enough to start POC, or if you think that spec should placed there as is, i
>>> can do it now
>>>
>>> Thank you
>>>
>>> ___
>>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Symlinks to new stuff for OpenStack Patching

[Evgeniy L]

Hi,

In case of OpenStack patching you don't need to create any symlinks and
mount new directories, you can just create new subdirectory in
/var/www/nailgun with specific version of openstack, like /var/www/nailgun/
5.0.1. And then use it as a repository path for new OpenStack releases.


On Mon, Jun 16, 2014 at 12:50 PM, Matthew Mosesohn 
wrote:

> Hi Igor,
>
> The repo directory its is too large to fit in a docker container and
> work reliably. It is just a symlink inside the repo storage container
> from host:/var/www/nailgun to repo-container:/repo. This /repo folder
> is shared out to containers, such as nginx, and then symlinks are
> created for each subdir in /var/www/nailgun. If you need more links
> without rebuilding your environment, you would need to symbolically
> link your new repository from /var/www/nailgun/newlink to
> /var/lib/docker/devicemapper/mnt/$(docker nspect -f='{{.ID}}'
> __containername__)/rootfs/repo. (replace __containername__ with the
> container you're trying to work on).
>
> I hope this helps.
>
> -Matthew
>
> On Sun, Jun 15, 2014 at 2:32 PM, Igor Kalnitsky 
> wrote:
> > Hello fuelers,
> >
> > I'm working on openstack patching for 5.1 and I've met some problems.
> > The problems I've met are in repos/puppets installing process.
> >
> > The problems are almost same, so I describe it on repos example.
> >
> > The repos data are located in /var/www/nailgun. This folder is mounted
> > as /repo into Nginx container. Nginx container has own /var/www/nailgun
> > with various symlinks to /repo's content.
> >
> > So the problem is that we need to add symlinks to newest repos in Nginx
> > container. How this problem should be solved? Should our fuel-upgrade
> > script add these symlinks or we'll ship new docker containers which
> > already contain these symlinks?
> >
> >
> > Thanks,
> > Igor
> >
> > ___
> > 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] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

Hi,

We had a meeting today about plugins on UI, as result of the meeting
we have two approaches and this approaches affect not only UX but
plugins itself.

*1st - disable/enable plugin on settings tab*

   1. user installs the plugin
   2. creates a cluster
   3. configures and enables/disables plugins on settings tab

For user it will look like Ceph plugin checkboxes on settings tab,
if he enables checkbox, then we pass the parameter to orchestrator
as `true`.

Cons:

   - plugin developer should define a checkbox in each plugin (for plugin
   disabling/enabling)
   - on the backend we have to enable all of the plugins for environment,
   because user can define any name for his checkbox and we won't be able to
   find it and make appropriate mapping plugin <-> env
   - since all of the plugins are always "enabled" we have to run tasks for
   all of the plugins, and each plugin should parse astute.yaml in order to
   figure out if it's required to run task current script

Pros:

   - it won't require additional setting or step for wizard
   - user will be able to disable plugin after environment creation

*2nd - enable plugins in wizard*

   1. user installs the plugin
   2. now he can choose specific plugins for his environment in wizard
   3. after cluster is created, he can configure additional parameters on
   settings tab, if plugin provides any

Cons:

   - user won't be able to disable plugin after cluster is created
   - additional step or configuration subcategory in wizard

Pros:

On backend we always know which plugin is disabled and which is enabled.



   - it means we don't provide settings for plugins which are disabled
   - we don't run tasks on slaves if it's not required

Thanks,
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

Hi Dmitry,

>> In 1st case - in tasks we will introduce simple conditions (in
description or in python code of the plugin):

You will be able to do it in the same way in case of 2nd solution.
I mean there is no constraints on conditions defining.

>> Also, we should not forget about CLI

In case of cli we can provide special parameter and user will be able to
create env with specific plugins.

Thanks,

On Tue, Oct 7, 2014 at 6:51 PM, Dmitriy Shulyak 
wrote:

> Hi, I would use 1st option.
> Consider plugins which is mutually exclusive, and you need to disable
> default tasks if plugin is selected.
>
> As example:
> - neutron backend plugins
>
> neutron_backend:
>   choices:
> - ovs
> - contrail
>   value: ovs
>
> Right now we are using ovs as neutron_backend, but what we will need to do
> if plugin will provide completely different backend, as contrail?
>
> In 1st case - in tasks we will introduce simple conditions (in description
> or in python code of the plugin):
> condition: 'ovs == cluster.attributes.neutron_backend' - for default
> workflow
>
> condition: 'contrail == cluster.attributes.neutron_backend' - contrail
> plugin workflow
>
> And if we need to exclude some task from workflow - simply select another
> value from drop down list.
> I believe same applies for glance/cinder backends (lvm/ceph, swift/ceph).
> Atleast we are managing them this way right now.
>
> Also, we should not forget about CLI.
> I can easily imagine how operator downloads cluster config (big cluster
> attributes file) and modifies it accordingly to turn on specific plugins.
> How we will manage plugins from cli if plugins will be managed from
> wizard?
>
>
> On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> We had a meeting today about plugins on UI, as result of the meeting
>> we have two approaches and this approaches affect not only UX but
>> plugins itself.
>>
>> *1st - disable/enable plugin on settings tab*
>>
>>1. user installs the plugin
>>2. creates a cluster
>>3. configures and enables/disables plugins on settings tab
>>
>> For user it will look like Ceph plugin checkboxes on settings tab,
>> if he enables checkbox, then we pass the parameter to orchestrator
>> as `true`.
>>
>> Cons:
>>
>>- plugin developer should define a checkbox in each plugin (for
>>plugin disabling/enabling)
>>- on the backend we have to enable all of the plugins for
>>environment, because user can define any name for his checkbox and we 
>> won't
>>be able to find it and make appropriate mapping plugin <-> env
>>- since all of the plugins are always "enabled" we have to run tasks
>>for all of the plugins, and each plugin should parse astute.yaml in order
>>to figure out if it's required to run task current script
>>
>> Pros:
>>
>>- it won't require additional setting or step for wizard
>>- user will be able to disable plugin after environment creation
>>
>> *2nd - enable plugins in wizard*
>>
>>1. user installs the plugin
>>2. now he can choose specific plugins for his environment in wizard
>>3. after cluster is created, he can configure additional parameters
>>on settings tab, if plugin provides any
>>
>> Cons:
>>
>>- user won't be able to disable plugin after cluster is created
>>- additional step or configuration subcategory in wizard
>>
>> Pros:
>>
>> On backend we always know which plugin is disabled and which is enabled.
>>
>>
>>
>>- it means we don't provide settings for plugins which are disabled
>>- we don't run tasks on slaves if it's not required
>>
>> Thanks,
>>
>> ___
>> 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] Cluster reconfiguration scenarios

[Evgeniy L]

Hi,

I'm not sure if we should add the new state in this case, it looks like you
can get this
information dynamically, you already have the state of env which tells you
that
there are new ceph nodes, and there are no ready ceph nodes in the cluster
hence you should install ceph-mon on the controllers.

The same for rabbitmq, if there is new controller, run rabbit
reconfiguration on
non-controllers nodes.

Thanks,

On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak 
wrote:

> Hi folks,
> I want to discuss cluster reconfiguration scenarios, i am aware of 2 such
> bugs:
>
> - ceph-mon not installed on controllers if cluster initially was deployed
> without ceph-osd
> - config with rabbitmq hosts not updated on non-controlles nodes after
> additional controllers is added to cluster [1]
>
> In both cases we need to track node state and change it accordingly to
> some event
> (additonal ceph-osd, additional controller added to cluster, etc..).
> I think that it is generic scenario and our api should support such
> modifications.
>
> To track state of node we need to introduce new state - something in lines
> of "requires_update".
> And extend deployment selection logic to include nodes with this state, if
> deploy action will be invoked.
>
> What do you think about such feature? I would be grateful for any other
> cases.
>
> [1] https://bugs.launchpad.net/fuel/+bug/1368445
>
>
> ___
> 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] Cinder/Neutron plugins on UI

[Evgeniy L]

;> >
>> > So what do you think, will it work or no?
>> >
>> > On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Frankly speaking, I'm not sure on how 1st approach will even work.
>> >> What if plugin doesn't provide any checkboxes (and in most cases it
>> >> won't)? How should we determine in serializer, which plugins should be
>> >> applied while generating astute.yaml and tasks.yaml? Should we
>> >> autogenerate some stuff for plugins which are not even enabled and do
>> >> needless work?
>> >>
>> >> This looks too complicated for me from the backend side, and option
>> >> with enabling/disabling plugins in wizard for specific environment (we
>> >> can invent mechanism to disable them on env which is not deployed yet,
>> >> besides, for API it's just one PUT) is MUCH simpler and much more
>> >> obvious, as I see.
>> >>
>> >>
>> >>
>> >> On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
>> >>  wrote:
>> >> > Hi,
>> >> >
>> >> > I would go with the 1st approach. The thing I don't like in the 2nd
>> >> > approach
>> >> > is that we have to make the user enable plugin twice. For example, we
>> >> > have
>> >> > to enable Ceph as a plugin and then add Ceph role to nodes and choose
>> >> > what
>> >> > we want to store in Ceph (images, objects). Why we would need to
>> >> > explicitly
>> >> > enable Ceph plugin? Let's always show plugin options in wizard and
>> >> > settings
>> >> > tab, and if the user just doesn't want to enable Ceph, he would just
>> >> > leave
>> >> > all the checkboxes unchecked. The 2nd approach would also lead to
>> some
>> >> > kind
>> >> > of inconsistency in case the user enabled Ceph plugin but left all
>> the
>> >> > Ceph-related checkboxes unchecked and didn't add Ceph nodes.
>> >> >
>> >> > 2014-10-07 21:17 GMT+07:00 Evgeniy L :
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> We had a meeting today about plugins on UI, as result of the meeting
>> >> >> we have two approaches and this approaches affect not only UX but
>> >> >> plugins itself.
>> >> >>
>> >> >> 1st - disable/enable plugin on settings tab
>> >> >>
>> >> >> user installs the plugin
>> >> >> creates a cluster
>> >> >> configures and enables/disables plugins on settings tab
>> >> >>
>> >> >> For user it will look like Ceph plugin checkboxes on settings tab,
>> >> >> if he enables checkbox, then we pass the parameter to orchestrator
>> >> >> as `true`.
>> >> >>
>> >> >> Cons:
>> >> >>
>> >> >> plugin developer should define a checkbox in each plugin (for plugin
>> >> >> disabling/enabling)
>> >> >> on the backend we have to enable all of the plugins for environment,
>> >> >> because user can define any name for his checkbox and we won't be
>> able
>> >> >> to
>> >> >> find it and make appropriate mapping plugin <-> env
>> >> >> since all of the plugins are always "enabled" we have to run tasks
>> for
>> >> >> all
>> >> >> of the plugins, and each plugin should parse astute.yaml in order to
>> >> >> figure
>> >> >> out if it's required to run task current script
>> >> >>
>> >> >> Pros:
>> >> >>
>> >> >> it won't require additional setting or step for wizard
>> >> >> user will be able to disable plugin after environment creation
>> >> >>
>> >> >> 2nd - enable plugins in wizard
>> >> >>
>> >> >> user installs the plugin
>> >> >> now he can choose specific plugins for his environment in wizard
>> >> >> after cluster is created, he can configure additional parameters on
>> >> >> settings tab, if plugin provides any
>> >> >>
>> >&g

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

emovable (when they're not enabled in any deployed
>> environments), we
>> should at least leave room for that in the design.
>>
>> 2. Either level of plugin settings (enable or configure) may be exposed in
>> setup wizard, settings page, or both.
>>
>> - Yes, additional plugin settings also may show up in the wizard (e.g.
>> vCenter
>>   credentials).
>>
>> - Yes, we should maintain the settings page as the SSoT, and that means
>>   reflecting as many of setup wizard options in it as possible.
>>
>> - Yes, for some options (like choice of operating system or network
>> topology),
>>   our settings page is not dynamic enough to allow user to go back and
>> revert
>>   them without recreating the environment.
>>
>> - No, plugin writer shouldn't have to explicitly describe a checkbox to
>> enable
>>   their plugin. They only should provide name and description of the
>> plugin.
>>   Plugin engine should be able to produce a catalogue of installed
>> plugins, and
>>   UI should generate enable checkboxes from that catalogue.
>>
>> - If a plugin doesn't affect any available environment configuration
>> options
>>   outside of the settings tab (i.e. setup wizard, network settings, node
>> roles,
>>   disk & nic configuration), there's no reason to limit it to setup
>> wizard, the
>>   "enable" checkbox and whatever other options it has should all be
>> present in
>>   the settings page.
>>
>> - Do we have any plugins in 6.0 that have to be present in setup wizard
>> because
>>   they affect UI outside of settings page? I'm not aware of any.
>>
>> If so, lets start by representing all plugin settings in the settings
>> page. But
>> leave the room in the metadata to force some or all of plugin's settings
>> to
>> show up in the setup wizard (or even to present plugin configuration
>> options
>> differently in the wizard than in the settings).
>>
>> Just my $2,
>> -DmitryB
>>
>> On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov 
>> wrote:
>> > Vitaly,
>> >
>> > Once again, as a plugin developer I don't care about how Sahara or
>> Murano is
>> > implemented. I don't care about checkboxes, either. I just want one
>> simple
>> > command to run on target nodes and I should be provided with the
>> simplest
>> > possible interface to:
>> > 1) Write this command in some YAML and don't care about anything else
>> > 2) Enable my plugin for particular environment and see if it's really
>> > enabled both on UI and CLI (and through pure API by simple field
>> checking)
>> >
>> > If it provides some separate service - this doesn't change anything, I
>> just
>> > need it to be listed somewhere in "plugins" inside cluster data to know
>> that
>> > it'll be executed.
>> >
>> > How will it work with your approach?
>> >
>> > 08 Окт 2014 г. 20:00 пользователь "Vitaly Kramskikh"
>> >  написал:
>> >
>> >> Hi, responses inline.
>> >>
>> >> 2014-10-08 21:09 GMT+07:00 Evgeniy L :
>> >>>
>> >>> Hi,
>> >>>
>> >>> Vitaly, I understand your concerns about UX.
>> >>> But there are technical problems and statements which affect
>> >>> plugin developer and makes his live more complicated.
>> >>>
>> >>> My opinion is we definitely should know, if plugin is disabled
>> >>> or if it's enabled for specific environment.
>> >>>
>> >>> 1. plugin developer defines tasks, like "I want the script to be
>> >>> executed on nodes with controller role" and I don't think that
>> >>> he expects this task to be run on all of the nodes, also
>> >>> I don't think that we want ask plugin developer to parse
>> >>> yaml with bash in order to understand if his plugin is enabled,
>> >>> it's a bad design
>> >>
>> >> Bash script shouldn't be even run if the conditions to run it are not
>> met.
>> >> I described above how it could be done.
>> >>>
>> >>> 2. there will be no way to uninstall the plugin, because all of the
>> >>> plugins are enabled on the environments, even if user doesn't
>> >>> use them
>> >>
&

Re: [openstack-dev] [Fuel] Proposing Bogdan Dobrelia and Sergii Golovatiuk as core-reviewers for Fuel Library project

[Evgeniy L]

+1

On Fri, Oct 10, 2014 at 6:09 PM, Aleksandr Didenko 
wrote:

> +1 for both.
>
> On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky 
> wrote:
>
>> +1.
>>
>> On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin 
>> wrote:
>> > Hi, Fuelers
>> >
>> > As you may have noticed our project is growing continuously. And this
>> > imposes a requirement of increasing amount of core reviewers. I would
>> like
>> > to propose Bogdan Dobrelia(bogdando) and Sergii Golovatiuk(holser) as
>> core
>> > reviewers. As you know, they have been participating actively in
>> > development, design and code review of the majority of project
>> components as
>> > long as being our topmost reviewers and contributors (#2 and #3) [1 and
>> 2]
>> > (not to mention being just brilliant engineers and nice people).
>> >
>> > Please, reply to my message if you agree or disagree separately for
>> Bogdan
>> > and Sergii (this is mandatory for existing core-reviewers).
>> >
>> > [1] http://stackalytics.com/report/contribution/fuel-library/90
>> > [2] http://stackalytics.com/report/contribution/fuel-library/180
>> >
>> > --
>> > 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
>> >
>> > ___
>> > 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] [Fuel] Propose adding Igor K. to core reviewers for fuel-web projects

[Evgeniy L]

Hi everyone!

I would like to propose Igor Kalnitsky as a core reviewer on the
Fuel-web team. Igor has been working on openstack patching,
nailgun, fuel upgrade and provided a lot of good reviews [1]. In
addition he's also very active in IRC and mailing list.

Can the other core team members please reply with your votes
if you agree or disagree.

Thanks!

[1]
http://stackalytics.com/?project_type=stackforge&release=juno&module=fuel-web
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

Hi,

We've discussed what we will be able to do for the current release and
what we will not be able to implement.
We have not only technical problems, but also we don't have a lot of time
for implementation. We were trying to find solution which will work well
enough
with all of the constraints.
For the current release we want to implement approach which was suggested
by Mike.
We are going to generate for UI checkbox which defines if plugin is set for
deployment. In nailgun we'll be able to parse generated checkboxes and
remove or add relation between plugin and cluster models.
With this relation we'll be able to identify if plugins is used, it will
allow us
to remove the plugins if it's unused (in the future), or if we need to pass
tasks to orchestrator. Also in POC, we are going to implement something
really simple, like updating plugin attributes directly via api.

Thanks,

On Thu, Oct 9, 2014 at 8:13 PM, Dmitry Borodaenko 
wrote:

> Notes from the architecture review meeting on plugins UX:
>
>- separate page for plugins management
>- user installs the plugin on the master
>- global master node configuration across all environments:
>   - user can see a list of plugins on Plugins tab (plugins
>   description)
>   - Enable/Disable plugin
>  - should we enable/disable plugins globally, or only per
>  environment?
> - yes, we need a global plugins management page, it will
> later be extended to upload or remove plugins
>  - if a plugin is used in a deployed environment, options to
>  globally disable or remove that plugin are blocked
>   - show which environments (or a number of environments) have a
>   specific plugin enabled
>   - global plugins page is a Should in 6.0 (but easy to add)
>   - future: a plugin like ostf should have a deployable flag set to
>   false, so that it doesn't show up as an option per env
>- user creates new environment
>   - in setup wizard on the releases page (1st step), a list of
>   checkboxes for all plugins is offered (same page as releases?)
>  - all globally enabled plugins are checked (enabled) by default
>  - changes in selection of plugins will trigger regeneration of
>  subsequent setup wizard steps
>   - plugin may include a yaml mixin for settings page options in
>   openstack.yaml format
>  - in future releases, it will support describing setup wizard
>  (disk configuration, network settings etc.) options in the same way
>  - what is the simplest case? does plugin writer have to define
>  the plugin enable/disable checkbox, or is it autogenerated?
> - if plugin does not define any configuration options: a
> checkbox is automatically added into Additional Services section 
> of the
> settings page (disabled by default)
> - *problem:* if a plugin is enabled by default, but the
> option to deploy it is disabled by default, such environment 
> would count
> against the plugin (and won't allow to remove this plugin 
> globally) even
> though it actually wasn't deployed
>  - manifest of plugins enabled/used for an environment?
>
>
> We ended the discussion on the problem highlighted in bold above: what's
> the best way to detect which plugins are actually used in an environment?
>
>
> On Thu, Oct 9, 2014 at 6:42 AM, Vitaly Kramskikh 
> wrote:
>
>> Evgeniy,
>>
>> Yes, the plugin management page should be a separate page. As for
>> dependency on releases, I meant that some plugin can work only on Ubuntu
>> for example, so for different releases different plugins could be available.
>>
>> And please confirm that you also agree with the flow: the user install a
>> plugin, then he enables it on the plugin management page, and then he
>> creates an environment and on the first step he can uncheck some plugins
>> which he doesn't want to use in that particular environment.
>>
>> 2014-10-09 20:11 GMT+07:00 Evgeniy L :
>>
>>> Hi,
>>>
>>> Vitaly, I like the idea of having separate page, but I'm not sure if it
>>> should be on releases page.
>>> Usually a plugin is not release specific, usually it's environment
>>> specific and you can have
>>> different set of plugins for different environments.
>>>
>>> Also I don't think that we should enable plugins by default, user should
>>> enable plugin if he wants
>>> it to be installed.
>>>
>>> Thanks,
>>>
>>> On Thu, Oct 9, 2014 at 3:34 PM, Vitaly K

Re: [openstack-dev] [Fuel] Cinder/Neutron plugins on UI

[Evgeniy L]

Hi Mike,

Dmitry S. started to work on checkboxes auto-generation in nailgun
for UI.
And in parallel I've written simple script which just updates release
model with checkboxes and plugin's fields, this simple script will be used
only for POC, and then we will replace it with Dmitry's implementation when
it's ready.

Thanks,

On Tue, Oct 14, 2014 at 10:50 PM, Mike Scherbakov 
wrote:

> +1 for doing now:
> > we are going to implement something really simple, like updating plugin
> attributes directly via api.
> Then we can have discussions in parallel how we plan to evolve it.
>
> Please confirm that we went this path.
>
> Thanks,
>
>
> On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> We've discussed what we will be able to do for the current release and
>> what we will not be able to implement.
>> We have not only technical problems, but also we don't have a lot of time
>> for implementation. We were trying to find solution which will work well
>> enough
>> with all of the constraints.
>> For the current release we want to implement approach which was suggested
>> by Mike.
>> We are going to generate for UI checkbox which defines if plugin is set
>> for
>> deployment. In nailgun we'll be able to parse generated checkboxes and
>> remove or add relation between plugin and cluster models.
>> With this relation we'll be able to identify if plugins is used, it will
>> allow us
>> to remove the plugins if it's unused (in the future), or if we need to
>> pass
>> tasks to orchestrator. Also in POC, we are going to implement something
>> really simple, like updating plugin attributes directly via api.
>>
>> Thanks,
>>
>> On Thu, Oct 9, 2014 at 8:13 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> Notes from the architecture review meeting on plugins UX:
>>>
>>>- separate page for plugins management
>>>- user installs the plugin on the master
>>>- global master node configuration across all environments:
>>>   - user can see a list of plugins on Plugins tab (plugins
>>>   description)
>>>   - Enable/Disable plugin
>>>  - should we enable/disable plugins globally, or only per
>>>  environment?
>>> - yes, we need a global plugins management page, it will
>>> later be extended to upload or remove plugins
>>>  - if a plugin is used in a deployed environment, options to
>>>  globally disable or remove that plugin are blocked
>>>   - show which environments (or a number of environments) have a
>>>   specific plugin enabled
>>>   - global plugins page is a Should in 6.0 (but easy to add)
>>>   - future: a plugin like ostf should have a deployable flag set to
>>>   false, so that it doesn't show up as an option per env
>>>- user creates new environment
>>>   - in setup wizard on the releases page (1st step), a list of
>>>   checkboxes for all plugins is offered (same page as releases?)
>>>  - all globally enabled plugins are checked (enabled) by default
>>>  - changes in selection of plugins will trigger regeneration of
>>>  subsequent setup wizard steps
>>>   - plugin may include a yaml mixin for settings page options in
>>>   openstack.yaml format
>>>  - in future releases, it will support describing setup wizard
>>>  (disk configuration, network settings etc.) options in the same way
>>>  - what is the simplest case? does plugin writer have to define
>>>  the plugin enable/disable checkbox, or is it autogenerated?
>>> - if plugin does not define any configuration options: a
>>> checkbox is automatically added into Additional Services 
>>> section of the
>>> settings page (disabled by default)
>>> - *problem:* if a plugin is enabled by default, but the
>>> option to deploy it is disabled by default, such environment 
>>> would count
>>> against the plugin (and won't allow to remove this plugin 
>>> globally) even
>>> though it actually wasn't deployed
>>>  - manifest of plugins enabled/used for an environment?
>>>
>>>
>>> We ended the discussion on the problem highlighted in bold above: what's
>>> the best way to detect which plugins are actually use

Re: [openstack-dev] [Fuel] Pluggable framework in Fuel: first prototype ready

[Evgeniy L]

in plugin builders for certain versions of Fuel.
> Speaking about Fuel Client - there is no mistake. It's been discussed
> dozens of times, it's just lack of resources to make it on PyPI as well as
> to fix a few other things. I hope it could be done as part of efforts from
> [2].
>
> - Perhaps we have a separate settings tab just for Plug-Ins?For some
>> complex plug-ins, they might require a dedicated tab.   If we have too many
>> tabs it could get messy.
>
>
>
>> Shall we consider a separate place in UI (tab) for plugins? Settings tab
>> seems to be overloaded.
>
>
> This is certainly under planning and discussion for future releases. See
> [1], for example. For 6.0, we agreed that we can just extend existing
> Settings tab with plugins-related fields.
>
> One minor thing from me, which I forgot to mention during the demo:
> verbosity of fpb run. I understand it might sound like a bikeshedding now,
> but I believe if we develop it right from the very beginning, then we can
> save some time later. So I would suggest normal, short INFO output, and
> verbose one with --debug.
>
> Thanks for feedback folks!!!
>
> [1]
> https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37196.html
> [2]
> https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37001.html
>
>
> -- Forwarded message --
> From: Nathan Trueblood 
> Date: Sat, Oct 18, 2014 at 3:24 AM
> Subject: Re: plugins
>
> Agreed - I thought this initial PoC was great.
>
> A few initial thoughts about settings in the UI and plug-in in general:
>
> - Perhaps we have a separate settings tab just for Plug-Ins?For some
> complex plug-ins, they might require a dedicated tab.   If we have too many
> tabs it could get messy.
> - It seems like we should consider how we handle the VMWare settings in
> light of plug-ins as well.   Since with VMWare we have a lot of setting to
> configure and settings validation.
> - Do we offer any kind of validation for settings on plug-ins?   Or some
> way to for the developer to ensure that setting that cannot be default or
> computed get requested for the plug-in?
>
> - We need to think carefully about both the plug-in developer experience
> (how hard to test, get error messages, etc) and the experience for the user
> who deploys the plug-in into an environment.
>
>
> -Nathan
>
> On Fri, Oct 17, 2014 at 4:13 PM, Roman Alekseenkov <
> ralekseen...@mirantis.com> wrote:
>>
>>
>> I watched both videos (creating a file with the text from UI &&
>> installing and starting a service).
>>
>> It looks pretty good!! Some initial feedback/questions:
>>
>>1. I like the fact that fuel plugin builder appends version to the
>>name and makes it "fuel-awesome-plugin-1.2.3.tar". The approach is similar
>>to Java/Maven and is a good one.
>>2. I feel like we should not require user to unpack the plugin before
>>installing it. Moreover, we may chose to distribute plugins in our own
>>format, which we may potentially change later. E.g. "lbaas-v2.0.fp". I'd
>>rather stick with two actions:
>>   - Assembly (externally): fpb --build 
>>   - Installation (on master node): fuel --install-plugin 
>>3. How are we planning to distribute fuel plugin builder and its
>>updates? Ideally, it should be available externally (outside of master
>>node). I don't want us to repeat the same mistake as we did with Fuel
>>client, which doesn't seem to be usable as an external dependency.
>>4. How do we handle errors?
>>   - What happens if an error occurs during plugin installation?
>>   - What happens if an error occurs during plugin execution? Does it
>>   (should it?) fail the deployment? Will we show user an error message 
>> with
>>   the name of plugin that failed?
>>   5. Shall we consider a separate place in UI (tab) for plugins?
>>Settings tab seems to be overloaded.
>>6. When are we planning to focus on the 2 plugins which were
>>identified as must-haves for 6.0? Cinder & LBaaS
>>
>> Once again, great job guys!
>>
>> Thanks,
>> Roman
>>
>> On Fri, Oct 17, 2014 at 9:32 AM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Thanks, Evgeny, excellent work!
>>> Roman, I believe we are "green" with the feature. Watch yourself.
>>>
>>> Mike Scherbakov
>>> #mihgen
>>> On Oct 17, 2014 8:25 PM, "Evgeniy L"  wrote:
>>>
>>>> Hi guys, here are the videos from the demo
>>>>
>>>> Part 1
>>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXUGY1QVYyX3NLTWc/view
>>>>
>>>> Part 2
>>>> https://drive.google.com/file/d/0B7I3b5vI7ZYXWkRmV05fT1VEQkk/view
>>>>
>>>> Thanks,
>>>>
>>>>
>>
>
> --
> 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

Re: [openstack-dev] [Fuel] Pluggable framework in Fuel: first prototype ready

[Evgeniy L]

Hi Mike,

I would like to add a bit more details about current implementation and how
it can be done.

*Implement installation as a scripts inside of tar ball:*
Cons:
* install script is really simple right now, but it will be much more
complicated
** it requires to implement logic where we can ask user for login/password
** use some config, where we will be able to get endpoints, like where is
keystone, nailgun
** validate that it's possible to install plugin on the current version of
master
** handle error cases (to make installation process more atomic)
* it will be impossible to deprecate the installation logic/method, because
it's on the plugin's side
  and you cannot change a plugin which user downloaded some times ago, when
we get
  plugin manager, we probably would like user to use plugin manager,
instead of some scripts
* plugin installation process is not so simple as it could be (untar, cd
plugin, ./install)

Pros:
* plugin developer can change installation scripts (I'm not sure if it's a
pros)

*Add installation to fuel client:*
Cons:
* requires changes in fuel client, which are not good for fuel client by
design (fuel client
  should be able to work remotely from user's machine), current
implementation requires
  local operations on files, it will be changed in the future releases, so
fuel-client will
  be able to do it via api, also we can determine if it's not master node
by /etc/fuel/version.yaml
  and show the user a message which says that in the current version it's
not possible
  to install the plugin remotely
* plugin developer won't be able to change installation process (I'm not
sure if it's a cons)

Pros:
* it's easier for user to install the plugin `fuel --install-plugin
plugin_name-1.0.1.fpb'
* all of the authentication logic already implemented in fuel client
* fuel client uses config with endpoints which is generated by puppet
* it will be easier to deprecate previous installation approach, we can
just install new
  fuel client on the master which uses api

Personally I like the second approach, and I think we should try to
implement it,
when we get time.

Thanks,

On Thu, Oct 23, 2014 at 3:02 PM, Mike Scherbakov 
wrote:

>
>>1. I feel like we should not require user to unpack the plugin before
>>installing it. Moreover, we may chose to distribute plugins in our own
>>format, which we may potentially change later. E.g. "lbaas-v2.0.fp". I'd
>>rather stick with two actions:
>>
>>
>>- Assembly (externally): fpb --build 
>>
>>
>>- Installation (on master node): fuel --install-plugin 
>>
>>  I like the idea of putting plugin installation functionality in fuel client,
>> which is installed
>> on master node.
>> But in the current version plugin installation requires files operations
>> on the master,
>> as result we can have problems if user's fuel-client is installed on
>> another env.
>
>
> I suggest to keep it simple for now as we have the issue mentioned by
> Evgeny: fuel client is supposed to work from other nodes, and we will need
> additional verification code in there. Also, to make it smooth, we will
> have to end up with a few more checks - like what if tarball is broken,
> what if we can't find install script in it, etc.
> I'd suggest to run it simple for 6.0, and then we will see how it's being
> used and what other limitations / issues we have around plugin installation
> and usage. We can consider to make this functionality as part of fuel
> client a bit later.
>
> Thanks,
>
> On Tue, Oct 21, 2014 at 6:57 PM, Vitaly Kramskikh  > wrote:
>
>> Hi,
>>
>> As for a separate section for plugins, I think we should not force it and
>> leave this decision to a plugin developer, so he can create just a single
>> checkbox or a section of the settings tab or a separate tab depending on
>> plugin functionality. Plugins should be able to modify arbitrary release
>> fields. For example, if Ceph was a plugin, it should be able to extend
>> wizard config to add new options to Storage pane. If vCenter was a plugin,
>> it should be able to set maximum amount of Compute nodes to 0.
>>
>> 2014-10-20 21:21 GMT+07:00 Evgeniy L :
>>
>>> Hi guys,
>>>
>>> *Romans' questions:*
>>>
>>> >> I feel like we should not require user to unpack the plugin before
>>> installing it.
>>> >> Moreover, we may chose to distribute plugins in our own format, which
>>> we
>>> >> may potentially change later. E.g. "lbaas-v2.0.fp".
>>>
>>> I like the idea of putting plugin installation functionality in fuel
>>> client, which 

Re: [openstack-dev] [Fuel] Fuel plugins feedback

[Evgeniy L]

Hi Dmitry,

Thank you for being beta tester and for your feedback :)

On Wed, Oct 29, 2014 at 11:05 AM, Dmitry Ukov  wrote:

> All,
> Recently I have tried plugins feature which was implemented for 6.x
> release. And that was really pleasant experience. Plugins work almost
> out-of-the box. I was able to implement Cinder with NetApp backend
> installation and configuration as a separate Fuel plugin.
>
> Current simple implementation (with pre- and post-deployment
> customizations) covers around 30% of our use cases. Obviously this will
> cover all cases that require OpenStack configuration file changes (e.g.
> custom Cinder backend, LDAP integration e.t.c).
>
> Next things that will cover  significant amount of our use cases is
> ability to add custom roles and modify node provisioning parameters. I'm
> looking forward to trying those features out.
>
> I'd like to thank Fuel team for implementation such desirable feature.
> Plugins will definitely  help to increase flexibility of MOS. Great job!
>
> --
> Kind regards
> Dmitry Ukov
> IT Engineer
> Mirantis, Inc.
>
>
> ___
> 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] Test runner for python tests and parallel execution

[Evgeniy L]

Hi Dmitry,

Thank you for bringing it up, it's not only about CI, it really takes
a lot of developers time to run Nailgun unit/integration tests on local
machine, and it's must have priority task in technical debt scope.

Personally I'm ok with py.test, but we should improve db creation mechanism
in your patch to use psycopg2 instead of running psql in subprocess.

Thanks,

On Fri, Nov 7, 2014 at 5:35 PM, Dmitriy Shulyak 
wrote:

> Hi guys,
> Long time ago i've made patch [1] which added tests distribution between
> processes and databases.  It was simple py.test configuration which allows
> us to reduce time of test execution almost linearly, on my local machine
> one test run (distributed over 4 cores) takes 250 seconds.
>
> At that time idea of using py.test was discarded, because:
> 1. it is neither nosetests
> 2. nor openstack community way (testrepository)
>
> There is plugin for nosetests which adds multiprocessing support (maybe it
> is even included in default distribution) but i wasnt able to find a normal
> way of distribution over databases, just because runner doesnot include
> necessery config options like RUNNER_ID. I cant stop you
> from trying - so please share your results, if you will find a nice and
> easy way to make it work.
>
> As for testrepository - if you have positive experience using this tool,
> share them, from my point of view it has very bad UX.
>
> Please consider trying py.test [2], i bet you will notice difference in
> reporting, and maybe will use it yourself for day-to-day test executions.
> Additionally there is very good
> system for parametrizing tests and writing extensions.
>
> The goal of this letter is to solve problem of CI queues for fuel-web
> project, so please
> share your opinions, It will be nice to solve this at the start of next
> week.
>
> [1] https://review.openstack.org/#/c/82284/3/nailgun/conftest.py
> [2] http://pytest.readthedocs.org/en/2.1.0/
>
> ___
> 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] Separate code freeze for repos

[Evgeniy L]

Hi,

>> There was an idea to make a separate code freeze for repos

Could you please clarify what do you mean?

I think we should have a way to merge patches for the next
release event if it's code freeze for the current.

Thanks,

On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh 
wrote:

> Folks,
>
> There was an idea to make a separate code freeze for repos, but we decided
> not to do it. Do we plan to try it this time? It is really painful to
> maintain multi-level tree of dependent review requests and wait for a few
> weeks until we can merge new stuff in master.
>
> --
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dev mode implementation

[Evgeniy L]

Hi Sergii,

Sorry, but I don't like the idea of creating yet another type of iso, it
will complicate debugging process (because of different environments).

Disable authentication - if we have a feature, we should not disable it,
during the development we need to make sure that this feature works fine
with any other features which we are working on.

If we want to solve this problem, I think it will be better to create some
scripts to make your env more developer friendly i.e. install nc, iperf,
tcpdump, systemtap.


On Tue, Jul 8, 2014 at 11:39 PM, Sergii Golovatiuk  wrote:

> Hi crew,
>
> There is no functioning "dev" mode as of right now in the Fuel ISO build.
> Authentication feature  makes developer's life even more painful.  A lot of
> tests must be rewritten to pass authentication. Manual testing will be
> slowed down as it will require additional steps. This complicates many
> things we do. "Dev" mode should slightly modify ISO for development use.
> Here are the features we should turn on in 'dev" mode
>
> 1. Disable authentication
> 2. Development packages should be added (nc, iperf, tcpdump, systemtap)
> 3. Extra verbosity should be turned on. CoreDumps should be enabled and
> analyzed.
> 4. Special OpenStack flavors (m1.tiny should be 128MB instead of 512MB)
> 5. Additional messages in REST/JSON or any other API
>
> If you have anything to add please bring that to our attention so we'll
> try to cover your wishlist in blueprint.
>
> Thank you.
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> ___
> 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] Upgrade of netchecker/mcagents during OpenStack patching procedure

[Evgeniy L]

Hi,

I want to discuss here several bugs

1. Do we want to upgrade (deliver new packages) for netchecker and
mcagents? [1]

If yes, then we have to add a list of packages which are
installed on provisioning stage (e.g. netchecker/mcagent/something else)
in puppet, to run patching for this packages.

2. After master node upgrade (from 5.0 to 5.0.1/5.1) Murana test is still
disabled [2]
for old clusters, despite the fact that the test was fixed in 5.0.1/5.1 and
works on
clusters which were created after upgrade.

I'm not an expert in OSTF, are there any suggestions how to fix it? Who we
can
assign this bug to?

[1] https://bugs.launchpad.net/fuel/+bug/1343139
[2] https://bugs.launchpad.net/fuel/+bug/1337823
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Authentication is turned on - Fuel API and UI

[Evgeniy L]

Hi,

I have several concerns about password changing.

>> Default password can be changed via UI or via fuel-cli. In case of
changing password via UI or fuel-cli password is not stored in any file
only in keystone

It's important to change password in /etc/fuel/astute.yaml
otherwise it will be impossible for user to run upgrade,

1. upgrade system uses credentials from /etc/fuel/astute.yaml
to authenticate in nailgun
2. upgrade system runs puppet to upgrade dockerctl/fuelclient
on the host system, puppet uses credentials from /etc/fuel/astute.yaml
to update config /etc/fuel/client/config.yaml [1], even if user changed
the password in the config for fuelclient, it will be overwritten after
upgrade

If we don't want to change credentials in /etc/fuel/astute.yaml
lets at least add some warning in the documentation.

[1]
https://github.com/stackforge/fuel-library/blob/705dc089037757ed8c5a25c4cf78df71f9bd33b0/deployment/puppet/nailgun/examples/host-only.pp#L51-L55



On Thu, Jul 24, 2014 at 6:17 PM, Lukasz Oles  wrote:

> Hi all,
>
> one more thing. You do not need to install keystone in your development
> environment. By default it runs there in fake mode. Keystone mode is
> enabled only on iso. If you want to test it locally you have to install
> keystone and configure nailgun as Kamil explained.
>
> Regards,
>
>
> On Thu, Jul 24, 2014 at 3:57 PM, Mike Scherbakov  > wrote:
>
>> Kamil,
>> thank you for the detailed information.
>>
>> Meg, do we have anything documented about authx yet? I think Kamil's
>> email can be used as a source to prepare user and operation guides for Fuel
>> 5.1.
>>
>> Thanks,
>>
>>
>> On Thu, Jul 24, 2014 at 5:45 PM, Kamil Sambor 
>> wrote:
>>
>>> Hi folks,
>>>
>>> All parts of code related to stage I and II from blueprint
>>> http://docs-draft.openstack.org/29/96429/11/gate/gate-fuel-specs-docs/2807f30/doc/build/html/specs/5.1/access-control-master-node.htm
>>> 
>>>  are
>>> merged. In result of that, fuel (api and UI)  we now have
>>> authentication via keystone and now is required as default. Keystone is
>>> installed in new container during master installation. We can configure
>>> password via fuelmenu during installation (default user:password -
>>> admin:admin). Password is saved in astute.yaml, also admin_token is stored
>>> here.
>>> Almost all endpoints in fuel are protected and they required
>>> authentication token. We made exception for few endpoints and they are
>>> defined in nailgun/middleware/keystone.py in public_url .
>>> Default password can be changed via UI or via fuel-cli. In case of
>>> changing password via UI or fuel-cli password is not stored in any file
>>> only in keystone, so if you forgot password you can change it using
>>> keystone client from master node and admin_token from astute.yaml using
>>> command: keystone --os-endpoint=http://10.20.0.2:35357/v2.0 
>>> --os-token=admin_token
>>> password-update .
>>> Fuel client now use for authentication user and passwords which are
>>> stored in /etc/fuel/client/config.yaml. Password in this file is not
>>> changed during changing via fuel-cli or UI, user must change this password
>>> manualy. If user don't want use config file can provide user and password
>>> to fuel-cli by flags: --os-username=admin --os-password=test. We added also
>>> possibilities to change password via fuel-cli, to do this we should
>>> execute: fuel user --change-password --new-pass=new .
>>> To run or disable authentication we should change
>>> /etc/nailgun/settings.yaml (AUTHENTICATION_METHOD) in nailgun container.
>>>
>>> Best regards,
>>> Kamil S.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Łukasz Oleś
>
> ___
> 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] Authentication is turned on - Fuel API and UI

[Evgeniy L]

Hi,

1. yes, we can do it, if it's possible to create new user with admin_token.
But it will complicate upgrade process and will take some time to
design/implement and test, because I see several new cases, for example we
need to create new user in previous version of the container (we use
nailgun api before upgrade too), and then in new container, and in case of
rollback delete it from previous container.

2. afaik, this config is not in the container, it's on the host system, and
it will be replaced by puppet on the host system


On Mon, Jul 28, 2014 at 6:37 PM, Lukasz Oles  wrote:

> As I said in another topic, storing user password in plain text is not an
> option.
>
> Ad. 1.
> We can create special "upgrade_user" with the same rights as admin user.
> We can use it to authenticate in nailgun. It can be done after 5.1 release.
>
> Ad. 2.
> In perfect world during upgrade /etc/fuel/client/config.yaml should be
> copied to new container. If it's not possible, warning in documentation
> should be ok.
>
> Regards
>
>
> On Mon, Jul 28, 2014 at 3:59 PM, Mike Scherbakov  > wrote:
>
>> Lukasz,
>> what do you think on this? Is someone addressing the issues mentioned by
>> Evgeny?
>>
>> Thanks,
>>
>>
>> On Fri, Jul 25, 2014 at 3:31 PM, Evgeniy L  wrote:
>>
>>> Hi,
>>>
>>> I have several concerns about password changing.
>>>
>>> >> Default password can be changed via UI or via fuel-cli. In case of
>>> changing password via UI or fuel-cli password is not stored in any file
>>> only in keystone
>>>
>>> It's important to change password in /etc/fuel/astute.yaml
>>> otherwise it will be impossible for user to run upgrade,
>>>
>>> 1. upgrade system uses credentials from /etc/fuel/astute.yaml
>>> to authenticate in nailgun
>>> 2. upgrade system runs puppet to upgrade dockerctl/fuelclient
>>> on the host system, puppet uses credentials from
>>> /etc/fuel/astute.yaml
>>> to update config /etc/fuel/client/config.yaml [1], even if user
>>> changed
>>> the password in the config for fuelclient, it will be overwritten
>>> after upgrade
>>>
>>> If we don't want to change credentials in /etc/fuel/astute.yaml
>>> lets at least add some warning in the documentation.
>>>
>>> [1]
>>> https://github.com/stackforge/fuel-library/blob/705dc089037757ed8c5a25c4cf78df71f9bd33b0/deployment/puppet/nailgun/examples/host-only.pp#L51-L55
>>>
>>>
>>>
>>> On Thu, Jul 24, 2014 at 6:17 PM, Lukasz Oles  wrote:
>>>
>>>> Hi all,
>>>>
>>>> one more thing. You do not need to install keystone in your development
>>>> environment. By default it runs there in fake mode. Keystone mode is
>>>> enabled only on iso. If you want to test it locally you have to install
>>>> keystone and configure nailgun as Kamil explained.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On Thu, Jul 24, 2014 at 3:57 PM, Mike Scherbakov <
>>>> mscherba...@mirantis.com> wrote:
>>>>
>>>>> Kamil,
>>>>> thank you for the detailed information.
>>>>>
>>>>> Meg, do we have anything documented about authx yet? I think Kamil's
>>>>> email can be used as a source to prepare user and operation guides for 
>>>>> Fuel
>>>>> 5.1.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> On Thu, Jul 24, 2014 at 5:45 PM, Kamil Sambor 
>>>>> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> All parts of code related to stage I and II from blueprint
>>>>>> http://docs-draft.openstack.org/29/96429/11/gate/gate-fuel-specs-docs/2807f30/doc/build/html/specs/5.1/access-control-master-node.htm
>>>>>> <http://docs-draft.openstack.org/29/96429/11/gate/gate-fuel-specs-docs/2807f30/doc/build/html/specs/5.1/access-control-master-node.html>
>>>>>>  are
>>>>>> merged. In result of that, fuel (api and UI)  we now have
>>>>>> authentication via keystone and now is required as default. Keystone is
>>>>>> installed in new container during master installation. We can configure
>>>>>> password via fuelmenu during installation (default user:password -
>>>>>> admin:admin). Password is saved in astute.yaml, also admin_token is 
>>>>>>

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Evgeniy L]

Hi,

The main reason why I think we should get all of the three states is we
don't know exactly if those plugins (which developer didn't specify) are
compatible or not, so we should not make any assumptions and prevent
the user from enabling any plugins she/he wants. The best we can do here
is to provide all of the information plugin developer knows, directly to
the user,
without us in the middle who make decisions based on incomplete data.

So lets ask plugin developer to specify a set of components which he tested
his plugin with. Plus a list of components which he tested with and he is
sure
that those are not going to working together.

On UI we can show explicitly, that this combination is tested and approved
to
be working, another combination is not working for sure (plugin developers
tested
it and explicitly specified), and there will be a lot of combination which
are going
to work together without problems, but we should say the user, that the
developer
didn't test it and he should test and use it carefully.

Thanks,

On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
wrote:

> Hi fuelers,
>
> Currently we are working on feature component registry [1] which should
> help us to prevent not logical compositions of different components in
> wizard tab during cluster(environment) creation. Now we have a mechanizm
> of 'restrictions' which is not flexible for components provided by
> plugins. In our current approach we have two states for components -
> compatible/incompatible which are described in compatibility matrix
> based on OpenStack components (For example: cinder-vmware storage only
> compatible with vCetner hypervisor and should work when only KVM uses).
> In this case we allow user to choose only that components we defently
> know works well with each other. Another approach tell us to have 3
> states: compatible/incompatible/ and all other components about
> compatibility with others we know nothing. In that case we should show
> on wizard which components compatible, which not, and others which user
> can enable on his own risk. So I need your opinions: should we allow for
> user choose only that coponents which are tested and defently works or
> prevent her/him from choosing which are defently not works and means
> potentional risk of failing deployment when component about we know
> nothing isn't work together.
>
>
>
> [1] https://blueprints.launchpad.net/fuel/+spec/component-registry
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'

[Evgeniy L]

Hi,

I believe we don't have any VirtualBox specific hacks, especially in terms
of
database configuration. By "development env" Vitaly meant fake UI, when
developer installs and configures the database by himself, without any iso
images, so probably his db is configured correctly with utf-8.

Also we should make sure that upgrade works correctly, after the problem is
fixed.

Thanks,

On Wed, Nov 4, 2015 at 2:30 PM, Artem Roma  wrote:

> Hi, folks!
>
> Recently I've been working on this bug [1] and have found that default
> encoding of database server used by FUEL infrastructure components
> (Nailgun, OSTF, etc) is ascii. At least this is true for environment set up
> via VirtualBox scripts. This situation may (and already does returning to
> the bug) cause obfuscating problems when dealing with non-ascii string data
> supplied by user such as names for nodes, clusters etc. Nailgun encodes
> such data in UTF-8 before sending to the database so misinterpretation by
> former while saving it is sure thing.
>
> I wonder if we have such situation on all Fuel environments or only on
> those set by VB scripts, because as for me it seems as pretty serious flaw
> in our infrastructure. It would be great to have some comments from people
> more competent in areas regarding to the matter.
>
> ​[1]​ https://bugs.launchpad.net/fuel/+bug/1472275
>
> --
> Regards!)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

[Evgeniy L]

Hi Javeria,

As far as I know there is no way to run the task on Fuel master host itself.
Since MCollective is installed in the container and tasks get executed using
MCollective, as a workaround you may try to ssh from the container to the
host.

Also I have several additional questions:
1. what version of Fuel do you use?
2. could you please clarify what did you mean by "moving to
deployment_tasks.yaml"?
3. could you please describe your use-case a bit more? Why do you want to
run
tasks on the host itself?

Thanks,

On Wed, Nov 4, 2015 at 11:25 PM, Javeria Khan  wrote:

> Thanks Igor, Alex. Guess there isn't any support for running tasks
> directly on the Fuel Master node for now.
>
> I did try moving to deployment_tasks.yaml, however it leads to other
> issues such as "/etc/fuel/plugins// does not exist" failing on
> deployments.
>
> I'm trying to move back to using the former tasks.yaml, but the
> fuel-plugin-builder keeps looking for deployment_tasks.yaml now. There
> should be some build source list I can remove?
>
>
> --
> Javeria
>
> On Wed, Nov 4, 2015 at 12:44 PM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> please note that such tasks are executed inside 'mcollective' docker
>> container, not on the Fuel master host system.
>>
>> Regards,
>> Alex
>>
>> On Tue, Nov 3, 2015 at 10:41 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Hi Javeria,
>>>
>>> Try to use 'master' in 'role' field. Example:
>>>
>>> - role: 'master'
>>>   stage: pre_deployment
>>>   type: shell
>>>   parameters:
>>>   cmd: echo all > /tmp/plugin.all
>>>   timeout: 42
>>>
>>> Let me know if you need additional help.
>>>
>>> Thanks,
>>> Igor
>>>
>>> P.S: Since Fuel 7.0 it's recommended to use deployment_tasks.yaml
>>> instead of tasks.yaml. Please see Fuel Plugins wiki page for details.
>>>
>>> On Tue, Nov 3, 2015 at 10:26 PM, Javeria Khan 
>>> wrote:
>>> > Hey everyone,
>>> >
>>> > I've been working on a fuel plugin and for some reason just cant
>>> figure out
>>> > how to run a task on the fuel master node through the tasks.yaml. Is
>>> there
>>> > even a role for it?
>>> >
>>> > Something similar to what ansible does with localhost would work.
>>> >
>>> > Thanks,
>>> > Javeria
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

[Evgeniy L]

Javeria,

In your case, I think it's easier to generate config on the target node,
using puppet for example, since the information which you may need
is placed in /etc/astute.yaml file. Also it may be a problem to retrieve
all required information about the cluster, since API is protected with
keystone authentication.

Thanks,

On Thu, Nov 5, 2015 at 5:35 PM, Javeria Khan  wrote:

> Hi Evgeniy,
>
>>
>> 1. what version of Fuel do you use?
>>
> Using 7.0
>
>
>> 2. could you please clarify what did you mean by "moving to
>> deployment_tasks.yaml"?
>>
> I tried changing my tasks.yaml to a deployment_tasks.yaml as the wiki
> suggests for 7.0. However I kept hitting issues.
>
>
>> 3. could you please describe your use-case a bit more? Why do you want to
>> run
>> tasks on the host itself?
>>
>
> I have a monitoring tool that accompanies my new plugin, which basically
> uses a config file that contains details about the cluster (IPs, VIPs,
> networks etc). This config file is typically created on the installer nodes
> through the deployment, Fuel Master in this case.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

[Evgeniy L]

Great, let us know, if you have any problems.

Also for the future we have some ideas/plans to provide a way for
a plugin to retrieve any information from API.

Thanks,

On Fri, Nov 6, 2015 at 12:16 PM, Javeria Khan  wrote:

> Thank Evgeniy.  I came to the same conclusion.
>
>
> --
> Javeria
>
> On Fri, Nov 6, 2015 at 1:41 PM, Evgeniy L  wrote:
>
>> Javeria,
>>
>> In your case, I think it's easier to generate config on the target node,
>> using puppet for example, since the information which you may need
>> is placed in /etc/astute.yaml file. Also it may be a problem to retrieve
>> all required information about the cluster, since API is protected with
>> keystone authentication.
>>
>> Thanks,
>>
>> On Thu, Nov 5, 2015 at 5:35 PM, Javeria Khan 
>> wrote:
>>
>>> Hi Evgeniy,
>>>
>>>>
>>>> 1. what version of Fuel do you use?
>>>>
>>> Using 7.0
>>>
>>>
>>>> 2. could you please clarify what did you mean by "moving to
>>>> deployment_tasks.yaml"?
>>>>
>>> I tried changing my tasks.yaml to a deployment_tasks.yaml as the wiki
>>> suggests for 7.0. However I kept hitting issues.
>>>
>>>
>>>> 3. could you please describe your use-case a bit more? Why do you want
>>>> to run
>>>> tasks on the host itself?
>>>>
>>>
>>> I have a monitoring tool that accompanies my new plugin, which basically
>>> uses a config file that contains details about the cluster (IPs, VIPs,
>>> networks etc). This config file is typically created on the installer nodes
>>> through the deployment, Fuel Master in this case.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Master node upgrade

[Evgeniy L]

Hi Vladimir,

Cannot say anything about 1st option, which is to use official Centos
scripts,
because I'm not familiar with the procedure, but since our installation is
not
really Centos, I have doubts that it's going to work correctly.

2nd option looks less risky. Also we should decide when to run containers
upgrade + host upgrade? Before or after new CentOS is installed? Probably
it should be done before we run backup, in order to get the latest scripts
for
backup/restore actions.

Thanks,

On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> At the moment I'm working on deprecating Fuel upgrade tarball. Currently,
> it includes the following:
>
> * RPM repository (upstream + mos)
> * DEB repository (mos)
> * openstack.yaml
> * version.yaml
> * upgrade script itself (+ virtualenv)
>
> Apart from upgrading docker containers this upgrade script makes copies of
> the RPM/DEB repositories and puts them on the master node naming these
> repository directories depending on what is written in openstack.yaml and
> version.yaml. My plan was something like:
>
> 1) deprecate version.yaml (move all fields from there to various places)
> 2) deliver openstack.yaml with fuel-openstack-metadata package
> 3) do not put new repos on the master node (instead we should use online
> repos or use fuel-createmirror to make local mirrors)
> 4) deliver fuel-upgrade package (throw away upgrade virtualenv)
>
> Then UX was supposed to be roughly like:
>
> 1) configure /etc/yum.repos.d/nailgun.repo (add new RPM MOS repo)
> 2) yum install fuel-upgrade
> 3) /usr/bin/fuel-upgrade (script was going to become lighter, because
> there should have not be parts coping RPM/DEB repos)
>
> However, it turned out that Fuel 8.0 is going to be run on Centos 7 and it
> is not enough to just do things which we usually did during upgrades. Now
> there are two ways to upgrade:
> 1) to use the official Centos upgrade script for upgrading from 6 to 7
> 2) to backup the master node, then reinstall it from scratch and then
> apply backup
>
> Upgrade team is trying to understand which way is more appropriate.
> Regarding to my tarball related activities, I'd say that this package based
> upgrade approach can be aligned with (1) (fuel-upgrade would use official
> Centos upgrade script as a first step for upgrade), but it definitely can
> not be aligned with (2), because it assumes reinstalling the master node
> from scratch.
>
> Right now, I'm finishing the work around deprecating version.yaml and my
> further steps would be to modify fuel-upgrade script so it does not copy
> RPM/DEB repos, but those steps make little sense taking into account Centos
> 7 feature.
>
> Colleagues, let's make a decision about how we are going to upgrade the
> master node ASAP. Probably my tarball related work should be reduced to
> just throwing tarball away.
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Master node upgrade

[Evgeniy L]

Hi Vladimir,

Just to make sure that we are on the same page. We'll have to use upgrade
script anyway, since you will need to run database migration and register
new releases.

Thanks,

On Monday, 9 November 2015, Vladimir Kozhukalov 
wrote:

> Looks like most people thing that building backup/re-install approach is
> more viable. So, we certainly need to invent completely new upgrade from
> and thus my suggestion is disable building/testing upgrade tarball right
> now, because anyway it makes no sense.
>
>
> Vladimir Kozhukalov
>
> On Fri, Nov 6, 2015 at 8:21 PM, Vladimir Kuklin  > wrote:
>
>> Just my 2 cents here - let's do docker backup and roll it up onto brand
>> new Fuel 8 node.
>>
>> On Fri, Nov 6, 2015 at 7:54 PM, Oleg Gelbukh > > wrote:
>>
>>> Matt,
>>>
>>> You are talking about this part of Operations guide [1], or you mean
>>> something else?
>>>
>>> If yes, then we still need to extract data from backup containers. I'd
>>> prefer backup of DB in simple plain text file, since our DBs are not that
>>> big.
>>>
>>> [1]
>>> https://docs.mirantis.com/openstack/fuel/fuel-7.0/operations.html#howto-backup-and-restore-fuel-master
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh
>>>
>>> On Fri, Nov 6, 2015 at 6:03 PM, Matthew Mosesohn >> > wrote:
>>>
>>>> Oleg,
>>>>
>>>> All the volatile information, including a DB dump, are contained in the
>>>> small Fuel Master backup. There should be no information lost unless there
>>>> was manual customization done inside the containers (such as puppet
>>>> manifest changes). There shouldn't be a need to back up the entire
>>>> containers.
>>>>
>>>> The information we would lose would include the IP configuration
>>>> interfaces besides the one used for the Fuel PXE network and any custom
>>>> configuration done on the Fuel Master.
>>>>
>>>> I want #1 to work smoothly, but #2 should also be a safe route.
>>>>
>>>> On Fri, Nov 6, 2015 at 5:39 PM, Oleg Gelbukh >>> > wrote:
>>>>
>>>>> Evgeniy,
>>>>>
>>>>> On Fri, Nov 6, 2015 at 3:27 PM, Evgeniy L >>>> > wrote:
>>>>>
>>>>>> Also we should decide when to run containers
>>>>>> upgrade + host upgrade? Before or after new CentOS is installed?
>>>>>> Probably
>>>>>> it should be done before we run backup, in order to get the latest
>>>>>> scripts for
>>>>>> backup/restore actions.
>>>>>>
>>>>>
>>>>> We're working to determine if we need to backup/upgrade containers at
>>>>> all. My expectation is that we should be OK with just backup of DB, IP
>>>>> addresses settings from astute.yaml for the master node, and credentials
>>>>> from configuration files for the services.
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Oleg Gelbukh
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> On Fri, Nov 6, 2015 at 1:29 PM, Vladimir Kozhukalov <
>>>>>> vkozhuka...@mirantis.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Dear colleagues,
>>>>>>>
>>>>>>> At the moment I'm working on deprecating Fuel upgrade tarball.
>>>>>>> Currently, it includes the following:
>>>>>>>
>>>>>>> * RPM repository (upstream + mos)
>>>>>>> * DEB repository (mos)
>>>>>>> * openstack.yaml
>>>>>>> * version.yaml
>>>>>>> * upgrade script itself (+ virtualenv)
>>>>>>>
>>>>>>> Apart from upgrading docker containers this upgrade script makes
>>>>>>> copies of the RPM/DEB repositories and puts them on the master node 
>>>>>>> naming
>>>>>>> these repository directories depending on what is written in 
>>>>>>> openstack.yaml
>>>>>>> and version.yaml. My plan was something like:
>>>>>>>
>>>>>>> 1) deprecate version.yaml (move all fields from there to various
>>>>>>> places)
>>>>>>> 2) deliver opens

Re: [openstack-dev] [Fuel] shotgun code freeze

[Evgeniy L]

+1 to Dmitry, thanks for pushing this activity Vladimir.

On Friday, 6 November 2015, Dmitry Pyzhov  wrote:

> Great job! We are much closer to removal of fuel-web repo.
>
> On Tue, Oct 27, 2015 at 7:35 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com
> > wrote:
>
>> Dear colleagues,
>>
>> I am glad to announce that since now shotgun is a separate project.
>> fuel-web/shotgun directory has been deprecated. There is yet another patch
>> that has not been merged https://review.openstack.org/238525 (adds
>> .gitignore file to the new shotgun repo). Please review it.
>>
>> Shotgun
>>
>>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506894
>>- project-config patch https://review.openstack.org/235355 (DONE)
>>- pypi (DONE)
>>- run_tests.sh https://review.openstack.org/235368 (DONE)
>>- rpm/deb specs https://review.openstack.org/#/c/235382/ (DONE)
>>- fuel-ci verification jobs https://review.fuel-infra.org/12872 (DONE)
>>- label jenkins slaves for verification (DONE)
>>- directory freeze (DONE)
>>- prepare upstream (DONE)
>>- waiting for project-config patch to be merged (DONE)
>>- .gitreview https://review.openstack.org/238476 (DONE)
>>- .gitignore https://review.openstack.org/238525 (ON REVIEW)
>>- custom jobs parameters https://review.fuel-infra.org/13209 (DONE)
>>- fix core group (DONE)
>>- fuel-main https://review.openstack.org/#/c/238953/ (DONE)
>>- packaging-ci  https://review.fuel-infra.org/13181 (DONE)
>>- MAINTAINERS https://review.openstack.org/239410 (DONE)
>>- deprecate shotgun directory https://review.openstack.org/239407
>>(DONE)
>>- fix verify-fuel-web-docs job (it installs shotgun for some reason)
>>https://review.fuel-infra.org/#/c/13194/ (DONE)
>>- remove old shotgun package (DONE)
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Wed, Oct 21, 2015 at 2:46 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com
>> > wrote:
>>
>>> Dear colleagues,
>>>
>>> As you might know I'm working on splitting multiproject fuel-web
>>> repository into several sub-projects. Shotgun is one of directories that
>>> are to be moved to a separate git project.
>>>
>>> Checklist for this to happen is as follows:
>>>
>>>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506894
>>>- project-config patch  https://review.openstack.org/#/c/235355 (ON
>>>REVIEW)
>>>- pypi project
>>>https://pypi.python.org/pypi?%3Aaction=pkg_edit&name=Shotgun (DONE)
>>>- run_tests.sh  https://review.openstack.org/235368 (DONE)
>>>- rpm/deb specs  https://review.openstack.org/#/c/235382 (DONE)
>>>- fuel-ci verification jobs https://review.fuel-infra.org/#/c/12872/ (ON
>>>REVIEW)
>>>- label jenkins slaves for verification jobs (ci team)
>>>- directory freeze (WE ARE HERE)
>>>- prepare upstream (TODO)
>>>- waiting for project-config patch to be merged (ON REVIEW)
>>>- fuel-main patch (TODO)
>>>- packaging-ci patch (TODO)
>>>- deprecate fuel-web/shotgun directory (TODO)
>>>
>>> Now we are at the point where we need to freeze fuel-web/shotgun
>>> directory. So, I'd like to announce code freeze for this directory and all
>>> patches that make changes in the directory and are currently on review will
>>> need to be backported to the new git repository.
>>>
>>> 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

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

[Evgeniy L]

Hi,

I have several comments, just to make sure, that we are on the same page
here.
Current API calls for provisioning/deployment are used by developers and
fuel hackers,
and by design there was removed all validation. So shouldn't there be some
more
user friendly API calls which have validation? For example we don't run any
pre
deployment checks and network validation, you can even ask to deploy
offline nodes.
As result novice user can easily break her/his cluster.

Thanks,

On Fri, Nov 13, 2015 at 11:46 AM, Julia Aranovich 
wrote:

> Hi fuelers,
>
> Currently Fuel UI team is working on blueprint [1] to give Fuel UI user an
> ability to launch provisioning of environment nodes separately from
> deployment (without choosing particular nodes for now).
>
> In the process we were faced with the following issues. Some of them block
> the blueprint:
>
>- deployment constantly failed on environment with pre-provisioned
>nodes [2]
>- node pending_addition flag is reset to False for provisioned nodes
>[3]. This causes a lot of UX problems: provisioned node roles, disks,
>interfaces can not be reconfigured, node can not be deleted from
>environment, just can be marked as pending deletion (that requires
>environment deployment)
>- completed provisioning task has Null message. So, there is no to
>show the user after provisioning finished [4]
>- no notification comes on UI after provisioned finished [5]
>- fake provisioning task is also should be fixed: environment nodes
>stay in 'provisioning' status after provisioning finished [6]. This breaks
>fake Fuel UI workflow and brings difficulties in Fuel UI development.
>
> Could you please consider/fix the tickets and help to unblock the
> blueprint targeted for the current release.
>
> Also, you can check how provisioning works in Fuel UI on #547 custom 8.0
> ISO.
>
> Thank you!
> Julia
>
> [1]
> https://blueprints.launchpad.net/fuel/+spec/support-separate-provisioning-and-deployment-in-ui
> [2] https://bugs.launchpad.net/fuel/+bug/1515903
> [3] https://bugs.launchpad.net/fuel/+bug/1515898
> [4] https://bugs.launchpad.net/fuel/+bug/1515895
> [5] https://bugs.launchpad.net/fuel/+bug/1515891
> [6] https://bugs.launchpad.net/fuel/+bug/1515893
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Fuel Python Gerrit Dashboard

[Evgeniy L]

Thanks Igor, it's very helpful,

Also if you forget where to get the link, use the documentation [1].
I think something like that may also be useful for library and QA team.

Thanks,

[1] https://wiki.openstack.org/wiki/Fuel#Development_related_links


On Mon, Nov 30, 2015 at 3:29 PM, Igor Kalnitsky 
wrote:

> Hey Fuelers,
>
> As a part of improving review process, I've prepared a Gerrit
> Dashboard for Python projects [1]. First and foremost, I did it for
> myself (I believe it will help me to get attention to *ready-to-merge*
> patches), but I want to share the link with you.
>
> Feel free to use it!
>
> [1] https://goo.gl/aFHdeQ
>
> Thanks,
> Igor
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Patch size limit

[Evgeniy L]

Hi Maciej, thank you for bringing this up,

+1, but we should discuss the limit, personally for me it's ok to review
400loc patches,
if the patch covers only one bug-fix/feature implementation.

So if everybody is agree, we should:
1. update contribution guide
2. create a task for *non-voting* gate, which will -1 patch if it has loc
>= x (400?),
also as Neil mentioned, it shouldn't take into account files renaming.

Thanks,

On Tue, Dec 1, 2015 at 3:40 PM, Maciej Kwiek  wrote:

> Hi,
>
> I recently noticed the influx of big patches hitting Gerrit (especially in
> fuel-web, but I also heard that there was a couple of big ones in library).
> I think that patches that have 1000 LOC are simply too big to review
> thoroughly and reliably.
>
> I would argue that there should be a limit to patch size, either a soft
> one (i.e. written down in contributor guidelines) or a hard one (e.g.
> enforced by gate job).
>
> I think that we need a discussion whether we really need this limit, what
> should it be, and how to enforce it.
>
> I personally think that most patches that are over 400 LOC could be easily
> split into at least two smaller changes.
>
> Regarding the limit enforcement - I think we should go with the soft
> limit, with X LOC written as a guideline and giving the reviewers a
> possibility to give -1s to patches that are too big, but also giving the
> possibility to merge bigger changes if it's absolutely necessary (in really
> rare cases the changes simply cannot be split). We may mix in the hard
> limit for ridiculously large patches (twice the "soft limit" would be good
> in my opinion), so the gate would automatically reject such patches,
> forcing contributor to split his patch.
>
> Please share your thoughts on this.
>
> Regards,
> Maciej Kwiek
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Dropping python2.6 compatibility

[Evgeniy L]

Hi,

During Fuel master migration to CentOS7 there was found a problem that tests
get failed [0] for python2.6

As far as I can see it's a common practise to drop python2.6 compatibility
[1],
shouldn't we switch tests to work with python2.7 instead of python2.6?

It looks like fuelclient will be an exception, because clients continue
supporting
python2.6 [1]

Thanks,

[0] https://review.openstack.org/#/c/251120/
[1]
https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

[Evgeniy L]

Hi Dmitry,

It depends, but usually it takes half of working time to do reviews, I'm
not sure if we can assume 25-30%, also finding a good reviewer usually is
much harder than a person who can write the code, so it would be much more
productive to encourage people to spend as much time as they can on making
the project better and helping other contributors, than restricting them to
review code for not more than 2.5 hours.

Thanks,

On Thu, Jun 9, 2016 at 5:46 AM, Dmitry Klenov  wrote:

> Hi Folks,
>
> From technical standpoint I fully support Arthur to become core reviewer.
> I like thorough reviews that he is making.
>
> Although I have some concerns as well. Planned tasks for our team will not
> allow Arthur to spend more than 25-30% of his time for reviewing. If that
> is fine - my concerns are resolved.
>
> Thanks,
> Dmitry.
>
> On Thu, Jun 9, 2016 at 12:57 PM, Sergey Vasilenko  > wrote:
>
>> +1
>>
>>
>> /sv
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] Component Leads Elections

[Evgeniy L]

Hi,

I'm not sure if it's a right place to continue this discussion, but if
there are doubts that such role is needed, we should not wait for another
half a year to drop it.

Also I'm not sure if a single engineer (or two engineers) can handle
majority of upcoming patches + specs + meetings around features. Sergii and
Igor put a lot of efforts to make it work, but does it really scale?

I think it would be better to offload more responsibilities to core groups,
and if core team (of specific project) wants to see formal or informal
leader, let them decide.

I would be really interested to see feedback from current component leads.

Thanks,


On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dmitry,
>
> "No need to rush" does not mean we should postpone
> team structure changes until Ocata. IMO, CL role
> (when it is exposed to Fuel) contradicts to our
> modularization activities. Fuel should be an aggregator
> of components. What if we decide to use Ironic or
> Neutron as Fuel components? Should we chose also
> Ironic CL? NO! Ironic is an independent
> project with its own PTL.
>
> I agree with Mike that we could remove this CL
> role in a month if have consensus. But does it
> make any sense to chose CLs now and then
> immediately remove this role? Probably, it is better
> to make a decision right now. I'd really like to
> see here in this ML thread opinions of our current
> CLs and other people.
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
>> > > I think this call is too late to change a structure for now. I suggest
>> > > that we always respect the policy we've accepted, and follow it.
>> > >
>> > > If Component Leads role is under a question, then I'd continue the
>> > > discussion, hear opinion of current component leads, and give this a
>> time
>> > > to be discussed. I'd have nothing against removing this role in a
>> month
>> > > from now if we reach a consensus on this topic - no need to wait for
>> the
>> > > cycle end.
>> >
>> > Sure, there is no need to rush. I'd also like to see current CL
>> opinions.
>>
>> Considering that, while there's an ongoing discussion on how to change
>> Fuel team structure for Ocata, there's also an apparent consensus that
>> we still want to have component leads for Newton, I'd like to call once
>> again for volunteers to self-nominate for component leads of
>> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
>> nomination period is over, and no volunteer so far :(
>>
>> --
>> Dmitry Borodaenko
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Evgeniy L]

Hi,

Problems which I see with current Shotgun are:
1. Luck of parallelism, so it's not going to fetch data fast enough from
medium/big clouds.
2. There should be an easy way to run it manually (it's possible, but there
is no ready-to-use config), it would be really helpful in case if
Nailgun/Astute/MCollective are down.

As far as I know 1st is partly covered by Ansible, but the problem is it
executes a single task in parallel, so there is probability that lagging
node will slow down fetching from entire environment.
Also we will have to build a tool around Ansible to generate playbooks.

Thanks,

On Wed, Mar 30, 2016 at 5:18 PM, Tomasz 'Zen' Napierala <
tnapier...@mirantis.com> wrote:

> Hi,
>
> Do we have any requirements for the new tool? Do we know what we don’t
> like about current implementation, what should be avoided, etc.? Before
> that we can only speculate.
> From my ops experience, shotgun like tools will not work conveniently on
> medium to big environments. Even on medium env amount of logs is just too
> huge to handle by such simple tool. In such environments better pattern is
> to use dedicated log collection / analysis tool, just like StackLight.
> At the other hand I’m not sure if ansible is the right tool for that. It
> has some features (like ‘fetch’ command) but in general it’s a
> configuration management tool, and I’m not sure how it would act under such
> heavy load.
>
> Regards,
>
> > On 30 Mar 2016, at 15:20, Vladimir Kozhukalov 
> wrote:
> >
> > ​Igor,
> >
> > I can not agree more. Wherever possible we should
> > use existent mature solutions. Ansible is really
> > convenient and well known solution, let's try to
> > use it.
> >
> > Yet another thing should be taken into account.
> > One of Shotgun features is diagnostic report
> > that could then be attached to bugs to identify
> > the content of env. This report could also be
> > used to reproduce env and then fight a bug.
> > I'd like we to have this kind of report.
> > Is it possible to implement such a feature
> > using Ansible? If yes, then let's switch to Ansible
> > as soon as possible.
> >
> > ​
> >
> > Vladimir Kozhukalov
> >
> > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky 
> wrote:
> > Neil Jerram wrote:
> > > But isn't Ansible also over-complicated for just running commands over
> SSH?
> >
> > It may be not so "simple" to ignore that. Ansible has a lot of modules
> > which might be very helpful. For instance, Shotgun makes a database
> > dump and there're Ansible modules with the same functionality [1].
> >
> > Don't think I advocate Ansible as a replacement. My point is, let's
> > think about reusing ready solutions. :)
> >
> > - igor
> >
> >
> > [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
> >
> > On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram 
> wrote:
> > >
> > > FWIW, as a naive bystander:
> > >
> > > On 30/03/16 11:06, Igor Kalnitsky wrote:
> > >> Hey Fuelers,
> > >>
> > >> I know that you probably wouldn't like to hear that, but in my opinion
> > >> Fuel has to stop using Shotgun. It's nothing more but a command runner
> > >> over SSH. Besides, it has well known issues such as retrieving remote
> > >> directories with broken symlinks inside.
> > >
> > > It makes sense to me that a command runner over SSH might not need to
> be
> > > a whole Fuel-specific component.
> > >
> > >> So I propose to find a modern alternative and reuse it. If we stop
> > >> supporting Shotgun, we can spend extra time to focus on more important
> > >> things.
> > >>
> > >> As an example, we can consider to use Ansible. It should not be tricky
> > >> to generate Ansible playbook instead of generating Shotgun one.
> > >> Ansible is a  well known tool for devops and cloud operators, and they
> > >> we will only benefit if we provide possibility to extend diagnostic
> > >> recipes in usual (for them) way. What do you think?
> > >
> > > But isn't Ansible also over-complicated for just running commands over
> SSH?
> > >
> > > Neil
> > >
> > >
> > >
> __
> > > OpenStack Development Mailing 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
>
> --
> Tomasz 'Zen' Napierala
> Product Engineering - Poland
>
>
>
>
>
>
>
>

Re: [openstack-dev] [Fuel] Newton Design Summit sessions planning

[Evgeniy L]

Hi, no problem from my side.

On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to request workrooms sessions swap.
>
> We have a session about Fuel/Ironic integration and I'd like
> this session not to overlap with Ironic sessions, so Ironic
> team could attend Fuel sessions. At the same time, we have
> a session about orchestration engine and it would be great to
> invite there people from Mistral and Heat.
>
> My suggestion is as follows:
>
> Wed:
> 9:50 Astute -> Mistral/Heat/???
> Thu:
> 9.00 Fuel/Ironic/Ironic-inspector
>
> If there are any objections, please let me know asap.
>
>
>
> Vladimir Kozhukalov
>
> On Fri, Apr 1, 2016 at 9:47 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> Looks like we have final version sessions layout [1]
>> for Austin design summit. We have 3 fishbows,
>> 11 workrooms, full day meetup.
>>
>> Here you can find some useful information about design
>> summit [2]. All session leads must read this page,
>> be prepared for their sessions (agenda, slides if needed,
>> etherpads for collaborative work, etc.) and follow
>> the recommendations given in "At the Design Summit" section.
>>
>> Here is Fuel session planning etherpad [3]. Almost all suggested
>> topics have been put there. Please put links to slide decks
>> and etherpads next to respective sessions. Here is the
>> page [4] where other teams publish their planning pads.
>>
>> If session leads want for some reason to swap their slots it must
>> be requested in this ML thread. If for some reason session lead
>> can not lead his/her session, it must be announced in this ML thread.
>>
>> Fuel sessions are:
>> ===
>> Fishbowls:
>> ===
>> Wed:
>> 15:30-16:10
>> 16:30:17:10
>> 17:20-18:00
>>
>> ===
>> Workrooms:
>> ===
>> Wed:
>> 9:00-9:40
>> 9:50-10:30
>> 11:00-11:40
>> 11:50-12:30
>> 13:50-14:30
>> 14:40-15:20
>> Thu:
>> 9:00-9:40
>> 9:50-10:30
>> 11:00-11:40
>> 11:50-12:30
>> 13:30-14:10
>>
>> ===
>> Meetup:
>> ===
>> Fri:
>> 9:00-12:30
>> 14:00-17:30
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/d59d38b7/attachment.pdf
>> [2] https://wiki.openstack.org/wiki/Design_Summit
>> [3] https://etherpad.openstack.org/p/fuel-newton-summit-planning
>> [4] https://wiki.openstack.org/wiki/Design_Summit/Planning
>>
>> Thanks.
>>
>> Vladimir Kozhukalov
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

[Evgeniy L]

>> Btw, one of the ideas was to use Fuel task capabilities to gather
diagnostic snapshot.

I think such kind of tools should use as less as possible existing
infrastructure, because in case if something went wrong, you should be able
to easily get diagnostic information, even with broken RabbitMQ, Astute and
MCollective.

Thanks,


On Mon, Apr 18, 2016 at 2:26 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Colleagues,
>
> Whether we are going to continue using Shotgun or
> substitute it with something else, we still need to
> decouple it from Fuel because Shotgun is a generic
> tool. Please review these [1], [2].
>
> [1] https://review.openstack.org/#/c/298603
> [2] https://review.openstack.org/#/c/298615
>
>
> Btw, one of the ideas was to use Fuel task capabilities
> to gather diagnostic snapshot.
>
> Vladimir Kozhukalov
>
> On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> Problems which I see with current Shotgun are:
>> 1. Luck of parallelism, so it's not going to fetch data fast enough from
>> medium/big clouds.
>> 2. There should be an easy way to run it manually (it's possible, but
>> there is no ready-to-use config), it would be really helpful in case if
>> Nailgun/Astute/MCollective are down.
>>
>> As far as I know 1st is partly covered by Ansible, but the problem is it
>> executes a single task in parallel, so there is probability that lagging
>> node will slow down fetching from entire environment.
>> Also we will have to build a tool around Ansible to generate playbooks.
>>
>> Thanks,
>>
>> On Wed, Mar 30, 2016 at 5:18 PM, Tomasz 'Zen' Napierala <
>> tnapier...@mirantis.com> wrote:
>>
>>> Hi,
>>>
>>> Do we have any requirements for the new tool? Do we know what we don’t
>>> like about current implementation, what should be avoided, etc.? Before
>>> that we can only speculate.
>>> From my ops experience, shotgun like tools will not work conveniently on
>>> medium to big environments. Even on medium env amount of logs is just too
>>> huge to handle by such simple tool. In such environments better pattern is
>>> to use dedicated log collection / analysis tool, just like StackLight.
>>> At the other hand I’m not sure if ansible is the right tool for that. It
>>> has some features (like ‘fetch’ command) but in general it’s a
>>> configuration management tool, and I’m not sure how it would act under such
>>> heavy load.
>>>
>>> Regards,
>>>
>>> > On 30 Mar 2016, at 15:20, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>> >
>>> > ​Igor,
>>> >
>>> > I can not agree more. Wherever possible we should
>>> > use existent mature solutions. Ansible is really
>>> > convenient and well known solution, let's try to
>>> > use it.
>>> >
>>> > Yet another thing should be taken into account.
>>> > One of Shotgun features is diagnostic report
>>> > that could then be attached to bugs to identify
>>> > the content of env. This report could also be
>>> > used to reproduce env and then fight a bug.
>>> > I'd like we to have this kind of report.
>>> > Is it possible to implement such a feature
>>> > using Ansible? If yes, then let's switch to Ansible
>>> > as soon as possible.
>>> >
>>> > ​
>>> >
>>> > Vladimir Kozhukalov
>>> >
>>> > On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com> wrote:
>>> > Neil Jerram wrote:
>>> > > But isn't Ansible also over-complicated for just running commands
>>> over SSH?
>>> >
>>> > It may be not so "simple" to ignore that. Ansible has a lot of modules
>>> > which might be very helpful. For instance, Shotgun makes a database
>>> > dump and there're Ansible modules with the same functionality [1].
>>> >
>>> > Don't think I advocate Ansible as a replacement. My point is, let's
>>> > think about reusing ready solutions. :)
>>> >
>>> > - igor
>>> >
>>> >
>>> > [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
>>> >
>>> > On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram <
>>> neil.jer...@metaswitch.com> wrote:
>>> > >
>>> > > FWIW, as a naive bystander:
>>>

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

[Evgeniy L]

Hi,

On upcoming summit we will have a track on Fuel & Ironic (Ironic-inspector)
integration, so you are welcome to participate.

Thursday 9:00
https://etherpad.openstack.org/p/fuel-newton-summit-planning

Thanks,

On Fri, Mar 18, 2016 at 9:49 PM, Jim Rollenhagen 
wrote:

> On Fri, Mar 18, 2016 at 07:26:03PM +0300, Vladimir Kozhukalov wrote:
> > >Well, there's a number of reasons. Ironic is not meant only for an
> > >"undercloud" (deploying OpenStack on ironic instances). There are both
> > >public and private cloud deployments of ironic in production today, that
> > >make bare metal instances available to users of the cloud. Those users
> > >may not want an agent running inside their instance, and more
> > >importantly, the operators of those clouds may not want to expose the
> > >ironic or inspector APIs to their users.
> >
> > >I'm not sure ironic should say "no, that isn't allowed" but at a minimum
> > >it would need to be opt-in behavior.
> >
> > For me it's absolutely clear why cloud case does assume running any kind
> of
> > agent
> > inside user instance. It is clear why cloud case does not assume exposing
> > API
> > to the user instance. But cloud is not the only case that exists.
> > Fuel is a deployment tool. Fuel case is not cloud.  It is 'cattle'
> (cattle
> > vs. pets), but
> > it is not cloud in a sense that instances are 'user instances'.
> > Fuel 'user instances' are not even 'user' instances.
> > Fuel manages the content of instances throughout their whole life cycle.
>
> To be clear, I'm not saying we shouldn't do it. I'm saying we should
> talk about it. Ironic can't assume there's an agent, but we sure could
> make it optional. I do realize Fuel is a valid use case, and I want to
> be able to support that use case.
>
> // jim
>
> > As you might remember we talked about this about two years ago (when we
> > tried to contribute lvm and md features to IPA). I don't know why this
> case
> > (deployment) was rejected again and again while it's still viable and
> > widely used.
> > And I don't know why it could not be implemented to be 'opt-in'.
> > Since that we have invented our own fuel-agent (that supports lvm, md)
> and
> > a driver for Ironic conductor that allows to use Ironic with fuel-agent.
> >
> > >Is the fuel team having a summit session of some sort about integrating
> > >with ironic better? I'd be happy to come to that if it can be scheduled
> > >at a time that ironic doesn't have a session. Otherwise maybe we can
> > >catch up on Friday or something.
> >
> > >I'm glad to see Fuel wanting to integrate better with Ironic.
> >
> > We are still quite interested in closer integration with Ironic (we need
> > power
> > management features that Ironic provides). We'll be happy to schedule yet
> > another discussion on closer integration with Ironic.
> >
> > BTW, about a year ago (in Grenoble) we agreed that it is not even
> > necessary to merge such custom things into Ironic tree. Happily, Ironic
> is
> > smart enough to consume drivers using stevedore. About ironic-inspector
> > the case is the same. Whether we are going to run it inside 'user
> instance'
> > or inside ramdisk it does not affect ironic-inspector itself. If Ironic
> > team is
> > open for merging "non-cloud" features (of course 'opt-in') we'll be happy
> > to contribute.
> >
> > Vladimir Kozhukalov
> >
> > On Fri, Mar 18, 2016 at 6:03 PM, Jim Rollenhagen  >
> > wrote:
> >
> > > On Fri, Mar 18, 2016 at 05:26:13PM +0300, Evgeniy L wrote:
> > > > On Thu, Mar 17, 2016 at 3:16 PM, Dmitry Tantsur  >
> > > wrote:
> > > >
> > > > > On 03/16/2016 01:39 PM, Evgeniy L wrote:
> > > > >
> > > > >> Hi Dmitry,
> > > > >>
> > > > >> I can try to provide you description on what current Nailgun
> agent is,
> > > > >> and what are potential requirements we may need from HW discovery
> > > system.
> > > > >>
> > > > >> Nailgun agent is a one-file Ruby script [0] which is periodically
> run
> > > > >> under cron. It collects information about HW using ohai [1], plus
> it
> > > > >> does custom parsing, filtration, retrieval of HW information.
> After
> > > the
> > > > >> inf

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

[Evgeniy L]

Hi Irina,

I fully support the idea of creating separate launchpad project for each
plugin, because plugins have different release cycles and different teams
who support them.

Fuel Plugin documentation [2] has to be updated with information for plugin
developers (how to setup new project) and for users (how to create a bug).
Good information on how to create and setup new project can be found here
[1].

Thanks,

[1] http://docs.openstack.org/infra/manual/creators.html
[2] https://wiki.openstack.org/wiki/Fuel/Plugins

On Tue, Apr 19, 2016 at 6:49 PM, Irina Povolotskaya <
ipovolotsk...@mirantis.com> wrote:

> Hi to everyone,
>
> as you possibly know (at least, those dev. teams working on their Fuel
> plugins) we have a fuel-plugins Launchpad project [1] which serves as
> all-in-one entry point for filing bugs, related
> to plugin-specific problems.
>
> nevertheless, this single project is a bad idea in terms of providing
> granularity and visibility for each plugin:
> - it's not possible to make up milestones, unique for every plugin that
> would coincide with the plugin's version (which is specified in
> metadata.yaml file)
> - it's not possible to provide every dev. team with exclusive rights on
> managing importance, milestones etc.
>
> therefore, I would like to propose the following:
> - if you have your own fuel plugin, create a separate LP project for it
> e.g.[2] [3]and make up all corresponding groups for managing release cycle
> of your plugin
> - if you have some issues with fuel plugin framework itself, please
> consider filing bugs in fuel project [4] as usual.
>
> I would appreciate getting feedback on this idea.
> if it seems fine, then I'll follow-up with adding instructions into our
> SDK [5] and the list of already existing LP projects.
>
> thanks.
>
>
> [1] https://launchpad.net/fuel-plugins
> [2] https://launchpad.net/lma-toolchain
> [3] https://launchpad.net/fuel-plugin-nsxv
> [4] https://launchpad.net/fuel
> [5] https://wiki.openstack.org/wiki/Fuel/Plugins
>
>
> --
> Best regards,
>
> Irina Povolotskaya
>
>
>
>
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

[Evgeniy L]

Hi,

Thank you Igor for cleaning core related groups.

Also I would like to add that many of removed cores are still SME (subject
matter experts)
in specific areas, so they will continue reviewing related patches.

Thanks,

On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky 
wrote:

> Hey folks,
>
> In an effort to do some housekeeping, I clean up the list of core
> reviewers in Fuel.
>
> According to Stackalytics the following cores show a low contribution rate:
>
> # fuel-web [1]
>
> * Dmitry Shulyak
> * Evgeniy L
>
> # python-fuelclient [2]
>
> * Dmitry Pyzhov
> * Evgeniy L
>
> # shotgun [3]
>
> * Dmitry Shulyak
> * Evgeniy L
>
> # fuel-upgrade [4]
>
> * Aleksey Kasatkin
> * Vladimir Kozhukalov
>
> # fuel-main [5]
>
> * Dmitry Pyzhov
> * Roman Vyalov
>
> # fuel-agent [6]
>
> * Aleksey Kasatkin
> * Evgeniy L
> * Igor Kalnitsky
>
> Also, I've removed Sebastian Kalinowski as he said he has no time to
> work on Fuel anymore.
>
> Once former cores show high level of contribution again, I'll gladly
> add them back.
>
> - Igor
>
> [1] http://stackalytics.com/report/contribution/fuel-web/90
> [2] http://stackalytics.com/report/contribution/python-fuelclient/90
> [3] http://stackalytics.com/report/contribution/shotgun/90
> [4] http://stackalytics.com/report/contribution/fuel-upgrade/90
> [5] http://stackalytics.com/report/contribution/fuel-main/90
> [6] http://stackalytics.com/report/contribution/fuel-agent/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Experimental Task Based Deployment Landed into Master

[Evgeniy L]

+1 It's really good job folks.

On Sat, Dec 12, 2015 at 2:25 AM, Vladimir Kuklin 
wrote:

> Fuelers
>
> I am thrilled to announce that task based deployment engine [0] has been
> just merged into Fuel master. We checked it against existing BVT test cases
> for regressions as well as against functional testing for several cases of
> deployment. All the OSTF and network verification tests have successfully
> passed.
>
> We will obviously need to polish it and fix bugs which will arise, but
> this is a gigantic step forward for our orchestration engine which should
> allow us to drastically increase our development velocity as well as end
> user experience.
>
> Thanks to all who participated in development testing and review:
>
> Dmitry Ilyin
> Vladimir Sharshov
> Bulat Gaifullin
> Alexey Shtokolov
> Igor Kalnitsky
> Evgeniy Li
> Sergii Golovatiuk
> Dmitry Shulyak
>
> and many-many others
>
> I am pretty confident that this will allow us to develop and test faster
> as well as introduce support of some of Life-Cycle Management scenarios in
> 8.0 release.
>
> Once again, thank you all, folks, for your dedicated work and efforts on
> making Fuel better.
>
> [0]
> https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Dropping Python 2.6

[Evgeniy L]

Hi Roman,

We've discussed it [1], so +1

[1]
https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility

On Mon, Dec 14, 2015 at 5:05 PM, Roman Prykhodchenko  wrote:

> Fuelers,
>
> Since Mitaka OpenStack Infra has no resources to test python 2.6 support
> so the corresponding jobs are not running anymore. Since Fuel master node
> is on CentOS 7 now, let’s drop Python 2.6 support in Fuel.
>
>
> - 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

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

[Evgeniy L]

+1

On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova  wrote:

> +1
>
> On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov 
> wrote:
>
>> +1
>>
>> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin > > wrote:
>>
>>> +1.
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimir Sharshov <
>>> vshars...@mirantis.com> wrote:
>>>
 Hi,

 +1 from me to Bulat.

 On Mon, Dec 14, 2015 at 1:03 PM, Igor Kalnitsky <
 ikalnit...@mirantis.com> wrote:

> Hi Fuelers,
>
> I'd like to nominate Bulat Gaifulin [1] for
>
> * fuel-web-core [2]
> * fuel-mirror-core [3]
>
> Bulat's doing a really good review with detailed feedback and he's a
> regular participant in IRC. He's co-author of packetary and
> fuel-mirror projects, and he made valuable contribution to fuel-web
> (e.g. task-based deployment engine).
>
> Fuel Cores, please reply back with +1/-1.
>
> - Igor
>
> [1] http://stackalytics.com/?module=fuel-web&user_id=bgaifullin
> [2] http://stackalytics.com/report/contribution/fuel-web/90
> [3] http://stackalytics.com/report/contribution/fuel-mirror/90
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] [All][Bareon][Fuel][Ironic] New project: Bareon (provisioning system)

[Evgeniy L]

We are happy to introduce Bareon [0], which is a fork of fuel_agent [1]
project which have been developed under Fuel’s umbrella.

Bareon provides flexible and data driven interface to perform actions
which are related to operating system installation. In contrary to standard
kickstart and preseed ways of installation, Bareon provides a uniform
interface for system configuration. Higher level of flexibility is open via
this interface for other tools and products, such as Ironic [2] or Fuel.
It is to be a tool similar to old plain OS installation tools like anaconda
or debian-installer but drastically more convenient.

To summarise what Bareon is:
* flexible partitioning system
* image building functionality, mostly non-cloud use-cases that assume
  advanced partitioning, OS upgrading, in-place image building
* image/repo based provisioning

We decided to continue developing it as separate from Fuel project for
several reasons:
* it solves a set of problems which are not Fuel specific, with “fuel”
prefix
  in the name people may think that it’s intended to be used only with Fuel
* it's easier to contribute to a small standalone project than to find your
way
  around all the components of a large project such as Fuel
* to have separate roadmap [3] with its own release cycle and team, we
  really want to have small releases more often, it’ll be easier to do for a
  small project

fuel_agent repository and the project will exist for some time not to
disrupt
Fuel’s roadmap and its release cycle, after we finish full renaming and
required
refactoring, Fuel will be switched to Bareon.

Currently we are working on cleaning repository to finish renaming [4].
In case if you have any questions join us on #openstack-bareon irc channel.
We are going to arrange Bareon meetings soon, stay tuned.

Thanks!

[0] https://wiki.openstack.org/wiki/Bareon
[1] https://github.com/openstack/fuel-agent
[2]
https://github.com/openstack/bareon/blob/master/contrib/ironic/ironic-fa-deploy/README.rst
[3] https://wiki.openstack.org/wiki/Bareon/Roadmap
[4] https://review.openstack.org/#/c/257836/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

[Evgeniy L]

+1 to Vladimir Kozhukalov,

Entire point of moving branches creation to SCF was to perform such changes
as
early as possible in the release, I see no reasons to wait for HCF.

Thanks,

On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> -1
>
> We already discussed this and we have made a decision to move stable
> branch creation from HCF to SCF. There were reasons for this. We agreed
> that once stable branch is created, master becomes open for new features.
> Let's avoid discussing this again.
>
> Vladimir Kozhukalov
>
> On Wed, Dec 16, 2015 at 9:55 AM, Bulat Gaifullin 
> wrote:
>
>> +1
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> On 15 Dec 2015, at 22:19, Andrew Maksimov  wrote:
>>
>> +1
>>
>> Regards,
>> Andrey Maximov
>> Fuel Project Manager
>>
>> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Folks
>>>
>>> This email is a proposal to push Docker containers removal from the
>>> master node to the date beyond 8.0 HCF.
>>>
>>> Here is why I propose to do so.
>>>
>>> Removal of Docker is a rather invasive change and may introduce a lot of
>>> regressions. It is well may affect how bugs are fixed - we might have 2
>>> ways of fixing them, while during SCF of 8.0 this may affect velocity of
>>> bug fixing as you need to fix bugs in master prior to fixing them in stable
>>> branches. This actually may significantly increase our bugfixing pace and
>>> put 8.0 GA release on risk.
>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Evgeniy L]

Hi Dmitry,

I also don't think that we should duplicate the data in configdb,
because in this case there will be +2 additional interfaces which
will require to covert the data into configdb and after that from
configdb to Solar, which seems redundant overhead.

But we should be able to put the data directly to user's
CMDB/ZooKeeper/Puppet Master/etc.

Thanks,

On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak 
wrote:

> Hello folks,
>
> This topic is about configuration storage which will connect data sources
> (nailgun/bareon/others) and orchestration. And right now we are developing
> two projects that will overlap a bit.
>
> I understand there is not enough context to dive into this thread right
> away, but i will appreciate if those people, who participated in design,
> will add their opinions/clarifications on this matter.
>
> Main disagreements
> ---
> 1. configdb should be passive, writing to configdb is someone else
> responsibility
> + simpler implementation, easier to use
> - we will need another component that will do writing, or split this
> responsibility somehow
>
> 2. can be used without other solar components
> + clear inteface between solar components and storage layer
> - additional work required to design/refactor communication layer between
> modules in solar
> - some data will be duplicated between solar orchestrator layer and
> configdb
>
> 3. templates for output
> technical detail, can be added on top of solardb if required
>
> Similar functionality
> --
> 1. Hierachical storage
> 2. Versioning of changes
> 3. Possibility to overwrite config values
> 4. Schema for inputs
>
> Overall it seems that we share same goals for both services,
> the difference lies in organizational and technical implementation details.
>
> Possible solutions
> 
> 1. develop configdb and solar with duplicated functionality
> - at least 2 additional components will be added to the picture,
> one is configdb, another one will need to sync data between configdb and
> solar
> - in some cases data in solar and configdb will be 100% duplicated
> - different teams will work on same functionality
> - integration of additional component for fuel will require integration
> with
> configdb and with solar
> + configdb will be independent from solar orchestration/other components
>
> 2. make service out of solardb, allign with configdb use cases
> + solardb will be independent from solar orchestration/other solar
> components
> + integration of fuel component will be easier than in 1st version
> + clarity about components responsibility and new architecture
> - redesign/refactoring communication between components in solar
>
> 3. do not use configdb/no extraction of solardb
> - inproc communication, which can lead to coupled components (not the case
> currently)
> + faster implementation (no major changes required for integration with
> fuel)
> + clarity about components responsibility and new architecture
>
> Summary
> -
> For solar it makes no difference where data will come from: configdb or
> data sources, but in overall fuel architecture it will lead to significant
> complexity increase.
> It would be the best to follow 2nd path, because in long term we don't
> want tightly coupled components, but in nearest future we need to
> concentrate
> on:
> - integration with fuel
> - implementing policy engine
> - polishing solar components
> This is why i am not sure that we can spend time on 2nd path right now,
> or even before 9.0.
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Evgeniy L]

Hi,

Since older Postgres doesn't introduce bugs and it won't harm new features,
I would vote for downgrade to 9.2

The reasons are:
1. not to support own package for Centos (as far as I know 9.3 for Ubuntu
is already there)
2. should Fuel some day be a part of upstream Centos? If yes, or there is
even small probability that
it's going to be, we should be as much as possible compatible with
upstream repo. If we don't
consider such possibility, it doesn't really matter, because user will
have to connect external
repo anyway.

Since we already use Postgres specific features, we should spawn a separate
thread, if
we should or shouldn't continue doing that, and if there is a real need to
support mysql
for example.

Thanks,

On Wed, Dec 16, 2015 at 3:58 PM, Igor Kalnitsky 
wrote:

> > From what I understand, we are using 9.2 since the CentOS 7 switch. Can
> > anyone point me to a bug caused by that?
>
> AFAIK, there's no such bugs. Some folks have just *concerns*. Anyway,
> it's up to packaging team to decide whether to package or not.
>
> From Nailgun POV, I'd like to see classical RDBMS schemas as much as
> possible, and do not rely on database backend and its version.
>
> On Wed, Dec 16, 2015 at 11:30 AM, Bartłomiej Piotrowski
>  wrote:
> > On 2015-12-16 10:14, Bartłomiej Piotrowski wrote:
> >> On 2015-12-16 08:23, Mike Scherbakov wrote:
> >>> We could consider downgrading in Fuel 9.0, but I'd very carefully
> >>> consider that. As Vladimir Kuklin said, there are may be other users
> who
> >>> already rely on 9.3 for some of their enhancements.
> >>
> >> That will be way too late for that, as it will make upgrade procedure
> >> more complicated. Given no clear upgrade path from 7.0 to 8.0, it sounds
> >> like perfect opportunity to use what is provided by base distribution.
> >> Are there actual users facilitating 9.3 features or is it some kind of
> >> Invisible Pink Unicorn?
> >>
> >> Bartłomiej
> >>
> >
> > I also want to remind that we are striving for possibility to let users
> > do 'yum install fuel' (or apt) to make the magic happen. There is not
> > much magic in requiring potential users to install specific PostgreSQL
> > version because someone said so. It's either supporting the lowest
> > version available (CentOS 7 – 9.2, Ubuntu 14.04 – 9.3, Debian Jessie –
> > 9.4, openSUSE Leap – 9.4) or "ohai add this repo with our manually
> > imported and rebuilt EPEL package".
> >
> > From what I understand, we are using 9.2 since the CentOS 7 switch. Can
> > anyone point me to a bug caused by that?
> >
> > BP
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

[Evgeniy L]

Hi Andrew,

It doesn't look fair at all to say that we use Postgres specific feature
for no reasons
or as you said "just because we want".
For example we used Arrays which fits pretty well for our roles usage,
which improved
readability and performance.
Or try to fit into relational system something like that [1], I don't think
that we will get
a good result.

P.S. sending a link to a holywar topic (schema vs schemaless), won't help
to solve our
specific problem with Postgres downgrading vs keeping old (new) version.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml


On Tue, Dec 15, 2015 at 10:53 PM, Andrew Maksimov 
wrote:

> +1 to Igor suggestion to downgrade Postgres to 9.2. Our users don't work
> directly with Postgres, so there is no any deprecation of Fuel features.
> Maintaining our own custom Postgres package just because we want "JSON
> column" is not a rational decision. Come on, fuel is not a billing system
> with thousands tables and special requirements to database. At least, we
> should try to keep it simple and avoid unnecessary complication.
>
> PS
>  BTW, some people suggest to avoid using  json columns, read [1]
> PostgreSQL anti-patterns: unnecessary json columns.
>
> [1] -
> http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary-jsonhstore-dynamic-columns/
>
> Regards,
> Andrey Maximov
> Fuel Project Manager
>
>
> On Tue, Dec 15, 2015 at 9:34 PM, Vladimir Kuklin 
> wrote:
>
>> Folks
>>
>> Let me add my 2c here.
>>
>> I am for using Postgres 9.3. Here is an additional argument to the ones
>> provided by Artem, Aleksandra and others.
>>
>> Fuel is being sometimes highly customized by our users for their specific
>> needs. It has been Postgres 9.3 for a while and they might have as well
>> gotten used to it and assumed by default that this would not change. So
>> some of their respective features they are developing for their own sake
>> may depend on Postgres 9.3 and we will never be able to tell the fraction
>> of such use cases. Moreover, downgrading DBMS version of Fuel should be
>> inevitably considered as a 'deprecation' of some features our software
>> suite is providing to our users. This actually means that we MUST provide
>> our users with a warning and deprecation period to allow them to adjust to
>> these changes. Obviously, accidental change of Postgres version does not
>> follow such a policy in any way. So I see no other ways except for getting
>> back to Postgres 9.3.
>>
>>
>> On Tue, Dec 15, 2015 at 7:39 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Hey Mike,
>>>
>>> Thanks for your input.
>>>
>>> > actually not.  if you replace your ARRAY columns with JSON entirely,
>>>
>>> It still needs to fix the code, i.e. change ARRAY-specific queries
>>> with JSON ones around the code. ;)
>>>
>>> > there's already a mostly finished PR for SQLAlchemy support in the
>>> queue.
>>>
>>> Does it mean SQLAlchemy will have one unified interface to make JSON
>>> queries? So we can use different backends if necessary?
>>>
>>> Thanks,
>>> - Igor
>>>
>>> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer  wrote:
>>> >
>>> >
>>> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote:
>>> >> Hey Julien,
>>> >>
>>> >>>
>>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql
>>> >>
>>> >> I believe this blueprint is about DB for OpenStack cloud (we use
>>> >> Galera now), while here we're talking about DB backend for Fuel
>>> >> itself. Fuel has a separate node (so called Fuel Master) and we use
>>> >> PostgreSQL now.
>>> >>
>>> >>> does that mean Fuel is only going to be able to run with PostgreSQL?
>>> >>
>>> >> Unfortunately we already tied up to PostgreSQL. For instance, we use
>>> >> PostgreSQL's ARRAY column type. Introducing JSON column is one more
>>> >> way to tighten knots harder.
>>> >
>>> > actually not.  if you replace your ARRAY columns with JSON entirely,
>>> > MySQL has JSON as well now:
>>> > https://dev.mysql.com/doc/refman/5.7/en/json.html
>>> >
>>> > there's already a mostly finished PR for SQLAlchemy support in the
>>> queue.
>>> >
>>> >
>>> >
>>> >>
>>> >> - Igor
>>> >>
>>> >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou 
>>> wrote:
>>> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote:
>>> >>>
>>>  The things I want to notice are:
>>> 
>>>  * Currently we aren't tied up to PostgreSQL 9.3.
>>>  * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by using
>>> a
>>>  set of JSON operations.
>>> >>>
>>> >>> I'm curious and have just a small side question: does that mean Fuel
>>> is
>>> >>> only going to be able to run with PostgreSQL?
>>> >>>
>>> >>> I also see
>>> >>>
>>> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql
>>> ,
>>> >>> maybe it's related?
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> --
>>> >>> Julien Danjou
>>> >>> // Free Software hacker
>>> >>> // https://julien.danjou.info
>>> >>
>>> >>
>>> __

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

[Evgeniy L]

Hi Oleg,

With the same degree of confidence we can say that anything we have in the
beginning of
the release cycle is not urgent enough. We pushed early branching
specifically for
such big changes as Docker removal/Changing repos structures and merging
invasive patches
for new release features.

Vladimir Kuklin,

I'm not sure what do you mean by "fixing 2 different environments"? With
environment without
containers it will simplify debugging process.

Thanks,

On Wed, Dec 16, 2015 at 10:12 PM, Oleg Gelbukh 
wrote:

> Hi
>
> Although I agree that it should be done, the removal of Docker doesn't
> seem an urgent feature to me. It is not blocking anything besides moving to
> full package-based deployment of Fuel, as far as I understand. So it could
> be easily delayed for one milestone, especially if it is already almost
> done and submitted for review, so it could be merged fast before any other
> significant changes land in 'master' after it is open.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Wed, Dec 16, 2015 at 8:56 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Vladimir,
>>
>> I have other activities planned for the time immediately after SCF
>> (separating UI from fuel-web, maybe it is even more invasive :-)) and it is
>> not a big deal to postpone this feature or another. I am against the
>> approach itself of postponing something because it is too invasive. If we
>> create stable branch master becomes open. That was our primary intention to
>> open master earlier than later when we decided to move stable branch
>> creation.
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Wed, Dec 16, 2015 at 8:28 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Vladimir
>>>
>>> I am pretty much for removing docker, but I do not think that we should
>>> startle our developers/QA folks with additional efforts on fixing 2
>>> different environments. Let's just think from the point of development
>>> velocity here and at delay such changes for at least after NY. Because if
>>> we do it immediately after SCF there will be a whole bunch of holidays and
>>> Russian holidays are Jan 1st-10th and you (who is the SME for docker
>>> removal) will be offline. Do you really want to fix things instead of
>>> enjoying holidays?
>>>
>>> On Wed, Dec 16, 2015 at 4:09 PM, Evgeniy L  wrote:
>>>
>>>> +1 to Vladimir Kozhukalov,
>>>>
>>>> Entire point of moving branches creation to SCF was to perform such
>>>> changes as
>>>> early as possible in the release, I see no reasons to wait for HCF.
>>>>
>>>> Thanks,
>>>>
>>>> On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov <
>>>> vkozhuka...@mirantis.com> wrote:
>>>>
>>>>> -1
>>>>>
>>>>> We already discussed this and we have made a decision to move stable
>>>>> branch creation from HCF to SCF. There were reasons for this. We agreed
>>>>> that once stable branch is created, master becomes open for new features.
>>>>> Let's avoid discussing this again.
>>>>>
>>>>> Vladimir Kozhukalov
>>>>>
>>>>> On Wed, Dec 16, 2015 at 9:55 AM, Bulat Gaifullin <
>>>>> bgaiful...@mirantis.com> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> Regards,
>>>>>> Bulat Gaifullin
>>>>>> Mirantis Inc.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 Dec 2015, at 22:19, Andrew Maksimov 
>>>>>> wrote:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> Regards,
>>>>>> Andrey Maximov
>>>>>> Fuel Project Manager
>>>>>>
>>>>>> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin <
>>>>>> vkuk...@mirantis.com> wrote:
>>>>>>
>>>>>>> Folks
>>>>>>>
>>>>>>> This email is a proposal to push Docker containers removal from the
>>>>>>> master node to the date beyond 8.0 HCF.
>>>>>>>
>>>>>>> Here is why I propose to do so.
>>>>>>>
>>>>>>> Removal of Docker is a rather invasive change and may introduce a
>>>>>>> lot of regressions. It is well may affect how bugs are fixed - we might
>>>>>

[openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

[Evgeniy L]

Hi,

Some time ago, we’ve started a discussion [0] about Fuel modularisation
activity.
Due to unexpected circumstances POC has been delayed.

Regarding to partitioning/provisioning system, we have POC with a demo [1]
(thanks to Sylwester), which shows how the integration of Fuel and Bareon
[2] can
be done.

To summarise the implementation:
* we have a simple implementation of Bareon-API [3], which stores
partitioning
  related data and allows to edit it
* for Nailgun new extension has been implemented [4], which uses Bareon-API
  to store partitioning information, so we will be able to easily switch
between
  classic volume_manager implementation and Bareon-API extension
* when provisioning gets started, extensions retrieves the data from
Bareon-API

Next steps:
* create Bareon-API repository, and start production ready implementation
* create a spec for Fuel project
* create a spec for Bareon project

If you have any questions don’t hesitate to ask them in this thread, also
you can
find us on #openstack-bareon channel.

Thanks!

[0]
http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
[1] https://www.youtube.com/watch?v=GTJM8i7DL0w
[2]
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
[3] https://github.com/Mirantis/bareon-api
[4] https://review.openstack.org/#/c/250864/
__
OpenStack Development Mailing 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][Bareon] Fuel & Bareon integration (fuel modularisation)

[Evgeniy L]

Hi Igor,

Bareon by itself doesn't have any REST interface, Bareon is basically
fuel_agent,
which is framework + CLI wrapper to use it as an agent.
In order to store and edit required entities in the database we need some
wrapper,
which adds this functionality. This simple wrapper will be implemented in
Bareon-API.
User should be able to use Bareon without any additional API/Database if
she/he
wants to do some basic stuff without need to store the configuration, which
is not
Fuel use case.
If the question was specifically about Bareon-API in separate repo, there
is no
reason to store it in a single repo, since we may have separate teams
working
on those sub-projects and those solve a bit different problems, user facing
api
vs low level tools.

Thanks,

On Thu, Dec 17, 2015 at 5:33 PM, Igor Kalnitsky 
wrote:

> > create Bareon-API repository, and start production ready implementation
>
> For what reason do we need a separate repo? I thought API will be a
> part of bareon repo. Or bareon is just a provisioning agent, which
> will be driven by bareon-api?
>
> On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L  wrote:
> > Hi,
> >
> > Some time ago, we’ve started a discussion [0] about Fuel modularisation
> > activity.
> > Due to unexpected circumstances POC has been delayed.
> >
> > Regarding to partitioning/provisioning system, we have POC with a demo
> [1]
> > (thanks to Sylwester), which shows how the integration of Fuel and Bareon
> > [2] can
> > be done.
> >
> > To summarise the implementation:
> > * we have a simple implementation of Bareon-API [3], which stores
> > partitioning
> >   related data and allows to edit it
> > * for Nailgun new extension has been implemented [4], which uses
> Bareon-API
> >   to store partitioning information, so we will be able to easily switch
> > between
> >   classic volume_manager implementation and Bareon-API extension
> > * when provisioning gets started, extensions retrieves the data from
> > Bareon-API
> >
> > Next steps:
> > * create Bareon-API repository, and start production ready implementation
> > * create a spec for Fuel project
> > * create a spec for Bareon project
> >
> > If you have any questions don’t hesitate to ask them in this thread, also
> > you can
> > find us on #openstack-bareon channel.
> >
> > Thanks!
> >
> > [0]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
> > [1] https://www.youtube.com/watch?v=GTJM8i7DL0w
> > [2]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
> > [3] https://github.com/Mirantis/bareon-api
> > [4] https://review.openstack.org/#/c/250864/
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Evgeniy L]

Hi Oleg,

I understand the concern, but in case of integration specifically with
Solar,
I don't see any reasons to add ConfigDB, because Solar by itself is a
ConfigDB.
At the same time I would agree that there might be a case, when user uses
Zookeeper/Puppet Master/CMDB as a data store, in this case we should store
the data directly in those services, without keeping them in yet another
storage.

So the flow will look like this:
Components ->
Data get polled by data processors ->
| Solar data processor puts the data into Solar in its format
| Zookeeper data processor puts the data into Zookeeper in its format
| Custom CMDB data processor puts the data into CMDB in its own format

Thanks,

On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh  wrote:

> Hi,
>
> The idea behind configdb is that it is independent component that defines
> data flows between other components of the system. It has no knowledge
> about those components or specifics of their data. Data formats are defined
> by components themselves via schemas/templates and can be changed at any
> time (i.e. don't require code changes).
>
> Important 'pro' having ConfigDB separate from Solar is that it will
> simplify transition from current Fuel architecture by breaking it into more
> definite stages and reducing the number of components Solar have to be
> integrated with.
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>
>> Hi Dmitry,
>>
>> I also don't think that we should duplicate the data in configdb,
>> because in this case there will be +2 additional interfaces which
>> will require to covert the data into configdb and after that from
>> configdb to Solar, which seems redundant overhead.
>>
>> But we should be able to put the data directly to user's
>> CMDB/ZooKeeper/Puppet Master/etc.
>>
>> Thanks,
>>
>> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak 
>> wrote:
>>
>>> Hello folks,
>>>
>>> This topic is about configuration storage which will connect data
>>> sources (nailgun/bareon/others) and orchestration. And right now we are
>>> developing two projects that will overlap a bit.
>>>
>>> I understand there is not enough context to dive into this thread right
>>> away, but i will appreciate if those people, who participated in design,
>>> will add their opinions/clarifications on this matter.
>>>
>>> Main disagreements
>>> ---
>>> 1. configdb should be passive, writing to configdb is someone else
>>> responsibility
>>> + simpler implementation, easier to use
>>> - we will need another component that will do writing, or split this
>>> responsibility somehow
>>>
>>> 2. can be used without other solar components
>>> + clear inteface between solar components and storage layer
>>> - additional work required to design/refactor communication layer
>>> between modules in solar
>>> - some data will be duplicated between solar orchestrator layer and
>>> configdb
>>>
>>> 3. templates for output
>>> technical detail, can be added on top of solardb if required
>>>
>>> Similar functionality
>>> --
>>> 1. Hierachical storage
>>> 2. Versioning of changes
>>> 3. Possibility to overwrite config values
>>> 4. Schema for inputs
>>>
>>> Overall it seems that we share same goals for both services,
>>> the difference lies in organizational and technical implementation
>>> details.
>>>
>>> Possible solutions
>>> 
>>> 1. develop configdb and solar with duplicated functionality
>>> - at least 2 additional components will be added to the picture,
>>> one is configdb, another one will need to sync data between configdb and
>>> solar
>>> - in some cases data in solar and configdb will be 100% duplicated
>>> - different teams will work on same functionality
>>> - integration of additional component for fuel will require integration
>>> with
>>> configdb and with solar
>>> + configdb will be independent from solar orchestration/other components
>>>
>>> 2. make service out of solardb, allign with configdb use cases
>>> + solardb will be independent from solar orchestration/other solar
>>> components
>>> + integration of fuel component will be easier than in 1st version
>>> + clarity about components responsibility and new architecture
>>> - redesign/refactoring co

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

[Evgeniy L]

Comments inline.

On Mon, Dec 21, 2015 at 1:42 PM, Oleg Gelbukh  wrote:

> The problem with this approach is that we can't manage the interfaces
> between components without changing the code of 2+ components (i.e. one
> that provides the data and all that consume it).
>

I'm not sure if understand you correctly, none of these approaches
require to change the components, we will have change a single
place, which is specific data processor.


>
> I also don't like polling model for data processors. In my understanding,
> components should push their changes through the pipeline. Although this is
> pure implementation detail and is not really important ATM.
>

We don't have any other choice, we don't control components, configuration
components are not going to implement Fuel specific logic, so Fuel has
to pool the data.


>
> The point is that for Solar integration, we still need integration points,
> and the less of them we have, the more simple the transition is going to
> be..
>

As described above, there will be a single integration point, data
processor.

>
> --
> Best regards,
> Oleg Gelbukh
>
> On Mon, Dec 21, 2015 at 11:32 AM, Evgeniy L  wrote:
>
>> Hi Oleg,
>>
>> I understand the concern, but in case of integration specifically with
>> Solar,
>> I don't see any reasons to add ConfigDB, because Solar by itself is a
>> ConfigDB.
>> At the same time I would agree that there might be a case, when user uses
>> Zookeeper/Puppet Master/CMDB as a data store, in this case we should store
>> the data directly in those services, without keeping them in yet another
>> storage.
>>
>> So the flow will look like this:
>> Components ->
>> Data get polled by data processors ->
>> | Solar data processor puts the data into Solar in its format
>> | Zookeeper data processor puts the data into Zookeeper in its format
>> | Custom CMDB data processor puts the data into CMDB in its own format
>>
>> Thanks,
>>
>> On Fri, Dec 18, 2015 at 7:00 PM, Oleg Gelbukh 
>> wrote:
>>
>>> Hi,
>>>
>>> The idea behind configdb is that it is independent component that
>>> defines data flows between other components of the system. It has no
>>> knowledge about those components or specifics of their data. Data formats
>>> are defined by components themselves via schemas/templates and can be
>>> changed at any time (i.e. don't require code changes).
>>>
>>> Important 'pro' having ConfigDB separate from Solar is that it will
>>> simplify transition from current Fuel architecture by breaking it into more
>>> definite stages and reducing the number of components Solar have to be
>>> integrated with.
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh
>>>
>>> On Wed, Dec 16, 2015 at 4:38 PM, Evgeniy L  wrote:
>>>
>>>> Hi Dmitry,
>>>>
>>>> I also don't think that we should duplicate the data in configdb,
>>>> because in this case there will be +2 additional interfaces which
>>>> will require to covert the data into configdb and after that from
>>>> configdb to Solar, which seems redundant overhead.
>>>>
>>>> But we should be able to put the data directly to user's
>>>> CMDB/ZooKeeper/Puppet Master/etc.
>>>>
>>>> Thanks,
>>>>
>>>> On Wed, Dec 16, 2015 at 2:03 AM, Dmitriy Shulyak >>> > wrote:
>>>>
>>>>> Hello folks,
>>>>>
>>>>> This topic is about configuration storage which will connect data
>>>>> sources (nailgun/bareon/others) and orchestration. And right now we are
>>>>> developing two projects that will overlap a bit.
>>>>>
>>>>> I understand there is not enough context to dive into this thread
>>>>> right away, but i will appreciate if those people, who participated in
>>>>> design, will add their opinions/clarifications on this matter.
>>>>>
>>>>> Main disagreements
>>>>> ---
>>>>> 1. configdb should be passive, writing to configdb is someone else
>>>>> responsibility
>>>>> + simpler implementation, easier to use
>>>>> - we will need another component that will do writing, or split this
>>>>> responsibility somehow
>>>>>
>>>>> 2. can be used without other solar components
>>>>> + clear inteface between solar components and stora

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Evgeniy L]

Hi,

We mustn't touch Nailgun's logic, otherwise after upgrade user won't be able
to manage her/his old nova Cluster. So lets just remove it from UI.
Also as far as I know we should provide a way to manage old clusters not
for a release, but for a couple of years.

Thanks,

On Tue, Dec 22, 2015 at 10:40 AM, Igor Kalnitsky 
wrote:

> I don't think it's a good idea to drop support of 7.0 nova-network
> setup in 8.0. We should keep compatibility for at least one release.
>
> On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin
>  wrote:
> > Sergii,
> >
> > We could remove it completely from nailgun if support for 7.0 and
> earlier is
> > not required.
> >
> >
> > Aleksey Kasatkin
> >
> >
> > On Tue, Dec 22, 2015 at 3:27 AM, Sergii Golovatiuk
> >  wrote:
> >>
> >> Hi,
> >>
> >> Finally we can deprecate nova-network ...
> >> We should remove it from UI, nailgun logic and tests to have less
> >> technical debt.
> >>
> >> --
> >> Best regards,
> >> Sergii Golovatiuk,
> >> Skype #golserge
> >> IRC #holser
> >>
> >> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
> >> wrote:
> >>>
> >>> Hey guys –
> >>>
> >>>
> >>>
> >>> I know this has been a topic of a lot of discussion – Adrian informed
> me
> >>> on Friday that QA has confirmed the multi-hypervisor use case has been
> >>> tested successfully without nova-network, so we can finally deprecate
> it!
> >>>
> >>>
> >>>
> >>> Users who want to deploy multiple hypervisors will need to use the Fuel
> >>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and
> the
> >>> KVM/QEMU computes can use Neutron + GRE/VXLAN.
> >>>
> >>>
> >>>
> >>> I’ve created a kind of “cover all the things” bug here:
> >>> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
> >>> nova-network right now in Fuel, I have marked it as Critical.
> >>>
> >>>
> >>>
> >>> Let’s start the conversation on here and make sure all the bases are
> >>> covered – if additional bugs need to be logged or there’s
> administrative
> >>> overhead, let me know and I’ll be happy to help out!
> >>>
> >>>
> >>>
> >>> Sheena Gregson | Sr. Product Manager | Mirantis
> >>>
> >>> p: +1 650 646 3302 | e: sgreg...@mirantis.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

[Evgeniy L]

Hi Aleksey,

Since Fuel's FF is on 2nd of March, I don't think that full switch from
fuel-agent + nailgun volume manager to Bareon will happen.
Also Bareon will have separate from Fuel release cycle, so you will have
to land the feature first into Bareon and then to Fuel.

Could you please provide a bit more information on what features are
needed in the agent for 9.0 Fuel release?

Thanks,

On Tue, Dec 29, 2015 at 1:38 PM, Aleksey Zvyagintsev <
azvyagint...@mirantis.com> wrote:

>
> Guys, do you have any plans to achieve integration for fuel9\fuel-next
> ?(and final switching from fuel-agent to BareOn will be...?)
> We are going to implement some new features for fuel - and the main
> question should we push it into fuel-agent or in newer BareOn?
>
>
> On Mon, Dec 28, 2015 at 11:56 PM, Tomasz Napierala <
> tnapier...@mirantis.com> wrote:
>
>> I agree with Evgeny: from work organization it would more optimal to have
>> 2 repos. API and system facing programming are completely different
>> domains, requiring different skill sets. In my opinion separation would
>> lower the entry barriers.
>>
>> Regards,
>>
>> > On 17 Dec 2015, at 15:53, Evgeniy L  wrote:
>> >
>> > Hi Igor,
>> >
>> > Bareon by itself doesn't have any REST interface, Bareon is basically
>> fuel_agent,
>> > which is framework + CLI wrapper to use it as an agent.
>> > In order to store and edit required entities in the database we need
>> some wrapper,
>> > which adds this functionality. This simple wrapper will be implemented
>> in Bareon-API.
>> > User should be able to use Bareon without any additional API/Database
>> if she/he
>> > wants to do some basic stuff without need to store the configuration,
>> which is not
>> > Fuel use case.
>> > If the question was specifically about Bareon-API in separate repo,
>> there is no
>> > reason to store it in a single repo, since we may have separate teams
>> working
>> > on those sub-projects and those solve a bit different problems, user
>> facing api
>> > vs low level tools.
>> >
>> > Thanks,
>> >
>> > On Thu, Dec 17, 2015 at 5:33 PM, Igor Kalnitsky <
>> ikalnit...@mirantis.com> wrote:
>> > > create Bareon-API repository, and start production ready
>> implementation
>> >
>> > For what reason do we need a separate repo? I thought API will be a
>> > part of bareon repo. Or bareon is just a provisioning agent, which
>> > will be driven by bareon-api?
>> >
>> > On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L  wrote:
>> > > Hi,
>> > >
>> > > Some time ago, we’ve started a discussion [0] about Fuel
>> modularisation
>> > > activity.
>> > > Due to unexpected circumstances POC has been delayed.
>> > >
>> > > Regarding to partitioning/provisioning system, we have POC with a
>> demo [1]
>> > > (thanks to Sylwester), which shows how the integration of Fuel and
>> Bareon
>> > > [2] can
>> > > be done.
>> > >
>> > > To summarise the implementation:
>> > > * we have a simple implementation of Bareon-API [3], which stores
>> > > partitioning
>> > >   related data and allows to edit it
>> > > * for Nailgun new extension has been implemented [4], which uses
>> Bareon-API
>> > >   to store partitioning information, so we will be able to easily
>> switch
>> > > between
>> > >   classic volume_manager implementation and Bareon-API extension
>> > > * when provisioning gets started, extensions retrieves the data from
>> > > Bareon-API
>> > >
>> > > Next steps:
>> > > * create Bareon-API repository, and start production ready
>> implementation
>> > > * create a spec for Fuel project
>> > > * create a spec for Bareon project
>> > >
>> > > If you have any questions don’t hesitate to ask them in this thread,
>> also
>> > > you can
>> > > find us on #openstack-bareon channel.
>> > >
>> > > Thanks!
>> > >
>> > > [0]
>> > >
>> http://lists.openstack.org/pipermail/openstack-dev/2015-October/077025.html
>> > > [1] https://www.youtube.com/watch?v=GTJM8i7DL0w
>> > > [2]
>> > >
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
>> > > [3] https://github.com/Mirantis/bareon-api
>> > 

Re: [openstack-dev] [fuel] github can't sync with git because of big uploading

[Evgeniy L]

Hi,

You should probably talk to infra team on this issue #openstack-infra
channel.
I see several ways what can be done here:
1. recreate the repo
2. create a repo with different name

Also there is possibility to remove from the commit those files and push
using --force,
but it's a very bad practise and I don't think that infra allows to do that.

Thanks,

On Wed, Dec 30, 2015 at 5:34 AM, wuwenbin  wrote:

> Hi all:
>
>  Repo of fuel-plugin-onos has something wrong because of uploading
> big file. Though codes are reverted while history still contains the pack
> which results in big downloading and unsync with github.
>
>  I really want to solve this problem and please forgive my own
> decision for a new commit of new onosfw because I don’t want this impacting
> the project. I have to admit that I am really bad at management of commit
> and merge. So I invite fuel ptl as the manager of new repo to avoid such
> things.
>
>  Does anyone can help me solve this as soon as possible?
>
>Thanks
>
> Bests
>
> Cathy
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

[Evgeniy L]

Hi,

For the last several weeks I've been working on algorithm (and prototype)
for dynamic allocation of volumes on disks.

I have some results [0] and would like to ask you to review it and provide
some feedback.

Our plan is to implement it as an external driver for Bareon [1].

Thanks,

[0] http://bareon-allocator.readthedocs.org/en/latest/architecture.html
[1] https://wiki.openstack.org/wiki/Bareon
__
OpenStack Development Mailing 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] [Bareon][Fuel] Dynamic allocation algorithm

[Evgeniy L]

Hi Artur,

You are correct, we probably may consider using bytes instead of megabytes.

Regarding to question "ssd vs hdd", user can describe which space is better
to allocate on ssd and which is better on hdd, the mechanism is completely
data driven,
it can be done using "best_with_disks" [0], in fact it covers much more
cases,
since user can build sets of disks where space can be allocated based on any
parameter of HW which discovery can provide.

Thanks,

[0]
http://bareon-allocator.readthedocs.org/en/latest/architecture.html#best-with-disks

On Wed, Jan 13, 2016 at 1:56 PM, Artur Svechnikov 
wrote:

> Hi.
>
> Very good documentation. For Integer Solution you can use bytes instead of
> megabytes. Hence N bytes will be unallocated in the worst case.
>
> I didn't find solution for problem:
>
>- Don’t allocate a single volume on ssd and hdd
>
>
> Best regards,
> Svechnikov Artur
>
> On Tue, Jan 12, 2016 at 9:37 PM, Evgeniy L  wrote:
>
>> Hi,
>>
>> For the last several weeks I've been working on algorithm (and prototype)
>> for dynamic allocation of volumes on disks.
>>
>> I have some results [0] and would like to ask you to review it and provide
>> some feedback.
>>
>> Our plan is to implement it as an external driver for Bareon [1].
>>
>> Thanks,
>>
>> [0] http://bareon-allocator.readthedocs.org/en/latest/architecture.html
>> [1] https://wiki.openstack.org/wiki/Bareon
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

[Evgeniy L]

Hi,

In addition I've generated several examples in order to show how current
prototype allocates the volumes [0].

Thanks,

[0] http://bareon-allocator.readthedocs.org/en/latest/examples.html


On Wed, Jan 13, 2016 at 2:14 PM, Evgeniy L  wrote:

> Hi Artur,
>
> You are correct, we probably may consider using bytes instead of megabytes.
>
> Regarding to question "ssd vs hdd", user can describe which space is better
> to allocate on ssd and which is better on hdd, the mechanism is completely
> data driven,
> it can be done using "best_with_disks" [0], in fact it covers much more
> cases,
> since user can build sets of disks where space can be allocated based on
> any
> parameter of HW which discovery can provide.
>
> Thanks,
>
> [0]
> http://bareon-allocator.readthedocs.org/en/latest/architecture.html#best-with-disks
>
> On Wed, Jan 13, 2016 at 1:56 PM, Artur Svechnikov <
> asvechni...@mirantis.com> wrote:
>
>> Hi.
>>
>> Very good documentation. For Integer Solution you can use bytes instead
>> of megabytes. Hence N bytes will be unallocated in the worst case.
>>
>> I didn't find solution for problem:
>>
>>- Don’t allocate a single volume on ssd and hdd
>>
>>
>> Best regards,
>> Svechnikov Artur
>>
>> On Tue, Jan 12, 2016 at 9:37 PM, Evgeniy L  wrote:
>>
>>> Hi,
>>>
>>> For the last several weeks I've been working on algorithm (and prototype)
>>> for dynamic allocation of volumes on disks.
>>>
>>> I have some results [0] and would like to ask you to review it and
>>> provide
>>> some feedback.
>>>
>>> Our plan is to implement it as an external driver for Bareon [1].
>>>
>>> Thanks,
>>>
>>> [0] http://bareon-allocator.readthedocs.org/en/latest/architecture.html
>>> [1] https://wiki.openstack.org/wiki/Bareon
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Evgeniy L]

Hi Simon,

As far as I know it's expected behaviour (at least for the current
release), and it's expected that user reruns deployment on required nodes
using fuel cli, in order to install plugin on a live environment.
It depends on specific role, but "update_required" field may help you, it
can be added to role description, Fuel reruns deployment on nodes with
roles, which are specified in the list, if new node with the role is added
to the environment.

Thanks,

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18

On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
wrote:

> Hi,
> I'm testing the ability to install Fuel plugins in a an environment that
> is already deployed.
> My starting environment is quite simple: 1 controller + 1 compute. After
> the initial deployment, I've installed the 4 LMA plugins:
> - LMA collector
> - Elasticsearch-Kibana [*]
> - InfluxDB-Grafana [*]
> - Infrastructure Alerting [*]
> [*] adds a new role
> Of course, all plugins have "is_hotpluggable: true" in their metadata
> definition.
> My expectation is that I can add a new node with the new roles and that
> the LMA collector tasks are executed for all 3 nodes. So I've added the new
> node and click the "Deploy changes" button. My re-deployment runs fine but
> I notice that the plugins aren't installed on the existing nodes (eg
> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
> executed on already deployed nodes... Is this a known limitation? Am I
> missing something?
> Best regards,
> Simon
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

[Evgeniy L]

Simon,

>> Any plan to have a nicer experience in future Fuel releases?

I haven't heard about any plans on improvements for that, but management
team should know better whether it's on roadmap or not.

Thanks,

On Fri, Feb 5, 2016 at 1:52 PM, Simon Pasquier 
wrote:

> Thanks Evgeniy.
>
> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L  wrote:
>
>> Hi Simon,
>>
>> As far as I know it's expected behaviour (at least for the current
>> release), and it's expected that user reruns deployment on required nodes
>> using fuel cli, in order to install plugin on a live environment.
>>
>
> Ok. For the record, this means running this command for every node that is
> already deployed:
> $ fuel node --node-id  --deploy
>
> Any plan to have a nicer experience in future Fuel releases?
>
>
>> It depends on specific role, but "update_required" field may help you, it
>> can be added to role description, Fuel reruns deployment on nodes with
>> roles, which are specified in the list, if new node with the role is added
>> to the environment.
>>
>
> Nope, it doesn't work for me since it should run for *all* the nodes,
> irrespective of their roles. AFAIK update_required doesn't support '*'.
>
>
>>
>> Thanks,
>>
>> [1]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L16-L18
>>
>> On Fri, Feb 5, 2016 at 12:53 PM, Simon Pasquier 
>> wrote:
>>
>>> Hi,
>>> I'm testing the ability to install Fuel plugins in a an environment that
>>> is already deployed.
>>> My starting environment is quite simple: 1 controller + 1 compute. After
>>> the initial deployment, I've installed the 4 LMA plugins:
>>> - LMA collector
>>> - Elasticsearch-Kibana [*]
>>> - InfluxDB-Grafana [*]
>>> - Infrastructure Alerting [*]
>>> [*] adds a new role
>>> Of course, all plugins have "is_hotpluggable: true" in their metadata
>>> definition.
>>> My expectation is that I can add a new node with the new roles and that
>>> the LMA collector tasks are executed for all 3 nodes. So I've added the new
>>> node and click the "Deploy changes" button. My re-deployment runs fine but
>>> I notice that the plugins aren't installed on the existing nodes (eg
>>> /etc/fuel/plugins/...) so there is no way that the plugins tasks can be
>>> executed on already deployed nodes... Is this a known limitation? Am I
>>> missing something?
>>> Best regards,
>>> Simon
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

[Evgeniy L]

+1

On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky 
wrote:

> Hey Fuelers,
>
> I'd like to nominate Fedor Zhadaev for the fuel-menu-core team.
> Fedor's doing good review with detailed feedback [1], and has
> contributes over 20 patches during Mitaka release cycle [2].
>
> Fuel Cores, please reply back with +1/-1.
>
> - igor
>
> [1] http://stackalytics.com/?module=fuel-menu&release=mitaka
> [2]
> http://stackalytics.com/?module=fuel-menu&release=mitaka&user_id=fzhadaev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Bareon][Fuel] Best practises on syncing patches between repositories

[Evgeniy L]

Hi,

Some time ago we started Bareon project [1], and now we have some fixes
landed to
fuel-agent only, the question is what are the best practises on keeping two
repos in sync
with possibility to resolve conflicts manually? Cherry-picking patches
manually doesn't look
like the most error prone solution, are there any scripts written to make
sure that repos are
in one way sync (fuel-agent -> Bareon)?

Thanks,

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082397.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

[Evgeniy L]

+1

On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> +1 to enable it ASAP.
>
> It will also affect our deployment tests (~1 hour vs. ~2.5 hours).
>
> Vladimir Kozhukalov
>
> On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin 
> wrote:
>
>> +1.
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> > On 08 Feb 2016, at 19:05, Igor Kalnitsky 
>> wrote:
>> >
>> > Hey Fuelers,
>> >
>> > When we are going to enable it? I think since HCF is passed for
>> > stable/8.0, it's time to enable task-based deployment for master
>> > branch.
>> >
>> > Opinion?
>> >
>> > - Igor
>> >
>> > On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya <
>> bdobre...@mirantis.com> wrote:
>> >> On 02.02.2016 17:35, Alexey Shtokolov wrote:
>> >>> Hi Fuelers!
>> >>>
>> >>> As you may be aware, since [0] Fuel has implemented a new
>> orchestration
>> >>> engine [1]
>> >>> We switched the deployment paradigm from role-based (aka granular) to
>> >>> task-based and now Fuel can deploy all nodes simultaneously using
>> >>> cross-node dependencies between deployment tasks.
>> >>
>> >> That is great news! Please do not forget about docs updates as well.
>> >> Those docs are always forgotten like poor orphans... I submitted a
>> patch
>> >> [0] to MOS docs, please review and add more details, if possible, for
>> >> plugins impact as well.
>> >>
>> >> [0] https://review.fuel-infra.org/#/c/16509/
>> >>
>> >>>
>> >>> This feature is experimental in Fuel 8.0 and will be enabled by
>> default
>> >>> for Fuel 9.0
>> >>>
>> >>> Allow me to show you the results. We made some benchmarks on our bare
>> >>> metal lab [2]
>> >>>
>> >>> Case #1. 3 controllers + 7 computes w/ ceph.
>> >>> Task-based deployment takes *~38* minutes vs *~1h15m* for granular
>> (*~2*
>> >>> times faster)
>> >>> Here and below the deployment time is average time for 10 runs
>> >>>
>> >>> Case #2. 3 controllers + 3 mongodb + 4 computes w/ ceph.
>> >>> Task-based deployment takes *~41* minutes vs *~1h32m* for granular
>> >>> (*~2.24* times faster)
>> >>>
>> >>>
>> >>>
>> >>> Also we took measurements for Fuel CI test cases. Standard BVT (Master
>> >>> node + 3 controllers + 3 computes w/ ceph. All are in qemu VMs on one
>> host)
>> >>>
>> >>> Fuel CI slaves with *4 *cores *~1.1* times faster
>> >>> In case of 4 cores for 7 VMs they are fighting for CPU resources and
>> it
>> >>> marginalizes the gain of task-based deployment
>> >>>
>> >>> Fuel CI slaves with *6* cores *~1.6* times faster
>> >>>
>> >>> Fuel CI slaves with *12* cores *~1.7* times faster
>> >>
>> >> These are really outstanding results!
>> >> (tl;dr)
>> >> I believe the next step may be to leverage the "external install & svc
>> >> management" feature (example [1]) of the Liberty release (7.0.0) of
>> >> Puppet-Openstack (PO) modules. So we could use separate concurrent
>> >> cross-depends based tasks *within a single node* as well, like:
>> >> - task: install_all_packages - a singleton task for a node,
>> >> - task: [configure_x, for each x] - concurrent for a node,
>> >> - task: [manage_service_x, for each x] - some may be concurrent for a
>> >> node, while another shall be serialized.
>> >>
>> >> So, one might use the "--tags" separator for concurrent puppet runs to
>> >> make things go even faster, for example:
>> >>
>> >> # cat test.pp
>> >> notify
>> >> {"A": tag => "a" }
>> >> notify
>> >> {"B": tag => "b" }
>> >>
>> >> # puppet apply test.pp
>> >> Notice: A
>> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> >> Notice: B
>> >> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B'
>> >>
>> >> # puppet apply test.pp --tags a
>> >> Notice: A
>> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> >>
>> >> # puppet apply test.pp --tags a & puppet apply test.pp --tags b
>> >> Notice: B
>> >> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B'
>> >> Notice: A
>> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A'
>> >>
>> >> Which is supposed to be faster, although not for this example.
>> >>
>> >> [1] https://review.openstack.org/#/c/216926/3/manifests/init.pp
>> >>
>> >>>
>> >>> You can see additional information and charts in the presentation [3].
>> >>>
>> >>> [0]
>> >>> -
>> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html
>> >>> [1]
>> >>> -
>> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html
>> >>> [2] -  3 x HP ProLiant DL360p Gen8 (XeonE5 6 cores/64GB/SSD)  + 7 x HP
>> >>> ProLiant DL320p Gen8 (XeonE3 4 cores/8-16GB/HDD)
>> >>> [3] -
>> >>>
>> https://docs.google.com/presentation/d/1jZCFZlXHs_VhjtVYS2VuWgdxge5Q6sOMLz4bRLuw7YE
>> >>>
>> >>> ---
>> >>> WBR, Alexey Shtokolov
>> >>>
>> >>>
>> >>>
>> __
>> >>> OpenStack Development Mailing List (not for usage questions)
>> >>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Evgeniy L]

Hi,

As an author of this part of pluggable architecture I can shade more light
on why it was implemented this way and why it's valuable to continue
supporting multi-release feature.

At the time it was implemented Fuel officially was supporting both Ubuntu
and CentOS, in order to simplify plugins distribution development and
support,
plugin developer was able to create a single plugin which supports both
operating systems, deployment scripts in the most cases support both
operating systems, if they are not, there is enough flexibility to specify
different set of deployment scripts and repositories.

We don't force plugin developer to support all range of releases in a single
plugin, it's up to plugin developer to decide what mechanism is better for
specific plugin, I'm strongly against of making "single release a.k.a os"
plugins.

Also suggested change will dramatically complicate distribution when we
get heterogeneous environments (different operating system in a single
environment).

Bulat is right that there are issues, but those issues has to be fixed, and
there is straightforward way to do it.

To summarise, I don't think that we should force the developer to follow
specific release schema, let the developer decide.

Thanks,


On Thu, Feb 11, 2016 at 10:16 AM, Bulat Gaifullin 
wrote:

> I agree with Stas, one rpm - one version.
>
> But plugin builder allows to specify several releases as compatible. The
> deployment tasks and repositories can be specified per release, at the same
> time the deployment graph is one for all releases.
> Currently it looks like half-implemented feature.  Can we drop this
> feature? or should we finish implementation of this feature.
>
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 11 Feb 2016, at 02:41, Andrew Woodward  wrote:
>
>
>
> On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> +1 to Stas, supplanting VCS branches with code duplication is a path to
>> madness and despair. The dubious benefits of a cross-release backwards
>> compatible plugin binary are not worth the code and infra technical debt
>> that such approach would accrue over time.
>>
>
> Supporting multiple fuel releases will likely result in madness as
> discussed, however as we look to support multiple OpenStack releases from
> the same version of fuel, this methodology becomes much more important.
>
>
>> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
>> > It changes mostly nothing for case of furious plugin development when
>> big
>> > parts of code changed from one release to another.
>> >
>> > You will have 6 different deployment_tasks directories and 30 a little
>> bit
>> > different files in root directory of plugin. Also you forgot about
>> > repositories directory (+6 at least), pre_build hooks (also 6) and so
>> on.
>> > It will look as hell after just 3 years of development.
>> >
>> > Also I can't imagine how to deal with plugin licensing if you have
>> Apache
>> > for liberty but BSD for mitaka release, for example.
>> >
>> > Much easier way to develop a plugin is to keep it's source in VCS like
>> Git
>> > and just make a branches for every fuel release. It will give us
>> > opportunity to not store a bunch of similar but a little bit different
>> > files in repo. There is no reason to drag all different versions of code
>> > for specific release.
>> >
>> >
>> > On other hand there is a pros - your plugin can survive after upgrade
>> if it
>> > supports new release, no changes needed here.
>> >
>> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <
>> ashtoko...@mirantis.com>
>> > wrote:
>> >
>> > > Fuelers,
>> > >
>> > > We are discussing the idea to extend the multi release packages for
>> > > plugins.
>> > >
>> > > Fuel plugin builder (FPB) can create one rpm-package for all supported
>> > > releases (from metadata.yaml) but we can specify only deployment
>> scripts
>> > > and repositories per release.
>> > >
>> > > Current release definition (in metadata.yaml):
>> > > - os: ubuntu
>> > >   version: liberty-8.0
>> > >   mode: ['ha']
>> > >   deployment_scripts_path: deployment_scripts/
>> > >   repository_path: repositories/ubuntu
>> > >
>>
>
> This will result in far too much clutter.
> For starters we should support nested over rides. for example the author
> may have already taken account for the changes between one openstack
> version to another. In this case they only should need to define the
> releases they support and not specify any additional locations. Later they
> may determine that they only need to replace packages, or one other file
> they should not be required to code every location for each release
>
> Also, at the same time we MUST clean up importing various yaml files.
> Specifically, tasks, volumes, node roles, and network roles. Requiring that
> they all be maintained in a single file doesn't scale, we don't require it
> for tasks.yaml in fuel library, and we should not req

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Evgeniy L]

Sorry for the typo "s/I can shade more light/I can shed more light/"

On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L  wrote:

> Hi,
>
> As an author of this part of pluggable architecture I can shade more light
> on why it was implemented this way and why it's valuable to continue
> supporting multi-release feature.
>
> At the time it was implemented Fuel officially was supporting both Ubuntu
> and CentOS, in order to simplify plugins distribution development and
> support,
> plugin developer was able to create a single plugin which supports both
> operating systems, deployment scripts in the most cases support both
> operating systems, if they are not, there is enough flexibility to specify
> different set of deployment scripts and repositories.
>
> We don't force plugin developer to support all range of releases in a
> single
> plugin, it's up to plugin developer to decide what mechanism is better for
> specific plugin, I'm strongly against of making "single release a.k.a os"
> plugins.
>
> Also suggested change will dramatically complicate distribution when we
> get heterogeneous environments (different operating system in a single
> environment).
>
> Bulat is right that there are issues, but those issues has to be fixed, and
> there is straightforward way to do it.
>
> To summarise, I don't think that we should force the developer to follow
> specific release schema, let the developer decide.
>
> Thanks,
>
>
> On Thu, Feb 11, 2016 at 10:16 AM, Bulat Gaifullin  > wrote:
>
>> I agree with Stas, one rpm - one version.
>>
>> But plugin builder allows to specify several releases as compatible. The
>> deployment tasks and repositories can be specified per release, at the same
>> time the deployment graph is one for all releases.
>> Currently it looks like half-implemented feature.  Can we drop this
>> feature? or should we finish implementation of this feature.
>>
>>
>> Regards,
>> Bulat Gaifullin
>> Mirantis Inc.
>>
>>
>>
>> On 11 Feb 2016, at 02:41, Andrew Woodward  wrote:
>>
>>
>>
>> On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> +1 to Stas, supplanting VCS branches with code duplication is a path to
>>> madness and despair. The dubious benefits of a cross-release backwards
>>> compatible plugin binary are not worth the code and infra technical debt
>>> that such approach would accrue over time.
>>>
>>
>> Supporting multiple fuel releases will likely result in madness as
>> discussed, however as we look to support multiple OpenStack releases from
>> the same version of fuel, this methodology becomes much more important.
>>
>>
>>> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
>>> > It changes mostly nothing for case of furious plugin development when
>>> big
>>> > parts of code changed from one release to another.
>>> >
>>> > You will have 6 different deployment_tasks directories and 30 a little
>>> bit
>>> > different files in root directory of plugin. Also you forgot about
>>> > repositories directory (+6 at least), pre_build hooks (also 6) and so
>>> on.
>>> > It will look as hell after just 3 years of development.
>>> >
>>> > Also I can't imagine how to deal with plugin licensing if you have
>>> Apache
>>> > for liberty but BSD for mitaka release, for example.
>>> >
>>> > Much easier way to develop a plugin is to keep it's source in VCS like
>>> Git
>>> > and just make a branches for every fuel release. It will give us
>>> > opportunity to not store a bunch of similar but a little bit different
>>> > files in repo. There is no reason to drag all different versions of
>>> code
>>> > for specific release.
>>> >
>>> >
>>> > On other hand there is a pros - your plugin can survive after upgrade
>>> if it
>>> > supports new release, no changes needed here.
>>> >
>>> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <
>>> ashtoko...@mirantis.com>
>>> > wrote:
>>> >
>>> > > Fuelers,
>>> > >
>>> > > We are discussing the idea to extend the multi release packages for
>>> > > plugins.
>>> > >
>>> > > Fuel plugin builder (FPB) can create one rpm-package for all
>>> supported
>>> > > releases

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

[Evgeniy L]

Ilya,

>> My opinion that i've seen no example of multiple software of plugins
versions shipped in one package or other form of bundle. Its not a common
practice.

With plugins we extend Fuel capabilities, which supports multiple operating
system releases, so it's absolutely natural to extend multiple releases at
the same time.

>> Anyway we need to provide ability to override paths in manifest
(metadata.yaml).

Could you please provide more information on that? I'm not sure if I
understand your solution.

Also I'm not sure what we are arguing about, if plugin developer (or
certification process of some company) requires to have plugin per release,
it's *very easy* and straight forward to do it even now *without any*
changes.

If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc, let
them do it, and again when we get full support
of multi-version environments it's going to be even more crucial for UX to
have a single plugin with multi-release support.

Thanks,

On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov  wrote:

> My opinion that i've seen no example of multiple software of plugins
> versions shipped in one package or other form of bundle. Its not a common
> practice.
>
> Anyway we need to provide ability to override paths in manifest
> (metadata.yaml).
>
> So the plugin developers could use this approaches to provide multiple
> versions support:
>
> * tasks logic (do the plugin developers have access to current release
> info?)
> * hooks in pre-build process. Its not a big deal to preprocess source
> folder to build different packages with scripts that adding or removing
> some files or replacing some paths.
> * and, perhaps, logic anchors with YACL or other DSL in tasks dependancies
> if this functionality will be added this in theory could allow to use or
> not to use some graph parts depending on release.
>
> I think its already better than nothing and more flexible than any
> standardised approach.
>
> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier 
> wrote:
>
>> Hi,
>>
>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky > > wrote:
>>
>>> Hey folks,
>>>
>>> The original idea is to provide a way to build plugin that are
>>> compatible with few releases. It makes sense to me, cause it looks
>>> awful if you need to maintain different branches for different Fuel
>>> releases and there's no difference in the sources. In that case, each
>>> bugfix to deployment scripts requires:
>>>
>>> * backport bugfix to other branches (N backports)
>>> * build new packages for supported releases (N builds)
>>> * release new packages (N releases)
>>>
>>> It's somehow.. annoying.
>>>
>>
>> A big +1 on Igor's remark. I've already expressed it in another thread
>> but it should be expected that plugin developers want to support 2
>> consecutive versions of Fuel for a given version of their plugin.
>> That being said, I've never had issues to do it with the current plugin
>> framework. Except when Fuel breaks the backward compatibility but it's
>> another story...
>>
>> Simon
>>
>>
>>>
>>> However, I starting agree that having all-in-one RPM when deployment
>>> scripts are different, tasks are different, roles/volumes are
>>> different, probably isn't a good idea. It basically means that your
>>> sources are completely different, and that means you have different
>>> implementations of the same plugin. In that case, in order to avoid
>>> mess in source tree, it'd be better to separate such implementations
>>> on VCS level.
>>>
>>> But I'd like to hear more opinion from plugin developers.
>>>
>>> - Igor
>>>
>>> On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin
>>>  wrote:
>>> > I agree with Stas, one rpm - one version.
>>> >
>>> > But plugin builder allows to specify several releases as compatible.
>>> The
>>> > deployment tasks and repositories can be specified per release, at the
>>> same
>>> > time the deployment graph is one for all releases.
>>> > Currently it looks like half-implemented feature.  Can we drop this
>>> feature?
>>> > or should we finish implementation of this feature.
>>> >
>>> >
>>> > Regards,
>>> > Bulat Gaifullin
>>> > Mirantis Inc.
>>> >
>>> >
>>> >
>>> > On 11 Feb 2016, at 02:41, Andrew Woodward  wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <
>>> dborodae...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> +1 to Stas, supplanting VCS branches with code duplication is a path
>>> to
>>> >> madness and despair. The dubious benefits of a cross-release backwards
>>> >> compatible plugin binary are not worth the code and infra technical
>>> debt
>>> >> that such approach would accrue over time.
>>> >
>>> >
>>> > Supporting multiple fuel releases will likely result in madness as
>>> > discussed, however as we look to support multiple OpenStack releases
>>> from
>>> > the same version of fuel, this methodology becomes much more important.
>>> >
>>> >>
>>> >> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
>>> >> > It changes mostly nothing

Re: [openstack-dev] [Fuel][Plugins] generators support in environment_config.yaml for plugins

[Evgeniy L]

Hi Sergiy,

Currently it's not possible to use generators in environment_config file,
the reason for this is generators get unwrapped before we add plugin's
attributes [1]. Could you please create a bug for fuel-python team, we'll
address this issue.

Thanks,

[1]
https://github.com/stackforge/fuel-web/blob/976baf842242a5f97c95bdc3e20328fa0558bf69/nailgun/nailgun/objects/cluster.py#L255-L264

On Tue, Jul 7, 2015 at 6:21 PM, Sergiy Lystopad 
wrote:

> Hi, colleagues
>
> Is it possible to generate random value for field (actually field with
> type: password) in environment_config.yaml
>
> I'm trying something like
> https://github.com/stackforge/fuel-web/blob/stable/6.1/nailgun/nailgun/fixtures/openstack.yaml#L836
> but seems it doesn't work
>
> Thanks
> --
> Sergiy Lystopad
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates

[Evgeniy L]

+1 for enabling auto-abandon

Sergii, I think the period should be smaller, 2 weeks - 1 month,
if patch is important, the author will unabandon it.

Thanks,

On Wed, Jul 8, 2015 at 3:50 AM, Sergii Golovatiuk 
wrote:

> 3 Months should be a good period. Sometimes, people have one month
> vacation thus it might be a problem in such cases.
>
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Tue, Jul 7, 2015 at 3:34 PM, Mike Scherbakov 
> wrote:
>
>> Hi,
>> we have too many patches which hang for over a month without attention.
>> Almost all are those which should be abandoned due to changes happened in
>> master, and need complete rework. Or, those were just proposals to make
>> something, which didn't fly. Unfortunately there are those which were good
>> ideas, but didn't attract enough attention from cores and didn't land into
>> master as a result.
>>
>> Anyway, I think we need to keep our review queues in better health. Can
>> we enable auto-abandon back again, if patch is hanging out for a month or
>> more?
>> --
>> 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
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Getting rid of launchpad group fuel-astute

[Evgeniy L]

Hi,

Agree, most of the python developers are familiar with Astute.
But at the same time it can look strange when we assign Astute (which is
written in Ruby)
bugs to the group which is called fuel-python :)

Thanks,

On Thu, Jul 16, 2015 at 2:21 PM, Alexander Kislitsky <
akislit...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to get rid of group fuel-astute on launchpad. In group only 2
> active members. Actually they are members of fuel-python team. Bugs for
> fuel-astute project always concern to fuel-web project. Bugs assigned to
> fuel-astute can stay without attention for a long time. Thus I propose to
> use fuel-python team instead fuel-astute.
>
> First of all we should reassign team for bugs [1]. After that we can
> remove or disable fuel-astute launchpad group.
>
> What do you think about this?
>
> [1] https://goo.gl/ap35t9
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel][plugins] Ability of plugin to provision switches before node deployment

[Evgeniy L]

Hi Steven, thank you for letting us know about your use case,

The problem is caused because since 6.1 release we run
part of network verification tasks before deployment [1], from
the code it can be seen, that this check is hardcoded [2], before
we send any deployment tasks, so we should figure out a way
to fix it.

Possible options:

1. run network verification us a part of deployment, somewhere
in pre_deployment stage, between pre_deployment/4999 and
pre_deployment/6000 [3], but it doesn't cover the case when user
wants to just run network verification on Network tab

2. introduce new stage pre_network_verification which will be
run before we start network verification, so you will be able
to configure switches

Also I would like to notice, that role as a plugin feature which
will allow to change deployment graph of the core, will not help
here [4]. Because network verification is not a part of the graph.

Thanks,

[1] https://bugs.launchpad.net/fuel/+bug/1439686
[2]
https://github.com/stackforge/fuel-web/commit/c4594fc2461f1cf66e580a07d32a869c3f25678d
[3] https://wiki.openstack.org/wiki/Fuel/Plugins#stage_parameter
[4]
https://github.com/stackforge/fuel-specs/blob/master/specs/7.0/role-as-a-plugin.rst

On Tue, Jul 21, 2015 at 12:49 AM, Steven Kath  wrote:

> Hi,
>
> I'm hoping to design a FUEL plugin which can provision a switch or set
> of switches according to the Network Settings specified when first
> configuring an environment in FUEL.
>
> We have puppet manifests which allow us to configure every aspect
> of our switches, including the plumbing of VLANs. It would be possible
> for us to configure the VLANs as specified in the environment's
> Network Settings prior to, or as part of, the "Verify Networks" stage.
>
> As far as I can tell, there aren't any FUEL plugin hooks this early in
> the provisioning process. I can't find where to initiate any
> configuration of a remote device before validating the network
> settings. I've looked at a number of the networking plugins for FUEL
> and they all seem to be focused on adding overlays, pre-supposing a
> static underlay network configuration which the plugins never
> manipulate.
>
> Can anyone confirm whether the current FUEL capabilities, or planned
> FUEL 7.0 functionality, would allow for this sort of pre-deployment
> network configuration?
>
> Are there any relevant documentation sections or plugin examples
> which I might have overlooked?
>
> Thanks!
> - Steven
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][python-fuelclient] Implementing new commands

[Evgeniy L]

Hi,

The best option is to add new functionality to fuel2 only, but I
don't think that we can do that if there is not enough functionality
in fuel2, we should not ask user to switch between fuel and fuel2
to get some specific functionality.
Do we have some list of commands which is not covered in fuel2?
I'm just wondering how much time will it take to implement all
required commands in fuel2.

Thanks,

On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski <
skalinow...@mirantis.com> wrote:

> Hi folks,
>
> For a some time in python-fuelclient we have two CLI apps: `fuel` and
> `fuel2`. It was done as an implementation of blueprint [1].
> Right now there is a situation where some new features are added just to
> old `fuel`, some to just `fuel2`, some to both. We cannot simply switch
> completely to new `fuel2` as it doesn't cover all old commands.
> As far as I remember there was no agreement how we should proceed with
> adding new things to python-fuelclient, so to keep all development for new
> commands I would like us to choose what will be our approach. There are 3
> ways to do it (with some pros and cons):
>
> A) Add new features only to old `fuel`.
> Pros:
>  - Implement feature in one place
>  - Almost all features are covered there
> Cons:
>  - Someone will need to port this features to new `fuel2`
>  - Issues that forced us to reimplement whole `fuel` as `fuel2`
>
> B) Add new features only to new `fuel2`
> Pros:
>  - Implement feature in one place
>  - No need to cope with issues in old `fuel` (like worse UX, etc.)
> Cons:
>  - Not all features are covered by `fuel2` so user will need to switch
> between `fuel` and `fuel2`
>
> C) Add new features to both CLIs
> Pros:
>  - User can choose which tool to use
>  - No need to port feature later...
> Cons:
>  - ...but it still doubles the work
>  - We keep alive a tool that should be replaced (old `fuel`)
>
>
> Best,
> Sebastian
>
> [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client
>
> __
> OpenStack Development Mailing 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