Re: [openstack-dev] [fuel][plugin] Is there a way to change plugin html dynamically?

[Stanislaw Bogatkin]

Hi Peter,

there are two ways I see today to have done what you want to:

First, you can change [0] and add some fields to store second netapp
device. In this case you'll need to change puppet manifests logic to use
new fields - according to current state, it's a bunch of code double or
you'll need to rewrite all this code as new type instead.

Second way, you can to do nothing with ui and just write needed values
after comma or space. In this case you'll still need to change puppet
manifests heavily.

[0]
https://github.com/openstack/fuel-plugin-cinder-netapp/blob/master/environment_config.yaml

On Sun, Sep 18, 2016 at 12:11 PM, Wang, Peter (Xu) 
wrote:

>
>
> Hi Fuel dev,
>
>
>
> I am studying the development of fuel plugin and usage of some existing
> plugins.
>
>
>
> I wondered is there a way to change the Plugin layout in settings page
> dynamically:
>
>
>
> Take netapp’s plugin as the example:
>
> https://github.com/openstack/fuel-plugin-cinder-netapp/
> blob/master/figures/cinder-netapp-7mode-iscsi-plugin.png
>
> Looks like admin can only add one netapp backend for one OpenStack cluster
> from the GUI, but what if user own 2 netapp devices to be managed?
>
>
>
> ·From GUI side:
>
> How can I do that as a plugin developer? Any reference guides on the
> layout yaml files are welcome  (environment_config.yaml)
>
> ·From puppet module side:
>
> Any reference implementation for how to enable multiple cinder backends in
> multi-backend enabled environment in one time?
>
>
>
> Thanks
>
> Peter
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Common fuel-core group for all Fuel projects

[Stanislaw Bogatkin]

Hi Vladimir,

I see one big problem here - people who have expert skills in one area (for
example, in fuel-library puppet manifests and their logic) will have
ability to set +2 and workflow +1 to reviews in other areas (for example,
in fuel-astute) where they don't have good expertise. It can lead to errors
increase and tests failures.

Also I don't feel any problems with core reviewers today (in fuel-library
at least). If someone think that patches are merged too slow - let's just
introduce new cores to corresponding teams, we have many great guys who
will be glad to do this work. A burden of one's own choice is not felt, you
know )

On Mon, Sep 5, 2016 at 2:11 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to suggest to use common fuel-core group for all Fuel projects
> instead of having separate independent 'by-project' core groups like
> 'fuel-astute-core' or 'fuel-agent-core'.
>
> Pros:
> 1) It will be easier to access core members (timezone and holiday
> tolerance)
> 2) It will be easier to manage single core group (promote new members,
> remove not active members)
>
> Cons:
> 1) Less of flexibility. Permissions will be the same for all core
> reviewers in all Fuel projects.
>
> What do you think?
>
> 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
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Propose Denis Egorenko for fuel-library core

[Stanislaw Bogatkin]

+1

On Thu, Aug 25, 2016 at 12:08 PM, Aleksandr Didenko 
wrote:

> +1
>
> On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko  > wrote:
>
>> +1
>>
>>
>> /sv
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Failed to install fuel master

[Stanislaw Bogatkin]

I believe it is a problem root. We put kickstart file as a kernel parameter
and custom usb creators sometimes do not take it to consideration. Use
plain diskdump for copy ISO onto usb stick and all should work properly in
this case. You can find more details in official documentation for Fuel 8.0
[0].

[0]
https://docs.mirantis.com/openstack/fuel/fuel-8.0/fuel-install-guide.html#install-prepare-install-media

On Thu, Jul 7, 2016 at 12:53 PM, Alioune <baliou...@gmail.com> wrote:

> Hi guys,
> I'm using Fuel-8.0  iso, I used "Lili USB Creator" to write ISO to the
> USB.
> (I tried this process for ubuntu-server.iso and it worked correctly).
>
> Regards,
>
> On 7 July 2016 at 09:54, Stanislaw Bogatkin <sbogat...@mirantis.com>
> wrote:
>
>> Hi guys,
>>
>> could you tell which way you used to write ISO to the USB stick?
>>
>> On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan <jack.mor...@intel.com>
>> wrote:
>>
>>> I'm pretty sure this is a USB stick install as I've seen the same
>>> failure on Fuel-8.0. Basically, the installer is not able to find the
>>> mounted drive to run the kickstart file. Duel layer DVD media or a virtual
>>> Fuel master are the only ways I've gotten Fuel-8.0 to install.
>>>
>>> On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
>>>
>>> Hi, Alioune
>>>
>>> Let's start with the most basic steps. Which Fuel are you using?
>>> And how do you install the node? Do you use USB stick or DVD or some
>>> IPMI virtual media? From what I see here it pretty much looks like, that
>>> this media is not inserted into the host.
>>>
>>> On Tue, Jul 5, 2016 at 3:11 PM, Alioune <baliou...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to install fuel master using [1] on phycal server but the
>>>> installation process fails and switches to a dracut console with the
>>>> following error:
>>>>
>>>> dracut-initqueue[595] floppy0: no floppy controllers found
>>>> dracut-initqueue[595] Warning: failed to fetck kickstart from
>>>> hd:sr0:/ks.cfg
>>>> dracut-initqueue[595] mount: no medium found on /dev/sr0
>>>> dracut-initqueue[595] Warning: Cloud not boot
>>>> dracut-initqueue[595] Warning: /dev/root does not exist
>>>>
>>>>
>>>> Starting Dracut Emergency Shell
>>>> Warning: /dev/root does not exist
>>>> Generating "/run/initramfs/rdsosreport.txt"
>>>> dracut:/#
>>>>
>>>> Any suggestion for solving that error ?
>>>>
>>>> Regards,
>>>>
>>>> [1]
>>>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com <http://www.mirantis.ru/>
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>> --
>>> Jack Morgan
>>> OPNFV Pharos Intel Lab
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> with best regards,
>> Stan.
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Failed to install fuel master

[Stanislaw Bogatkin]

Hi guys,

could you tell which way you used to write ISO to the USB stick?

On Thu, Jul 7, 2016 at 9:17 AM, Jack Morgan  wrote:

> I'm pretty sure this is a USB stick install as I've seen the same failure
> on Fuel-8.0. Basically, the installer is not able to find the mounted drive
> to run the kickstart file. Duel layer DVD media or a virtual Fuel master
> are the only ways I've gotten Fuel-8.0 to install.
>
> On 07/05/2016 05:22 AM, Vladimir Kuklin wrote:
>
> Hi, Alioune
>
> Let's start with the most basic steps. Which Fuel are you using?
> And how do you install the node? Do you use USB stick or DVD or some IPMI
> virtual media? From what I see here it pretty much looks like, that this
> media is not inserted into the host.
>
> On Tue, Jul 5, 2016 at 3:11 PM, Alioune  wrote:
>
>> Hi all,
>>
>> I'm trying to install fuel master using [1] on phycal server but the
>> installation process fails and switches to a dracut console with the
>> following error:
>>
>> dracut-initqueue[595] floppy0: no floppy controllers found
>> dracut-initqueue[595] Warning: failed to fetck kickstart from
>> hd:sr0:/ks.cfg
>> dracut-initqueue[595] mount: no medium found on /dev/sr0
>> dracut-initqueue[595] Warning: Cloud not boot
>> dracut-initqueue[595] Warning: /dev/root does not exist
>>
>>
>> Starting Dracut Emergency Shell
>> Warning: /dev/root does not exist
>> Generating "/run/initramfs/rdsosreport.txt"
>> dracut:/#
>>
>> Any suggestion for solving that error ?
>>
>> Regards,
>>
>> [1]
>> http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/install/install_prepare_install_media.html
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Jack Morgan
> OPNFV Pharos Intel Lab
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] YAQL console for master node

[Stanislaw Bogatkin]

Hi all,

as you maybe know, new conditions for Fuel tasks were recently (in master
and mitaka branches) introduced. Right after this I got several questions
like 'hey, how can I check my new condition?' Answer could be 'use standard
yaql console', but it hasn't have Fuel internal yaql functions which were a
foundation for Fuel task conditions. As a result, I have written small
utility to give an opportunity for check new conditions on the fly: [0]. It
still in development but usable for most tasks developer usually need when
build new yaql condition for task.

If you has any questions about using this tool or want to propose any
improvement - don't hesitate and contact me. Or just fork it and do what
you want - it licensed under GPLv3. I would be glad if it helps someone.

[0] https://github.com/sorrowless/fuyaql

-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Broken plugins.

[Stanislaw Bogatkin]

Hi guys,

if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that we need
1-2 days more to get this done.

Sorry for inconvenience.

[0] https://review.openstack.org/#/c/300637/

-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Broken plugins.

[Stanislaw Bogatkin]

Hi guys,

if you develop or testing Fuel plugins with current Fuel master ISOs - be
aware that with last changes into Fuel tasks serialize system plugins are
currently broken. There is a patch [0] which partially fixes this from
nailgun side and I am working on library part of it. I believe that we need
1-2 days more to get this done.

Sorry for inconvenience.

[0] https://review.openstack.org/#/c/300637/


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] Should we maintain example plugins?

[Stanislaw Bogatkin]

+1 to maintain example plugins. It is easy enough and really lowering
barriers for people who just begin create plugins.

On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn 
wrote:

> Igor,
>
> It seems you are proposing an IKEA approach to plugins. Take Fuel's
> example plugin, add in the current Fuel release, and then build it. We
> maintained these plugins in the past, but now it should a manual step
> to test it out on the current release.
>
> What would be a more ideal situation that meets the needs of users and
> QA? Right now we have failed tests until we can decide on a solution
> that works for everybody.
>
> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky 
> wrote:
> > No, this is a wrong road to go.
> >
> > What if in Fuel 10 we drop v1 plugins support? What should we do?
> > Remove v1 example from source tree? That doesn't seem good to me.
> >
> > Example plugins are only examples. The list of supported releases must
> > be maintained on system test side, and system tests must inject that
> > information into plugin's metadata.yaml and test it.
> >
> > Again, I don't say we shouldn't test plugins. I say, tests should be
> > responsible for preparing plugins. I can say even more: tests should
> > not rely on what is produced by plugins, since it's something that
> > could be changed and tests start failing.
> >
> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset 
> wrote:
> >> IMHO it is important to keep plugin examples and keep testing them, very
> >> valuable for plugin developers.
> >>
> >> For example, I've encountered [0] the case where "plugin as role"
> feature
> >> wasn't easily testable with fuel-qa because not compliant with the last
> >> plugin data structure,
> >> and more recently we've spotted a regression [1] with "vip-reservation"
> >> feature introduced by a change in nailgun.
> >> These kind of issues are time consuming for plugin developers and
> can/must
> >> be avoided by testing them.
> >>
> >> I don't even understand why the question is raised while fuel plugins
> are
> >> supposed to be supported and more and more used [3], even by murano [4]
> ...
> >>
> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> [3]
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> [4] https://review.openstack.org/#/c/286310/
> >>
> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> >> wrote:
> >>>
> >>> Hi Fuelers,
> >>>
> >>> I would like to bring your attention a dilemma we have here. It seems
> >>> that there is a dispute as to whether we should maintain the releases
> >>> list for example plugins[0]. In this case, this is for adding version
> >>> 9.0 to the list.
> >>>
> >>> Right now, we run a swarm test that tries to install the example
> >>> plugin and do a deployment, but it's failing only for this reason. I
> >>> should add that this is the only automated daily test that will verify
> >>> that our plugin framework actually works. During the Mitaka
> >>> development  cycle, we already had an extended period where plugins
> >>> were broken[1]. Removing this test (or leaving it permanently red,
> >>> which is effectively the same), would raise the risk to any member of
> >>> the Fuel community who depends on plugins actually working.
> >>>
> >>> The other impact of abandoning maintenance of example plugins is that
> >>> it means that a given interested Fuel Plugin developer would not be
> >>> able to easily get started with plugin development. It might not be
> >>> inherently obvious to add the current Fuel release to the
> >>> metadata.yaml file and it would likely discourage such a user. In this
> >>> case, I would propose that we remove example plugins from fuel-plugins
> >>> GIT repo if they are not maintained. Non-functioning code is worse
> >>> than deleted code in my opinion.
> >>>
> >>> Please share your opinions and let's decide which way to go with this
> >>> bug[2]
> >>>
> >>> [0] https://github.com/openstack/fuel-plugins/tree/master/examples
> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> >>> [2] https://launchpad.net/bugs/1548340
> >>>
> >>> Best Regards,
> >>> Matthew Mosesohn
> >>>
> >>>
> __
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> 

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

[Stanislaw Bogatkin]

 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
>>>> <bgaiful...@mirantis.com> 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 <xar...@gmail.com> 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.
>>>> >> >

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

[Stanislaw Bogatkin]

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 
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
>
> So the idea [0] is to make releases fully configurable.
> Suggested changes for release definition (in metadata.yaml):
>   components_path: components_liberty.yaml
>   deployment_tasks_path: deployment_tasks_liberty/ # <- folder
>   environment_config_path: environment_config_liberty.yaml
>   network_roles_path: network_roles_liberty.yaml
>   node_roles_path: node_roles_liberty.yaml
>   volumes_path: volumes_liberty.yaml
>
> I see the issue: if we change anything for one release (e.g.
> deployment_task typo) revalidation is needed for all releases.
>
> Your Pros and cons please?
>
> [0] https://review.openstack.org/#/c/271417/
> ---
> WBR, Alexey Shtokolov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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] URL of Horizon is hard to find on the dashboard

[Stanislaw Bogatkin]

+1 to Vitaly. There can be many links, so just underline those we already
have is the best option.

On Tue, Feb 9, 2016 at 4:31 PM, Roman Prykhodchenko  wrote:

> Cannot we use display the same link we use in the title?
>
> 9 лют. 2016 р. о 14:14 Vitaly Kramskikh 
> написав(ла):
>
> Hi, Roman,
>
> I think the only solution here is to underline the title so it would look
> like a link. I don't think it's a good idea to show full URL because:
>
>- If SSL is enabled, there will be 2 links - HTTP and HTTPS.
>- Plugins can provide their own links for their dashboards, and they
>would be shown using exactly the same representation which is used for
>Horizon. These links could be quite long.
>
>
> 2016-02-09 20:04 GMT+07:00 Roman Prykhodchenko :
>
>> Whoops! I forgot to attach the link. Sorry!
>>
>> 1. http://i.imgur.com/8GaUtDq.png
>>
>> > 9 лют. 2016 р. о 13:48 Roman Prykhodchenko  написав(ла):
>> >
>> > Hi fuelers!
>> >
>> > I’m not sure, if it’s my personal problem or the UX can be improved a
>> little, but I’ve literary spend more than 5 minutes trying to figure out
>> how to find a URL of Horizon. I’ve made a screenshot [1] and I suggest to
>> add a full a link with the full URL in its test after "The OpenStack
>> dashboard Horizon is now available". That would make things much more
>> usable.
>> >
>> >
>> > - 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
>>
>>
>
>
> --
> 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
>
>


-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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][Bugs] Time sync problem when testing.

[Stanislaw Bogatkin]

Yes, I have created custom iso with debug output. It didn't help, so
another one with strace was created.
On Jan 27, 2016 00:56, "Alex Schultz" <aschu...@mirantis.com> wrote:

> On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
> <sbogat...@mirantis.com> wrote:
> > When there is too high strata, ntpdate can understand this and always
> write
> > this into its log. In our case there are just no log - ntpdate send first
> > packet, get an answer - that's all. So, fudging won't save us, as I
> think.
> > Also, it's a really bad approach to fudge a server which doesn't have a
> real
> > clock onboard.
>
> Do you have a debug output of the ntpdate somewhere? I'm not finding
> it in the bugs or in some of the snapshots for the failures. I did
> find one snapshot with the -v change that didn't have any response
> information so maybe it's the other problem where there is some
> network connectivity isn't working correctly or the responses are
> getting dropped somewhere?
>
> -Alex
>
> >
> > On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
> > wrote:
> >>
> >> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
> >> <sbogat...@mirantis.com> wrote:
> >> > Hi guys,
> >> >
> >> > for some time we have a bug [0] with ntpdate. It doesn't reproduced
> 100%
> >> > of
> >> > time, but breaks our BVT and swarm tests. There is no exact point
> where
> >> > problem root located. To better understand this, some verbosity to
> >> > ntpdate
> >> > output was added but in logs we can see only that packet exchange
> >> > between
> >> > ntpdate and server was started and was never completed.
> >> >
> >>
> >> So when I've hit this in my local environments there is usually one or
> >> two possible causes for this. 1) lack of network connectivity so ntp
> >> server never responds or 2) the stratum is too high.  My assumption is
> >> that we're running into #2 because of our revert-resume in testing.
> >> When we resume, the ntp server on the master may take a while to
> >> become stable. This sync in the deployment uses the fuel master for
> >> synchronization so if the stratum is too high, it will fail with this
> >> lovely useless error.  My assumption on what is happening is that
> >> because we aren't using a set of internal ntp servers but rather
> >> relying on the standard ntp.org pools.  So when the master is being
> >> resumed it's struggling to find a good enough set of servers so it
> >> takes a while to sync. This then causes these deployment tasks to fail
> >> because the master has not yet stabilized (might also be geolocation
> >> related).  We could either address this by fudging the stratum on the
> >> master server in the configs or possibly introducing our own more
> >> stable local ntp servers. I have a feeling fudging the stratum might
> >> be better when we only use the master in our ntp configuration.
> >>
> >> > As this bug is blocker, I propose to merge [1] to better understanding
> >> > what's going on. I created custom ISO with this patchset and tried to
> >> > run
> >> > about 10 BVT tests on this ISO. Absolutely with no luck. So, if we
> will
> >> > merge this, we would catch the problem much faster and understand root
> >> > cause.
> >> >
> >>
> >> I think we should merge the increased logging patch anyway because
> >> it'll be useful in troubleshooting but we also might want to look into
> >> getting an ntp peers list added into the snapshot.
> >>
> >> > I appreciate your answers, folks.
> >> >
> >> >
> >> > [0] https://bugs.launchpad.net/fuel/+bug/1533082
> >> > [1] https://review.openstack.org/#/c/271219/
> >> > --
> >> > with best regards,
> >> > Stan.
> >> >
> >>
> >> Thanks,
> >> -Alex
> >>
> >>
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > with best regards,
> > Stan.
> >
> >
> __
> > OpenStack Development Mailing 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][Bugs] Time sync problem when testing.

[Stanislaw Bogatkin]

I've got proposal from mos-linux team about switch to sntp instead of
ntpdate due to ntpdate deprecation. It looks nice enough for me but we
already had similar problems with sntp before switching to ntpdate.
Does anyone vote against switching to sntp?

On Wed, Jan 27, 2016 at 2:25 PM, Maksim Malchuk <mmalc...@mirantis.com>
wrote:

> I think we shouldn't depend on the other services like Syslog and logger
> trying to catch the problem and it is better to create the logs ourselves.
>
>
> On Wed, Jan 27, 2016 at 1:49 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> >But you've used 'logger -t ntpdate' - this is can fail again and logs
>> can be empty again.
>> What do you mean by 'fall again'? Piping to logger uses standard blocking
>> I/O - logger gets
>> all the output it can reach, so it get all output strace will produce. If
>> ntpdate will hang for some
>> reason - we should see it in strace output. If ntpdate will exit - we
>> will see this too.
>>
>> On Wed, Jan 27, 2016 at 12:57 PM, Maksim Malchuk <mmalc...@mirantis.com>
>> wrote:
>>
>>> But you've used 'logger -t ntpdate' - this is can fail again and logs
>>> can be empty again.
>>> My opinion we should use output redirection to the log-file directly.
>>>
>>>
>>> On Wed, Jan 27, 2016 at 11:21 AM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
>>>> Yes, I have created custom iso with debug output. It didn't help, so
>>>> another one with strace was created.
>>>> On Jan 27, 2016 00:56, "Alex Schultz" <aschu...@mirantis.com> wrote:
>>>>
>>>>> On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
>>>>> <sbogat...@mirantis.com> wrote:
>>>>> > When there is too high strata, ntpdate can understand this and
>>>>> always write
>>>>> > this into its log. In our case there are just no log - ntpdate send
>>>>> first
>>>>> > packet, get an answer - that's all. So, fudging won't save us, as I
>>>>> think.
>>>>> > Also, it's a really bad approach to fudge a server which doesn't
>>>>> have a real
>>>>> > clock onboard.
>>>>>
>>>>> Do you have a debug output of the ntpdate somewhere? I'm not finding
>>>>> it in the bugs or in some of the snapshots for the failures. I did
>>>>> find one snapshot with the -v change that didn't have any response
>>>>> information so maybe it's the other problem where there is some
>>>>> network connectivity isn't working correctly or the responses are
>>>>> getting dropped somewhere?
>>>>>
>>>>> -Alex
>>>>>
>>>>> >
>>>>> > On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <
>>>>> aschu...@mirantis.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
>>>>> >> <sbogat...@mirantis.com> wrote:
>>>>> >> > Hi guys,
>>>>> >> >
>>>>> >> > for some time we have a bug [0] with ntpdate. It doesn't
>>>>> reproduced 100%
>>>>> >> > of
>>>>> >> > time, but breaks our BVT and swarm tests. There is no exact point
>>>>> where
>>>>> >> > problem root located. To better understand this, some verbosity to
>>>>> >> > ntpdate
>>>>> >> > output was added but in logs we can see only that packet exchange
>>>>> >> > between
>>>>> >> > ntpdate and server was started and was never completed.
>>>>> >> >
>>>>> >>
>>>>> >> So when I've hit this in my local environments there is usually one
>>>>> or
>>>>> >> two possible causes for this. 1) lack of network connectivity so ntp
>>>>> >> server never responds or 2) the stratum is too high.  My assumption
>>>>> is
>>>>> >> that we're running into #2 because of our revert-resume in testing.
>>>>> >> When we resume, the ntp server on the master may take a while to
>>>>> >> become stable. This sync in the deployment uses the fuel master for
>>>>> >> synchronization so if the stratum is too high, it will fail with
>>>>> this
>>>>

Re: [openstack-dev] [Fuel][Bugs] Time sync problem when testing.

[Stanislaw Bogatkin]

>But you've used 'logger -t ntpdate' - this is can fail again and logs can
be empty again.
What do you mean by 'fall again'? Piping to logger uses standard blocking
I/O - logger gets
all the output it can reach, so it get all output strace will produce. If
ntpdate will hang for some
reason - we should see it in strace output. If ntpdate will exit - we will
see this too.

On Wed, Jan 27, 2016 at 12:57 PM, Maksim Malchuk <mmalc...@mirantis.com>
wrote:

> But you've used 'logger -t ntpdate' - this is can fail again and logs can
> be empty again.
> My opinion we should use output redirection to the log-file directly.
>
>
> On Wed, Jan 27, 2016 at 11:21 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Yes, I have created custom iso with debug output. It didn't help, so
>> another one with strace was created.
>> On Jan 27, 2016 00:56, "Alex Schultz" <aschu...@mirantis.com> wrote:
>>
>>> On Tue, Jan 26, 2016 at 2:16 PM, Stanislaw Bogatkin
>>> <sbogat...@mirantis.com> wrote:
>>> > When there is too high strata, ntpdate can understand this and always
>>> write
>>> > this into its log. In our case there are just no log - ntpdate send
>>> first
>>> > packet, get an answer - that's all. So, fudging won't save us, as I
>>> think.
>>> > Also, it's a really bad approach to fudge a server which doesn't have
>>> a real
>>> > clock onboard.
>>>
>>> Do you have a debug output of the ntpdate somewhere? I'm not finding
>>> it in the bugs or in some of the snapshots for the failures. I did
>>> find one snapshot with the -v change that didn't have any response
>>> information so maybe it's the other problem where there is some
>>> network connectivity isn't working correctly or the responses are
>>> getting dropped somewhere?
>>>
>>> -Alex
>>>
>>> >
>>> > On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
>>> > wrote:
>>> >>
>>> >> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
>>> >> <sbogat...@mirantis.com> wrote:
>>> >> > Hi guys,
>>> >> >
>>> >> > for some time we have a bug [0] with ntpdate. It doesn't reproduced
>>> 100%
>>> >> > of
>>> >> > time, but breaks our BVT and swarm tests. There is no exact point
>>> where
>>> >> > problem root located. To better understand this, some verbosity to
>>> >> > ntpdate
>>> >> > output was added but in logs we can see only that packet exchange
>>> >> > between
>>> >> > ntpdate and server was started and was never completed.
>>> >> >
>>> >>
>>> >> So when I've hit this in my local environments there is usually one or
>>> >> two possible causes for this. 1) lack of network connectivity so ntp
>>> >> server never responds or 2) the stratum is too high.  My assumption is
>>> >> that we're running into #2 because of our revert-resume in testing.
>>> >> When we resume, the ntp server on the master may take a while to
>>> >> become stable. This sync in the deployment uses the fuel master for
>>> >> synchronization so if the stratum is too high, it will fail with this
>>> >> lovely useless error.  My assumption on what is happening is that
>>> >> because we aren't using a set of internal ntp servers but rather
>>> >> relying on the standard ntp.org pools.  So when the master is being
>>> >> resumed it's struggling to find a good enough set of servers so it
>>> >> takes a while to sync. This then causes these deployment tasks to fail
>>> >> because the master has not yet stabilized (might also be geolocation
>>> >> related).  We could either address this by fudging the stratum on the
>>> >> master server in the configs or possibly introducing our own more
>>> >> stable local ntp servers. I have a feeling fudging the stratum might
>>> >> be better when we only use the master in our ntp configuration.
>>> >>
>>> >> > As this bug is blocker, I propose to merge [1] to better
>>> understanding
>>> >> > what's going on. I created custom ISO with this patchset and tried
>>> to
>>> >> > run
>>> >> > about 10 BVT tests on this ISO. Absolutely with no luck. So, if we
>>> will
>>>

[openstack-dev] [Fuel][Bugs] Time sync problem when testing.

[Stanislaw Bogatkin]

Hi guys,

for some time we have a bug [0] with ntpdate. It doesn't reproduced 100% of
time, but breaks our BVT and swarm tests. There is no exact point where
problem root located. To better understand this, some verbosity to ntpdate
output was added but in logs we can see only that packet exchange between
ntpdate and server was started and was never completed.

As this bug is blocker, I propose to merge [1] to better understanding
what's going on. I created custom ISO with this patchset and tried to run
about 10 BVT tests on this ISO. Absolutely with no luck. So, if we will
merge this, we would catch the problem much faster and understand root
cause.

I appreciate your answers, folks.


[0] https://bugs.launchpad.net/fuel/+bug/1533082
[1] https://review.openstack.org/#/c/271219/
-- 
with best regards,
Stan.
__
OpenStack Development Mailing 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][Bugs] Time sync problem when testing.

[Stanislaw Bogatkin]

When there is too high strata, ntpdate can understand this and always write
this into its log. In our case there are just no log - ntpdate send first
packet, get an answer - that's all. So, fudging won't save us, as I think.
Also, it's a really bad approach to fudge a server which doesn't have a
real clock onboard.

On Tue, Jan 26, 2016 at 10:41 PM, Alex Schultz <aschu...@mirantis.com>
wrote:

> On Tue, Jan 26, 2016 at 11:42 AM, Stanislaw Bogatkin
> <sbogat...@mirantis.com> wrote:
> > Hi guys,
> >
> > for some time we have a bug [0] with ntpdate. It doesn't reproduced 100%
> of
> > time, but breaks our BVT and swarm tests. There is no exact point where
> > problem root located. To better understand this, some verbosity to
> ntpdate
> > output was added but in logs we can see only that packet exchange between
> > ntpdate and server was started and was never completed.
> >
>
> So when I've hit this in my local environments there is usually one or
> two possible causes for this. 1) lack of network connectivity so ntp
> server never responds or 2) the stratum is too high.  My assumption is
> that we're running into #2 because of our revert-resume in testing.
> When we resume, the ntp server on the master may take a while to
> become stable. This sync in the deployment uses the fuel master for
> synchronization so if the stratum is too high, it will fail with this
> lovely useless error.  My assumption on what is happening is that
> because we aren't using a set of internal ntp servers but rather
> relying on the standard ntp.org pools.  So when the master is being
> resumed it's struggling to find a good enough set of servers so it
> takes a while to sync. This then causes these deployment tasks to fail
> because the master has not yet stabilized (might also be geolocation
> related).  We could either address this by fudging the stratum on the
> master server in the configs or possibly introducing our own more
> stable local ntp servers. I have a feeling fudging the stratum might
> be better when we only use the master in our ntp configuration.
>
> > As this bug is blocker, I propose to merge [1] to better understanding
> > what's going on. I created custom ISO with this patchset and tried to run
> > about 10 BVT tests on this ISO. Absolutely with no luck. So, if we will
> > merge this, we would catch the problem much faster and understand root
> > cause.
> >
>
> I think we should merge the increased logging patch anyway because
> it'll be useful in troubleshooting but we also might want to look into
> getting an ntp peers list added into the snapshot.
>
> > I appreciate your answers, folks.
> >
> >
> > [0] https://bugs.launchpad.net/fuel/+bug/1533082
> > [1] https://review.openstack.org/#/c/271219/
> > --
> > with best regards,
> > Stan.
> >
>
> Thanks,
> -Alex
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [fuel][plugins]Security problem in Fuel 7.0

[Stanislaw Bogatkin]

+1 to Andrew. Plugins created for run some code and plugin verification is
the source of trust there.

On Mon, Dec 7, 2015 at 8:19 PM, Andrew Woodward  wrote:

> I'd have to say that this is expected behavior. I'm not sure what you
> would hope to prohibit when these kinds of things are necessary for the
> deployment. We also can't prohibit this from being done in a plugin, this
> is what the plugin verification is supposed to help combat. If you just go
> download a random puppet manifest // script // etc... from the internet,
> how do you ensure that it didn't install a root-kit.
>
> On Mon, Dec 7, 2015 at 9:14 AM Eugene Korekin 
> wrote:
>
>> As far as I know this feature is planned for the next releases.
>>
>> But I think the main problem is: it's not obvious that just by installing
>> a plugin, even without enabling the plugin in Fuel user could break or
>> somehow alter already existing environments.  It could be done by malicious
>> attacker who could compromise plugin or just unintentionally with some bug
>> in the plugin code.
>>
>> Unfortunately, by installing some plugin a user jeopardizes his existing
>> environments. And I think we should at least document these risks.
>>
>>
>> On 07.12.2015 19:52, Javeria Khan wrote:
>>
>> My two cents. It would be useful to have a role that could execute on the
>> Fuel Master host itself rather than a container.
>>
>> --
>> Javeria
>> On Dec 7, 2015 9:49 PM, "Roman Prykhodchenko"  wrote:
>>
>>> Alexey,
>>>
>>> thank you for bringing this up. IMO discussing security problems is
>>> better to be done in a special kind of Launchpad bugs.
>>>
>>> - romcheg
>>>
>>>
>>> > 7 груд. 2015 р. о 17:36 Alexey Elagin < 
>>> aela...@mirantis.com> написав(ла):
>>> >
>>> > Hello all,
>>> >
>>> > We have a security problem in Fuel 7.0. It's related to plugin
>>> > development and allows to execute code in mcollective docker container
>>> > on Fuel master node. Any fuel plugin may contains a yaml file with
>>> > deployment tasks (tasks.yaml, deployment_tasks.yaml etc) and there is
>>> > an ability to run some code on node with role "master". It's also
>>> > possible to connect to any target node via ssh without a password from
>>> > within the container.
>>> >
>>> > As i understood, it was made to simplify some deployment cases. I see
>>> > some steps for resolving this situation:
>>> > 1. Fuel team should disallow
>>> > execution of any puppet manifests or bash code on nodes with master
>>> > role.
>>> > 2. Append the Fuel documentation. Notify users about this
>>> > security issue.
>>> >
>>> > What do you think about it? What deployment cases which require
>>> > execution of code on role "master" do you know?
>>> >
>>> > --
>>> > Best regards,
>>> > Alexey
>>> > Deployment Engineer
>>> > Mirantis, Inc
>>> > Cell: +7 (968) 880 2288
>>> > Skype: shikelbober
>>> > Slack: aelagin
>>> > mailto:aela...@mirantis.com
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> --
>> Eugene Korekin
>> Partner Enablement Team Deployment Engineer
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Hi Dmitry,

thank you for an update.
I personally think that 2 and 3 must be done in one blueprint as it related
to master node only and 2 shouldn't be a rocket science. What you mean
by "Non-root
accounts on slave nodes"? If we speak about disabling root for ssh,
creating new user and adding needed commands for him in sudoers - I believe
that it can be done in that blueprint too. If it is something much bigger -
it worth to be in separate blueprint.

On Fri, Dec 4, 2015 at 8:24 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> Folks, there is another spec update, please take a look:
> https://review.openstack.org/#/c/243340
>
> I'm also considering splitting the blueprint/spec into smaller pieces:
>
> 1. Non-root accounts on slave nodes.
> 2. Non-root user account (fueladmin) on master node.
> 3. Running fuel services as non-superuser.
> 4. Running mcollective as non-root (tentative, still need a POC).
>
> Let me know what you think.
>
> On Tue, Nov 24, 2015 at 12:22 PM, Dmitry Nikishov <dnikis...@mirantis.com>
> wrote:
>
>> Folks, I have updated a spec, please review:
>> https://review.openstack.org/#/c/243340
>>
>> On Fri, Nov 20, 2015 at 4:50 PM, Dmitry Nikishov <dnikis...@mirantis.com>
>> wrote:
>>
>>> Stanislaw,
>>>
>>> proposing patches could be a viable option long-term, however, by the
>>> time these patches will make it upstream, Fuel will use CentOS 7 w/ systemd.
>>>
>>> On Fri, Nov 20, 2015 at 4:05 PM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
>>>> Dmitry, as we work on opensource - it would be really nice to propose
>>>> patches to upstream for non-Fuel services. But if it is not an option -
>>>> using puppet make sense to me.
>>>>
>>>> On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <
>>>> dnikis...@mirantis.com> wrote:
>>>>
>>>>> Stanislaw,
>>>>>
>>>>> I want to clarify: there are 2 types of services, run on the Fuel node:
>>>>> - Those, which are a part of Fuel (astute, nailgun etc)
>>>>> - Those, which are not (e.g. atop)
>>>>>
>>>>> Capabilities for the former can easily be managed via post-install
>>>>> scripts, embedded in respective package spec file (since specs are a part
>>>>> of fuel-* repo). This is a very good idea.
>>>>> Capabilities for the latter will have to be taken care of via either
>>>>> a. some external utility (puppet)
>>>>> b. rebuilding respective package with updated spec
>>>>>
>>>>> I'd say that (a) is still more convinient.
>>>>>
>>>>> Another option would be to have a fine-grained control only on Fuel
>>>>> services and leave all the other at their defaults.
>>>>>
>>>>> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
>>>>> sbogat...@mirantis.com> wrote:
>>>>>
>>>>>> Dmitry, I just propose the way I think is right, because it's strange
>>>>>> enough - install package from *.deb file and then set any privileges to 
>>>>>> it
>>>>>> by third-party utility. Set permissions for app now mostly managed by
>>>>>> post-install scripts. Moreover - if it isn't - it should, cause if you 
>>>>>> set
>>>>>> capabilities by puppet there always will be a gap between installation 
>>>>>> and
>>>>>> setting permissions, so you will must bound package installation process
>>>>>> with setting permissions by puppet - other way you will have no way to 
>>>>>> use
>>>>>> your app.
>>>>>>
>>>>>> Setting setuid bits on apps is not a good idea - it is why linux
>>>>>> capabilities were introduced.
>>>>>>
>>>>>> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <
>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>
>>>>>>> Stanislaw,
>>>>>>>
>>>>>>> In my opinion the whole feature shouldn't be in the separate package
>>>>>>> simply because it will actually affect the code of many, if not all,
>>>>>>> components of Fuel.
>>>>>>>
>>>>>>> The only services whose capabilities will have to be managed by
>>>>>>> puppet are those, which are installed from upstream packages (e.g. 
&

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

[Stanislaw Bogatkin]

> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)

I believe you should ask other people if you are right, as set '-1' to code
that you
cannot improve is not the best option, so


> If you are not sure how the improved code would look like, just let it go!
is right


Also I think that set some strict boundaries, like 400 LOC per patch is
wrong. For example, if you
introduce new test fixture for fuel-library, it usually about 800+ LOC and
you can't split it
out, so we should either move such fixtures out of code or make an exeption
for such type of code.

On Mon, Dec 7, 2015 at 1:03 PM, Igor Kalnitsky 
wrote:

> Hey Andrii,
>
> I'm totally agree with you about contribution guides, except one thing
> - we need and should force users to split huge patches into set of
> small ones. Mostly because it will simplify support and review of
> patches. Previously we ignored this rule pretty often, and get a lot
> of troubles due to buggy code.
>
> Also, see some comments below.
>
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch.
>
> No one is suggesting to set -1 without leaving a comment how the patch
> could be divided.
>
>
> > If you are not sure how the improved code would look like, just let it
> go!
>
> What if you're not sure how the improved code should look like, but
> you definitely sure that it shouldn't look like proposed one? :)
>
> I'd say it's a good reason to set -1 and start discussion. Not only
> with author, but with other folks, since everyone in community is
> responsible of code quality of the project.
>
> - I
>
> On Mon, Dec 7, 2015 at 3:28 AM, Andrey Tykhonov 
> wrote:
> > I believe this is against the code review guidelines.
> >
> > «Comments must be meaningful and should help an author to change the
> > code the right way.» [1]
> >
> > If you get a comment that says «split this change into the smaller
> > commit» I'm sorry, but it doesn't help at all.
> >
> > «Leave constructive comments
> >
> > Not everyone in the community is a native English speaker, so make
> > sure your remarks are meaningful and helpful for the patch author to
> > change his code, but also polite and respectful.
> >
> > The review is not really about the score. It's all about the
> > comments. When you are reviewing code, always make sure that your
> > comments are useful and helpful to the author of the patch. Try to
> > avoid leaving comments just to show that you reviewed something if
> > they don't really add anything meaningful» [2]
> >
> > So, when an author of a patch gets -1 with the statement «split this
> > code», I believe it is not constructive. At least you should roughly
> > describe how you see it, how the patch could be split, you should be
> > helpful to the author of a patch. So, first of all, you need to review
> > the patch! :)
> >
> > I want to emphasize this: «The review is not really about the
> > score. It's all about the comments.»
> >
> > «In almost all cases, a negative review should be accompanied by clear
> > instructions for the submitter how they might fix the patch.» [4]
> >
> > I believe that the statement "split this change into the smaller
> > commit" is too generic, it is mostly the same as the "this patch needs
> > further work". It doesn't bring any additional instructions how
> > exactly a patch could be fixed.
> >
> > Please also take a loot at the following conversation from mailing
> > list: [3].
> >
> > «It's not so easy to guess what you mean, and in case of a clumsy
> > piece of code, not even that certain that better code can be used
> > instead. So always provide an example of what you would rather want to
> > see. So instead of pointing to indentation rules, just show properly
> > indented code. Instead of talking about grammar or spelling, just type
> > the corrected comment or docstring. Finally, instead of saying "use
> > list comprehension here" or "don't use has_key", just type your
> > proposal of how the code should look like. Then we have something
> > concrete to talk about. Of course, you can also say why you think this
> > is better, but an example is very important. If you are not sure how
> > the improved code would look like, just let it go, chances are it
> > would look even worse.» [3]
> >
> > So, please, bring something concrete to talk about. If you are not
> > sure how the improved code would look like, just let it go!
> >
> > «The simplest way to talk about code is to just show the code. When you
> > want the author to fix something, rewrite it in a different way,
> > format the code differently, etc. -- it's best to just write in the
> > comment how you want that code to look like. It's much faster than
> > having 

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

[Stanislaw Bogatkin]

Igor,

it is much more clear for me now. Thank you :)

On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov <ibeli...@mirantis.com> wrote:

> Hi Stanislaw,
>
> The reason behind this is simple - deployment tests are heavy. Each
> deployment test occupies whole server for ~2 hours, for each commit we have
> 2 deployment tests (for current fuel-library master) and that’s just
> because we don’t test CentOS deployment for now.
> If we assume that developers will rertrigger deployment tests only when
> retrigger would actually solve the failure - it’s still not smart in terms
> of HW usage to retrigger both tests when only one has failed, for example.
> And there are cases when retrigger just won’t do it and CI Engineer must
> manually erase the existing environment on slave or fix it by other means,
> so it’s better when CI Engineer looks through logs before each retrigger of
> deployment test.
>
> Hope this answers your question.
>
> --
> Igor Belikov
> Fuel CI Engineer
> ibeli...@mirantis.com
>
> On 20 Nov 2015, at 13:57, Stanislaw Bogatkin <sbogat...@mirantis.com>
> wrote:
>
> Hi Igor,
>
> would you be so kind tell, why fuel-library deployment tests doesn't
> support this? Maybe there is a link with previous talks about it?
>
> On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov <ibeli...@mirantis.com>
> wrote:
>
>> Hi,
>>
>> I’d like to inform you that all jobs running on Fuel CI (with the
>> exception of fuel-library deployment tests) now support retriggering via
>> “recheck” or “reverify” comments in Gerrit.
>> Exact regex is the same one used in Openstack-Infra’s zuul and can be
>> found here
>> https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3
>>
>> CI-Team kindly asks you to not abuse this option, unfortunately not every
>> failure could be solved by retriggering.
>> And, to stress this out once again: fuel-library deployment tests don’t
>> support this, so you still have to ask for a retrigger in #fuel-infra irc
>> channel.
>>
>> Thanks for attention.
>> --
>> Igor Belikov
>> Fuel CI Engineer
>> ibeli...@mirantis.com
>>
>>
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs

[Stanislaw Bogatkin]

Hi Igor,

would you be so kind tell, why fuel-library deployment tests doesn't
support this? Maybe there is a link with previous talks about it?

On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov  wrote:

> Hi,
>
> I’d like to inform you that all jobs running on Fuel CI (with the
> exception of fuel-library deployment tests) now support retriggering via
> “recheck” or “reverify” comments in Gerrit.
> Exact regex is the same one used in Openstack-Infra’s zuul and can be
> found here
> https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3
>
> CI-Team kindly asks you to not abuse this option, unfortunately not every
> failure could be solved by retriggering.
> And, to stress this out once again: fuel-library deployment tests don’t
> support this, so you still have to ask for a retrigger in #fuel-infra irc
> channel.
>
> Thanks for attention.
> --
> Igor Belikov
> Fuel CI Engineer
> ibeli...@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] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, I just propose the way I think is right, because it's strange
enough - install package from *.deb file and then set any privileges to it
by third-party utility. Set permissions for app now mostly managed by
post-install scripts. Moreover - if it isn't - it should, cause if you set
capabilities by puppet there always will be a gap between installation and
setting permissions, so you will must bound package installation process
with setting permissions by puppet - other way you will have no way to use
your app.

Setting setuid bits on apps is not a good idea - it is why linux
capabilities were introduced.

On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> Stanislaw,
>
> In my opinion the whole feature shouldn't be in the separate package
> simply because it will actually affect the code of many, if not all,
> components of Fuel.
>
> The only services whose capabilities will have to be managed by puppet are
> those, which are installed from upstream packages (e.g. atop) -- not built
> from fuel-* repos.
>
> Supervisord doesn't seem to use Linux capabilities, id does setuid
> instead:
> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>
> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I mean whole feature.
>> Btw, why do you want to grant capabilities via puppet? It should be done
>> by post-install package section, I believe.
>>
>> Also I doesn't know if supervisord can bound process capabilities like
>> systemd can - we could use this opportunity too.
>>
>> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <dnikis...@mirantis.com>
>> wrote:
>>
>>> My main concern with using linux capabilities/acls on files is actually
>>> puppet support or, actually, the lack of it. ACLs are possible AFAIK, but
>>> we'd need to write a custom type/provider for capabilities. I suggest to
>>> wait with capabilities support till systemd support.
>>>
>>> On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <dnikis...@mirantis.com
>>> > wrote:
>>>
>>>> Stanislaw, do you mean the whole feature, or just a user? Since feature
>>>> would require actually changing puppet code.
>>>>
>>>> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <
>>>> sbogat...@mirantis.com> wrote:
>>>>
>>>>> Dmitry, I believe it should be done via package spec as a part of
>>>>> installation.
>>>>>
>>>>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <
>>>>> dnikis...@mirantis.com> wrote:
>>>>>
>>>>>> Hello folks,
>>>>>>
>>>>>> I have updated the spec, please review and share your thoughts on it:
>>>>>> https://review.openstack.org/#/c/243340/
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <
>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>
>>>>>>> Matthew,
>>>>>>>
>>>>>>> sorry, didn't mean to butcher your name :(
>>>>>>>
>>>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>>
>>>>>>>> Matther,
>>>>>>>>
>>>>>>>> I totally agree that each daemon should have it's own user which
>>>>>>>> should be created during installation of the relevant package. 
>>>>>>>> Probably I
>>>>>>>> didn't state this clear enough in the spec.
>>>>>>>>
>>>>>>>> However, there are security requirements in place that root should
>>>>>>>> not be used at all. This means that there should be a some kind of
>>>>>>>> maintenance or system user ('fueladmin'), which would have enough
>>>>>>>> privileges to configure and manage Fuel node (e.g. run "sudo puppet 
>>>>>>>> apply"
>>>>>>>> without password, create mirrors etc). This also means that certain 
>>>>>>>> fuel-
>>>>>>>> packages would be required to have their files accessible to that user.
>>>>>>>> That's the idea behind having a package which would create 'fueladmin' 
>>>>>>>> user
>>>>>>&

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, as we work on opensource - it would be really nice to propose
patches to upstream for non-Fuel services. But if it is not an option -
using puppet make sense to me.

On Fri, Nov 20, 2015 at 11:01 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> Stanislaw,
>
> I want to clarify: there are 2 types of services, run on the Fuel node:
> - Those, which are a part of Fuel (astute, nailgun etc)
> - Those, which are not (e.g. atop)
>
> Capabilities for the former can easily be managed via post-install
> scripts, embedded in respective package spec file (since specs are a part
> of fuel-* repo). This is a very good idea.
> Capabilities for the latter will have to be taken care of via either
> a. some external utility (puppet)
> b. rebuilding respective package with updated spec
>
> I'd say that (a) is still more convinient.
>
> Another option would be to have a fine-grained control only on Fuel
> services and leave all the other at their defaults.
>
> On Fri, Nov 20, 2015 at 1:19 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> Dmitry, I just propose the way I think is right, because it's strange
>> enough - install package from *.deb file and then set any privileges to it
>> by third-party utility. Set permissions for app now mostly managed by
>> post-install scripts. Moreover - if it isn't - it should, cause if you set
>> capabilities by puppet there always will be a gap between installation and
>> setting permissions, so you will must bound package installation process
>> with setting permissions by puppet - other way you will have no way to use
>> your app.
>>
>> Setting setuid bits on apps is not a good idea - it is why linux
>> capabilities were introduced.
>>
>> On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <dnikis...@mirantis.com>
>> wrote:
>>
>>> Stanislaw,
>>>
>>> In my opinion the whole feature shouldn't be in the separate package
>>> simply because it will actually affect the code of many, if not all,
>>> components of Fuel.
>>>
>>> The only services whose capabilities will have to be managed by puppet
>>> are those, which are installed from upstream packages (e.g. atop) -- not
>>> built from fuel-* repos.
>>>
>>> Supervisord doesn't seem to use Linux capabilities, id does setuid
>>> instead:
>>> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>>>
>>> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
>>> sbogat...@mirantis.com> wrote:
>>>
>>>> Dmitry, I mean whole feature.
>>>> Btw, why do you want to grant capabilities via puppet? It should be
>>>> done by post-install package section, I believe.
>>>>
>>>> Also I doesn't know if supervisord can bound process capabilities like
>>>> systemd can - we could use this opportunity too.
>>>>
>>>> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <
>>>> dnikis...@mirantis.com> wrote:
>>>>
>>>>> My main concern with using linux capabilities/acls on files is
>>>>> actually puppet support or, actually, the lack of it. ACLs are possible
>>>>> AFAIK, but we'd need to write a custom type/provider for capabilities. I
>>>>> suggest to wait with capabilities support till systemd support.
>>>>>
>>>>> On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <
>>>>> dnikis...@mirantis.com> wrote:
>>>>>
>>>>>> Stanislaw, do you mean the whole feature, or just a user? Since
>>>>>> feature would require actually changing puppet code.
>>>>>>
>>>>>> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <
>>>>>> sbogat...@mirantis.com> wrote:
>>>>>>
>>>>>>> Dmitry, I believe it should be done via package spec as a part of
>>>>>>> installation.
>>>>>>>
>>>>>>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <
>>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>>
>>>>>>>> Hello folks,
>>>>>>>>
>>>>>>>> I have updated the spec, please review and share your thoughts on
>>>>>>>> it: https://review.openstack.org/#/c/243340/
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <
>>&

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, I mean whole feature.
Btw, why do you want to grant capabilities via puppet? It should be done by
post-install package section, I believe.

Also I doesn't know if supervisord can bound process capabilities like
systemd can - we could use this opportunity too.

On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> My main concern with using linux capabilities/acls on files is actually
> puppet support or, actually, the lack of it. ACLs are possible AFAIK, but
> we'd need to write a custom type/provider for capabilities. I suggest to
> wait with capabilities support till systemd support.
>
> On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <dnikis...@mirantis.com>
> wrote:
>
>> Stanislaw, do you mean the whole feature, or just a user? Since feature
>> would require actually changing puppet code.
>>
>> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Dmitry, I believe it should be done via package spec as a part of
>>> installation.
>>>
>>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <dnikis...@mirantis.com
>>> > wrote:
>>>
>>>> Hello folks,
>>>>
>>>> I have updated the spec, please review and share your thoughts on it:
>>>> https://review.openstack.org/#/c/243340/
>>>>
>>>> Thanks.
>>>>
>>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <
>>>> dnikis...@mirantis.com> wrote:
>>>>
>>>>> Matthew,
>>>>>
>>>>> sorry, didn't mean to butcher your name :(
>>>>>
>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>>>> dnikis...@mirantis.com> wrote:
>>>>>
>>>>>> Matther,
>>>>>>
>>>>>> I totally agree that each daemon should have it's own user which
>>>>>> should be created during installation of the relevant package. Probably I
>>>>>> didn't state this clear enough in the spec.
>>>>>>
>>>>>> However, there are security requirements in place that root should
>>>>>> not be used at all. This means that there should be a some kind of
>>>>>> maintenance or system user ('fueladmin'), which would have enough
>>>>>> privileges to configure and manage Fuel node (e.g. run "sudo puppet 
>>>>>> apply"
>>>>>> without password, create mirrors etc). This also means that certain fuel-
>>>>>> packages would be required to have their files accessible to that user.
>>>>>> That's the idea behind having a package which would create 'fueladmin' 
>>>>>> user
>>>>>> and including it into other fuel- packages requirements lists.
>>>>>>
>>>>>> So this part of the feature comes down to having a non-root user with
>>>>>> sudo privileges and passwordless sudo for certain commands (like 'puppet
>>>>>> apply ') for scripting.
>>>>>>
>>>>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <
>>>>>> mmoses...@mirantis.com> wrote:
>>>>>>
>>>>>>> Dmitry,
>>>>>>>
>>>>>>> We really shouldn't put "user" creation into a single package and
>>>>>>> then depend on it for daemons. If we want nailgun service to run as 
>>>>>>> nailgun
>>>>>>> user, it should be created in the fuel-nailgun package.
>>>>>>> I think it makes the most sense to create multiple users, one for
>>>>>>> each service.
>>>>>>>
>>>>>>> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
>>>>>>> python-fuelclient package.
>>>>>>>
>>>>>>> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <
>>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>>
>>>>>>>> Stanislaw,
>>>>>>>>
>>>>>>>> I agree that this approch would work well. However, does Puppet
>>>>>>>> allow managing capabilities and/or file ACLs? Or can they be easily 
>>>>>>>> set up
>>>>>>>> when installing RPM package? (is there a way to specify 
>>>>>>>> capabilities/ACLs
>>>>>>>> in the RPM spec f

Re: [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

[Stanislaw Bogatkin]

+1 to remove containers

On Fri, Nov 20, 2015 at 12:29 AM, Thomas Goirand  wrote:

> On 11/19/2015 03:59 PM, Vladimir Kozhukalov wrote:
> > Anyway, the idea is to get
> > rid of Docker containers on the master node and switch to plane package
> > based approach that we used before.
>
> +1
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, I believe it should be done via package spec as a part of
installation.

On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> Hello folks,
>
> I have updated the spec, please review and share your thoughts on it:
> https://review.openstack.org/#/c/243340/
>
> Thanks.
>
> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <dnikis...@mirantis.com>
> wrote:
>
>> Matthew,
>>
>> sorry, didn't mean to butcher your name :(
>>
>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <dnikis...@mirantis.com
>> > wrote:
>>
>>> Matther,
>>>
>>> I totally agree that each daemon should have it's own user which should
>>> be created during installation of the relevant package. Probably I didn't
>>> state this clear enough in the spec.
>>>
>>> However, there are security requirements in place that root should not
>>> be used at all. This means that there should be a some kind of maintenance
>>> or system user ('fueladmin'), which would have enough privileges to
>>> configure and manage Fuel node (e.g. run "sudo puppet apply" without
>>> password, create mirrors etc). This also means that certain fuel- packages
>>> would be required to have their files accessible to that user. That's the
>>> idea behind having a package which would create 'fueladmin' user and
>>> including it into other fuel- packages requirements lists.
>>>
>>> So this part of the feature comes down to having a non-root user with
>>> sudo privileges and passwordless sudo for certain commands (like 'puppet
>>> apply ') for scripting.
>>>
>>> On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <
>>> mmoses...@mirantis.com> wrote:
>>>
>>>> Dmitry,
>>>>
>>>> We really shouldn't put "user" creation into a single package and then
>>>> depend on it for daemons. If we want nailgun service to run as nailgun
>>>> user, it should be created in the fuel-nailgun package.
>>>> I think it makes the most sense to create multiple users, one for each
>>>> service.
>>>>
>>>> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
>>>> python-fuelclient package.
>>>>
>>>> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <
>>>> dnikis...@mirantis.com> wrote:
>>>>
>>>>> Stanislaw,
>>>>>
>>>>> I agree that this approch would work well. However, does Puppet allow
>>>>> managing capabilities and/or file ACLs? Or can they be easily set up when
>>>>> installing RPM package? (is there a way to specify capabilities/ACLs in 
>>>>> the
>>>>> RPM spec file?) This doesn't seem to be supported out of the box.
>>>>>
>>>>> I'm going to research if it is possible to manage capabilities and
>>>>>  ACLs with what we have out of the box (RPM, Puppet).
>>>>>
>>>>> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
>>>>> sbogat...@mirantis.com> wrote:
>>>>>
>>>>>> Dmitry, I propose to give needed linux capabilities
>>>>>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
>>>>>> then start these processes from non-privileged user. It will give you
>>>>>> ability to run each process without 'sudo' at all with well fine-grained
>>>>>> permissions.
>>>>>>
>>>>>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>
>>>>>>> Stanislaw,
>>>>>>>
>>>>>>> I've been experimenting with 'capsh' on the 6.1 master node and it
>>>>>>> doesn't seem to preserve any capabilities when setting SECURE_NOROOT 
>>>>>>> bit,
>>>>>>> even if explicitely told to do so (via either --keep=1 or
>>>>>>> "SECURE_KEEP_CAPS" bit).
>>>>>>>
>>>>>>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
>>>>>>> dnikis...@mirantis.com> wrote:
>>>>>>>
>>>>>>>> Bartolomiej, Adam,
>>>>>>>> Stanislaw is correct. And this is going to be ported to master. The
>>>>>>>> goal currently is to reach an agreement on the implementation so that
>>>&

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Dmitry, I propose to give needed linux capabilities
(like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
then start these processes from non-privileged user. It will give you
ability to run each process without 'sudo' at all with well fine-grained
permissions.

On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <dnikis...@mirantis.com>
wrote:

> Stanislaw,
>
> I've been experimenting with 'capsh' on the 6.1 master node and it doesn't
> seem to preserve any capabilities when setting SECURE_NOROOT bit, even if
> explicitely told to do so (via either --keep=1 or "SECURE_KEEP_CAPS" bit).
>
> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <dnikis...@mirantis.com>
> wrote:
>
>> Bartolomiej, Adam,
>> Stanislaw is correct. And this is going to be ported to master. The goal
>> currently is to reach an agreement on the implementation so that there's
>> going to be a some kinf of compatibility during upgrades.
>>
>> Stanislaw,
>> Do I understand correctly that you propose using something like sucap to
>> launch from root, switch to a different user and then drop capabilities
>> which are not required?
>>
>> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> Bartolomiej, it's customer-related patches, they, I think, have to be
>>> done for 6.1 prior to 8+ release.
>>>
>>> Dmitry, it's nice to hear about it. Did you consider to use linux
>>> capabilities on fuel-related processes instead of just using non-extended
>>> POSIX privileged/non-privileged permission checks?
>>>
>>> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
>>> bpiotrow...@mirantis.com> wrote:
>>>
>>>> We don't develop features for already released versions… It should be
>>>> done for master instead.
>>>>
>>>> BP
>>>>
>>>> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <ahec...@mirantis.com>
>>>> wrote:
>>>>
>>>>> Dmitry,
>>>>> +1
>>>>>
>>>>> Do you plan to port your patchset to future Fuel releases?
>>>>>
>>>>> A.
>>>>>
>>>>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <
>>>>> dnikis...@mirantis.com> wrote:
>>>>>
>>>>>> Hey guys.
>>>>>>
>>>>>> I've been working on making Fuel not to rely on superuser privileges
>>>>>> at least for day-to-day operations. These include:
>>>>>> a) running Fuel services (nailgun, astute etc)
>>>>>> b) user operations (create env, deploy, update, log in)
>>>>>>
>>>>>> The reason for this is that many security policies simply do not
>>>>>> allow root access (especially remote) to servers/environments.
>>>>>>
>>>>>> This feature/enhancement means that anything that currently is being
>>>>>> run under root, will be evaluated and, if possible, put under a
>>>>>> non-privileged
>>>>>> user. This also means that remote root access will be disabled.
>>>>>> Instead, users will have to log in with "fueladmin" user.
>>>>>>
>>>>>> Together with Omar  we've put together a blueprint[0] and
>>>>>> a
>>>>>> spec[1] for this feature. I've been developing this for Fuel 6.1, so
>>>>>> there
>>>>>> are two patches into fuel-main[2] and fuel-library[3] that can give
>>>>>> you an
>>>>>> impression of current approach.
>>>>>>
>>>>>> These patches do following:
>>>>>> - Add fuel-admin-user package, which creates 'fueladmin'
>>>>>> - Make all other fuel-* packages depend on fuel-admin-user
>>>>>> - Put supervisord under 'fueladmin' user.
>>>>>>
>>>>>> Please review the spec/patches and let's have a discussion on the
>>>>>> approach to
>>>>>> this feature.
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>> [0] https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser
>>>>>> [1] https://review.openstack.org/243340
>>>>>> [2] https://review.openstack.org/243337
>>>>>> [3] https://review.openstack.org/243313
>>>>>>
>>>>>> --
>>>>>> Dmitry Niki

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Stanislaw Bogatkin]

I think that it is excellent thought.
+1

On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
wrote:

> Folks
>
> I wanted to raise awareness about one of the things I captured while doing
> reviews recently - we are sacrificing quality to bugfixing and feature
> development velocity, essentially moving from one heap to another - from
> bugs/features to 'tech-debt' bugs.
>
> I understand that we all have deadlines and need to meet them. But, folks,
> let's create the following policy:
>
> 1) do not introduce hacks/workarounds/kludges if it is possible.
> 2) while fixing things if you have a hack/workaround/kludge that you need
> to work with - think of removing it instead of enhancing and extending it.
> If it is possible - fix it. Do not let our technical debt grow.
> 3) if there is no way to avoid kludge addition/enhancing, if there is no
> way to remove it - please, add a 'TODO/FIXME' line above it, so that we can
> collect them in the future and fix them gradually.
>
> I suggest to add this requirement into code-review policy.
>
> What do you think about this?
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> 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] Using upstream packages & modules

[Stanislaw Bogatkin]

Hi Simon,

using 'include' in HAProxy is damn conveniently, I don't think it should
die. There is just one way I know to use haproxy with several different
conf's - to construct looong command line with all of them - and
it's really inconvenient.

On Tue, Nov 10, 2015 at 12:20 PM, Simon Pasquier 
wrote:

> Hello Alex!
>
> On Mon, Nov 9, 2015 at 9:29 PM, Alex Schultz 
> wrote:
>
>> Hey folks,
>>
>> I'm testing[0] out flipping our current method of consuming upstream
>> puppet modules from using pinned versions hosted on fuel-infra to be
>> able to use the ones directly from upstream (master).  This work is
>> primarily to be closer aligned with the other OpenStack projects as
>> well as switching the current way we manage Fuel into a downstream of
>> the upstream community version. As part of this work we have also been
>> working towards improving the upstream modules support different
>> package sets.  Specifically running Debian packages on Ubuntu[1][2].
>> This work is the start of being able to allow a user of Fuel to be
>> able to specify a specific package set and having it be able to work.
>> If we can properly split out the puppet modules and package
>> dependencies this will make Fuel a more flexible deployment engine as
>> I believe we would be better positioned to support multiple versions
>> of OpenStack for a given Fuel release.
>>
>> I'm currently working to get a PoC of Fuel consuming upstream puppet
>> modules and the UCA packages together and documenting all of the
>> issues so that we can address them.  So far I have been able to deploy
>> the upstream modules via a custom ISO using the MOS package set and it
>> works locally. Unfortunately the CI seems to be hitting some issues
>> that I think might be related to recently merged keystone changes but
>> I did not run into the same problem when running a manual deployment.
>> As I work through this PoC, I'm also attempting to develop a small
>> plugin that could be used to capture the work arounds to the
>> deployment process. I've run into a few issues so far as I work to
>> switch out the package sets.
>>
>> For the sake of providing additional visibility into this work, here
>> are the issues that I've hit so far.
>>
>> The first issue I ran across is that currently the MOS repositories
>> contain packages for both OpenStack and other system dependencies for
>> creating our HA implementation.  This is problematic when we want to
>> switch out the OpenStack packages but still want the MOS packages for
>> our HA items.  I'm working around this by adding the UCA repository as
>> a higher priorities for deployments.  As such I've run into an issue
>> with the haproxy package that MOS provides vs the upstream Ubuntu
>> package.  To get around this, I've pinned the MOS version for now
>> until I can circle back around and figure out if the difference is a
>> config or functionality issue.
>>
>
> I know at least for one difference between the MOS and Ubuntu versions:
> HAProxy from MOS has a patch to support the "include" configuration
> parameter.
> This is unrelated to your mail but I think this fork should die since it
> will never be accepted upstream and there are other ways to address the use
> case [0].
>
> HTH,
> Simon
>
> [0] http://marc.info/?l=haproxy=130817444025140=2
>
>
>>
>> The second issue that I have run across is that we are appending
>> read_timeout=60 to our mysql connection strings for our
>> configurations. This seems to be unsupported by the libraries and
>> OpenStack components provided by the UCA package set.  I'm not sure
>> how the priority of python-pymsql vs python-mysqldb is resolved as I
>> had both packages installed but it continued to fail on read_timeout
>> being in the connection string.  For now I've updated the fuel-library
>> code to remove this item from the connection strings and will be
>> circling back around to figure out the correct 'fix' for this issue.
>>
>> I'm hoping to be able to have a working ISO, plugin and a set of
>> instructions that can be used to deploy a basic cloud using Fuel by
>> the end of this week.
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/240325/
>> [1] https://review.openstack.org/#/c/241615/
>> [2] https://review.openstack.org/#/c/241741/
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__

Re: [openstack-dev] [Fuel] Running Fuel node as non-superuser

[Stanislaw Bogatkin]

Bartolomiej, it's customer-related patches, they, I think, have to be done
for 6.1 prior to 8+ release.

Dmitry, it's nice to hear about it. Did you consider to use linux
capabilities on fuel-related processes instead of just using non-extended
POSIX privileged/non-privileged permission checks?

On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
bpiotrow...@mirantis.com> wrote:

> We don't develop features for already released versions… It should be done
> for master instead.
>
> BP
>
> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko  wrote:
>
>> Dmitry,
>> +1
>>
>> Do you plan to port your patchset to future Fuel releases?
>>
>> A.
>>
>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov > > wrote:
>>
>>> Hey guys.
>>>
>>> I've been working on making Fuel not to rely on superuser privileges
>>> at least for day-to-day operations. These include:
>>> a) running Fuel services (nailgun, astute etc)
>>> b) user operations (create env, deploy, update, log in)
>>>
>>> The reason for this is that many security policies simply do not
>>> allow root access (especially remote) to servers/environments.
>>>
>>> This feature/enhancement means that anything that currently is being
>>> run under root, will be evaluated and, if possible, put under a
>>> non-privileged
>>> user. This also means that remote root access will be disabled.
>>> Instead, users will have to log in with "fueladmin" user.
>>>
>>> Together with Omar  we've put together a blueprint[0] and a
>>> spec[1] for this feature. I've been developing this for Fuel 6.1, so
>>> there
>>> are two patches into fuel-main[2] and fuel-library[3] that can give you
>>> an
>>> impression of current approach.
>>>
>>> These patches do following:
>>> - Add fuel-admin-user package, which creates 'fueladmin'
>>> - Make all other fuel-* packages depend on fuel-admin-user
>>> - Put supervisord under 'fueladmin' user.
>>>
>>> Please review the spec/patches and let's have a discussion on the
>>> approach to
>>> this feature.
>>>
>>> Thank you.
>>>
>>> [0] https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser
>>> [1] https://review.openstack.org/243340
>>> [2] https://review.openstack.org/243337
>>> [3] https://review.openstack.org/243313
>>>
>>> --
>>> Dmitry Nikishov,
>>> Deployment 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
>>>
>>>
>>
>>
>> --
>> Adam Heczko
>> Security Engineer @ Mirantis Inc.
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] [Puppet] Potential critical issue, due Puppet mix stderr and stdout while execute commands

[Stanislaw Bogatkin]

I spoken with Sergii about this and prepared a patch for get rid of
SecurityWarning [0] - it was easy. But we can't get rid from
InsecurePlatformWarning
so easy way. I see next options:
1. Update python version as [1] said - should be hard task
2. Downgrade urllib version to one without such warning - is a bad idea, as
for me
3. Rewrite code to use non-standard ssl python module (pyOpenSSL, for
example) - may be a massive task
4. Use something like 2>/dev/null to don't show stderr when call the
command - doesn't looks good, cause problem can be seen on other places (I
saw similar problems with keystone provider, for example)
5. Rewrite code to split stderr/stdout, as Sergey proposed - is a most
reasonable idea, as for me.

[0] https://review.openstack.org/#/c/237379
[1]
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning


On Wed, Oct 21, 2015 at 10:02 AM, Sergey Vasilenko 
wrote:

> Hi, guys!
>
> Now I observe potential-dangerous situation in the providers of
> puppet-neutron module. I want share details, because not only
> puppet-neutron module may be broken by warnings from Openstack CLI
> utilities.
>
>
>  After updating urllib3 library on my lab, commands like 'neutron net
> list' began to throw warnings, like:
>
>> root@node-2:~# neutron net-list
>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>> InsecurePlatformWarning: A true SSLContext object is not available. This
>> prevents urllib3 from configuring SSL appropriately and may cause certain
>> SSL connections to fail. For more information, see
>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
>> .
>>   InsecurePlatformWarning
>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>> for a `commonName` for now. This feature is being removed by major browsers
>> and deprecated by RFC 2818. (See
>> https://github.com/shazow/urllib3/issues/497 for details.)
>>   SecurityWarning
>>
>> +--+---+---+
>> | id   | name  | subnets
>>   |
>>
>> +--+---+---+
>> | 9e1c0866-51f0-4659-8d5c-1c5d0843dab4 | net04_ext |
>> 29c952ec-2a13-46fc-a8a1-6e2468a92a95 172.18.171.0/24  |
>> | d70b399b-668b-4861-b092-4876ec65df60 | net04 |
>> b87fbfd1-0e52-4ab6-8987-286ef0912d1f 192.168.111.0/24 |
>>
>> +--+---+---+
>>
>
> root@node-2:~#
>
>
> Such urllib3 based warnings is only particular case. Warnings may appear
> by another reason while call any Openstack utilities.
>
> Such warnings lead to broke work of puppet-neutron manifests:
>
>> 2015-10-20 16:42:11 +
>> /Stage[main]/Main/Openstack::Network::Create_network[net04]/Neutron_network[net04]
>> (info): Evaluated in 5.51 seconds
>> 2015-10-20 16:42:11 + Puppet (debug): Prefetching neutron resources
>> for neutron_subnet
>> 2015-10-20 16:42:11 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-list --format=csv --column=id --quote=none'
>> 2015-10-20 16:42:13 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-show --format=shell InsecurePlatformWarning'
>> 2015-10-20 16:42:16 + Puppet::Type::Neutron_subnet::ProviderNeutron
>> (notice): Unable to complete neutron request due to non-fatal error:
>> "Execution of '/usr/bin/neutron subnet-show --format=shell
>> InsecurePlatformWarning' returned 1:
>> /usr/lib/python2.7/dist-packages/urllib3/util/ssl_.py:90:
>> InsecurePlatformWarning: A true SSLContext object is not available. This
>> prevents urllib3 from configuring SSL appropriately and may cause certain
>> SSL connections to fail. For more information, see
>> https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
>> InsecurePlatformWarning
>> /usr/lib/python2.7/dist-packages/urllib3/connection.py:251:
>> SecurityWarning: Certificate has no `subjectAltName`, falling back to check
>> for a `commonName` for now. This feature is being removed by major browsers
>> and deprecated by RFC 2818. (See
>> https://github.com/shazow/urllib3/issues/497 for details.)
>>   SecurityWarningUnable to find subnet with name 'InsecurePlatformWarning'
>> ". Retrying for 7 sec.
>
>  .
>
> Unable to find subnet with name 'InsecurePlatformWarning'
>> ". Retrying for 0 sec.
>> 2015-10-20 16:42:25 + Puppet (debug): Executing '/usr/bin/neutron
>> subnet-show --format=shell InsecurePlatformWarning'
>> 2015-10-20 16:42:27 + Puppet (err): Could not prefetch neutron_subnet
>> provider 'neutron': Can't retrieve subnet-show because Neutron or Keystone
>> API is not available.
>> /etc/puppet/modules/neutron/lib/puppet/provider/neutron.rb:153:in
>> 

Re: [openstack-dev] [Fuel] SSL keys saving

[Stanislaw Bogatkin]

I preparing patches for library, but there was raised another question: how
should we saving keypairs from UI? I see there two options:

1. It will be done via UI (JS?) that will post file to special URL and then
it will be saved via nginx HttpUploadModule. Caveats here:
- I don't know how we will deal with authentication. How nginx should
understand that this file got from trusted source?
- As we should place keys in different places for different clusters, some
handler should so it, we cannot save files with pure nginx. Who will write
this handler and maintain it?

2. It will be done via Nailgun that will store files directly in FS.
Caveats here:
- How about speed/locks? Now we store just small files with certificates
(4 kb in most of cases), but in future we, maybe, will need to save big
files. Will a solution with Nailgun work okay?
- Logs. As I understand, if file will be saved by nailgun API, it will be
saved in logs and we need some tool to cut it out from there.

So, which way seems better for you, folks?

On Fri, Aug 21, 2015 at 1:59 PM, Adam Heczko ahec...@mirantis.com wrote:

 Sorry in understood incorrectly - using HTTP/Web IMO usually makes kind of
 overhead if designed from the beginning.
 If there are some HTTP authentication/CSR request/key management
 mechanisms already in place, of course there is no overhead.

 Regards,

 A.

 On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote:

 Hi Adam,

 I'm not sure if understand you correctly, what do you mean by overhead
 for
 certificate provisioning? We already have all the mechanisms in place
 in order
 to provision certificates, the point is currently with user's
 certificates we work in
 absolutely different way and store them in absolutely different place.
 And this
 way leads to huge problems.

 Thanks,

 On Fri, Aug 21, 2015 at 1:33 PM, Adam Heczko ahec...@mirantis.com
 wrote:

 Hi Evgeniy,
 what you've proposed is all right, although it adds some overhead for
 certificate provisioning.
 In fact, to do it right we should probably define REST API for
 provisioning certificates.
 I'm rather for simplified approach, consisting of Shell / Puppet scripts
 for certificate upload/management.

 Regards,

 A.


 On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote:

 Hi Stanislaw,

 I agree that user's certificates mustn't be saved in Nailgun database,
 in cluster attributes,
 in this case it can be seen in all the logs, which is terrible security
 problem,
 and we already have a place where we keep auto-generated certificates
 and
 ssh-keys, and those are copied to specific nodes by Astute.

 So UI should send the file to specific URL, Nginx should be configured
 to send auth
 request to backend, after request is authorised, Nginx should save the
 file into predefined
 directory, the same which we use for autogenerated certificates, in
 this case such
 tool as OSTF can take certificates from a single place.

 Thanks,

 On Fri, Aug 21, 2015 at 12:10 PM, Stanislaw Bogatkin 
 sbogat...@mirantis.com wrote:

 Hi folks.

 Today I want to discuss the way we save SSL keys for Fuel
 environments. As you maybe know we have 2 ways to get a key:
 a. Generate it by Fuel (self-signed certificate will be created in
 this case). In this case we will generate private key, csr and crt in a
 pre-deployment hook on master node and then copy keypair to the nodes 
 which
 needed it.

 b. Get a pre-generated keypair from user. In this case user should
 create keypair by himself and then upload it through Fuel UI settings tab.
 In this case keypair will be saved in nailgun database and then will
 serialized into astute.yaml on cluster nodes, pulled from it by puppet and
 saved into a file.

 Second way has some flaws:
 1. We already have some keys for nodes and we store them on master
 node. Store keys in different places is bad, cause:
 1.1. User experience - user should remember that in some cases keys
 will be store in FS and in some other cases - in DB.
 1.2. It brings problems for implementation in other different places -
 for example, we need to get certificate for properly run OSTF tests and 
 now
 we should implement two different ways to deliver that certificate to OSTF
 container. The same for fuel-cli - we should somehow get certificate from
 DB and place it in FS to use it.
 2. astute.yaml is similar for all nodes. Not all of nodes needs to
 have private key, but now we cannot control this.
 3. If keypair data serializes into astute.yaml it means than that data
 automatically will be fetched when diagnostic snapshot will created. So in
 some cases in can lead to security vulnerability, or we will must to write
 another crutch to cut it out of diagnostic snapshot.


 So I propose to get rid of saving keypair in nailgun database and
 implement a way to always saving it to local FS on master node. We need to
 implement next items:

 - Change UI logic that saving keypair into DB to logic that will save
 it to local FS
 - Implement

[openstack-dev] [Fuel] SSL keys saving

[Stanislaw Bogatkin]

Hi folks.

Today I want to discuss the way we save SSL keys for Fuel environments. As
you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in this
case). In this case we will generate private key, csr and crt in a
pre-deployment hook on master node and then copy keypair to the nodes which
needed it.

b. Get a pre-generated keypair from user. In this case user should create
keypair by himself and then upload it through Fuel UI settings tab. In this
case keypair will be saved in nailgun database and then will serialized
into astute.yaml on cluster nodes, pulled from it by puppet and saved into
a file.

Second way has some flaws:
1. We already have some keys for nodes and we store them on master node.
Store keys in different places is bad, cause:
1.1. User experience - user should remember that in some cases keys will be
store in FS and in some other cases - in DB.
1.2. It brings problems for implementation in other different places - for
example, we need to get certificate for properly run OSTF tests and now we
should implement two different ways to deliver that certificate to OSTF
container. The same for fuel-cli - we should somehow get certificate from
DB and place it in FS to use it.
2. astute.yaml is similar for all nodes. Not all of nodes needs to have
private key, but now we cannot control this.
3. If keypair data serializes into astute.yaml it means than that data
automatically will be fetched when diagnostic snapshot will created. So in
some cases in can lead to security vulnerability, or we will must to write
another crutch to cut it out of diagnostic snapshot.


So I propose to get rid of saving keypair in nailgun database and implement
a way to always saving it to local FS on master node. We need to implement
next items:

- Change UI logic that saving keypair into DB to logic that will save it to
local FS
- Implement according fixes in fuel-library
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL for master node API

[Stanislaw Bogatkin]

Hello again,

I heard a questions from team how exactly we will implement SSL for master
node. There is a way how I look it:
1. We implement ability to use SSL in fuel-nailgun-agent (I already created
a patch, it is on review now) and merge it in 7.0 release cycle. Also we
will need to implement SSL ability in other clients (for example, fuel-cli)
2. We save both HTTP and HTTPS on master node, because we need to have
seamless master node upgrade. As long as we have 2 years of release
support, we will need to have both protocols enabled for 2 years. After
that period of time we will disable HTTP completely and continue to use
HTTPS only.
3. For those people, who need to force HTTPS-only before 2 years
expiration, I'll prepare a patch that will disable plain HTTP in nginx on
master node if special key in hiera will be found. Also we will add a note
about this to our documentation and release notes (cause if someone will
decide to force HTTPS, he must to upgrade fuel-nailgun-client on all old
nodes too).

On Tue, Aug 4, 2015 at 5:05 PM, Stanislaw Bogatkin sbogat...@mirantis.com
wrote:

 Seems that second solution is okay.

 Sebastian, I'll try to fix it before SCF.

 On Tue, Aug 4, 2015 at 4:25 PM, Sebastian Kalinowski 
 skalinow...@mirantis.com wrote:

 +1 for option 2)

 But I have a question: how do we fit with this into the scope of Feature
 Freeze and Soft Code Freeze this week?
 Any ETAs?

 2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com:

 FYI: There is Strict-Transport-Security
 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security header
 which can also be useful here (unless we want to make SSL for master node
 optional)

 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov vshars...@mirantis.com:

 Hi,

 +1 to 2nd solution too.

 On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 +1 to 2nd solution, in this case old environments will work without
 additional
 actions. Agents for new environments, CLI and UI will use SSL.
 But probably for UI we will have to perform redirect on JS level.

 Thanks,

 On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin 
 sbogat...@mirantis.com wrote:

 Hi guys,
 in overall movement of Fuel to use secure sockets we think about
 wrapping master node UI and API calls to SSL. But there are next caveat:

 a) fuel-nailgun-agent cannot work via SSL now and need to be
 rewritten a little. But if it will be rewritten in 7.0 and HTTPS on 
 master
 node will be forced by default, it will break upgrade from previous
 releases to 7.0 due fact that after master node upgrade from 6.1 to 7.0 
 we
 will have HTTPS by default and fuel-nailgun-agent on all environments 
 won't
 upgraded, so it won't be able to connect to master node after upgrade. It
 breaks seamless upgrade procedure.

 What options I see there:
 1. We can forcedly enable SSL for master node and rewrite clients in
 7.0 to be able to work over it. In release notes for 7.0 we will write
 forewarning that clients which want to upgrade master node from previous
 releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
 all deployed environments.

 2. We can have both SSL and non-SSL versions enabled by default and
 rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
 availability and be able to work in plain HTTP for legacy mode. So, for 
 all
 new environments SSL will be used by default and for old ones plain HTTP
 will continue to work too. Master node upgrade will not be broken in this
 case.

 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
 save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in 
 next
 releases. It is just postponed version of first clause, so it doesn't 
 seems
 valid for me, actually.

 I would be really glad to hear what you think about this. Thank you
 in advance.


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




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




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




 --
 Vitaly Kramskikh,
 Fuel UI Tech Lead,
 Mirantis, Inc.


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

[openstack-dev] [Fuel] SSL for master node API

[Stanislaw Bogatkin]

Hi guys,
in overall movement of Fuel to use secure sockets we think about wrapping
master node UI and API calls to SSL. But there are next caveat:

a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
little. But if it will be rewritten in 7.0 and HTTPS on master node will be
forced by default, it will break upgrade from previous releases to 7.0 due
fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
default and fuel-nailgun-agent on all environments won't upgraded, so it
won't be able to connect to master node after upgrade. It breaks seamless
upgrade procedure.

What options I see there:
1. We can forcedly enable SSL for master node and rewrite clients in 7.0 to
be able to work over it. In release notes for 7.0 we will write forewarning
that clients which want to upgrade master node from previous releases to
7.0 must also install new fuel-nailgun-agent to all nodes in all deployed
environments.

2. We can have both SSL and non-SSL versions enabled by default and rewrite
fuel-nailgun-client in 7.0 such way that it will check SSL availability and
be able to work in plain HTTP for legacy mode. So, for all new environments
SSL will be used by default and for old ones plain HTTP will continue to
work too. Master node upgrade will not be broken in this case.

3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save
both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
releases. It is just postponed version of first clause, so it doesn't seems
valid for me, actually.

I would be really glad to hear what you think about this. Thank you in
advance.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL for master node API

[Stanislaw Bogatkin]

Seems that second solution is okay.

Sebastian, I'll try to fix it before SCF.

On Tue, Aug 4, 2015 at 4:25 PM, Sebastian Kalinowski 
skalinow...@mirantis.com wrote:

 +1 for option 2)

 But I have a question: how do we fit with this into the scope of Feature
 Freeze and Soft Code Freeze this week?
 Any ETAs?

 2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com:

 FYI: There is Strict-Transport-Security
 https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security header
 which can also be useful here (unless we want to make SSL for master node
 optional)

 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov vshars...@mirantis.com:

 Hi,

 +1 to 2nd solution too.

 On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 +1 to 2nd solution, in this case old environments will work without
 additional
 actions. Agents for new environments, CLI and UI will use SSL.
 But probably for UI we will have to perform redirect on JS level.

 Thanks,

 On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin 
 sbogat...@mirantis.com wrote:

 Hi guys,
 in overall movement of Fuel to use secure sockets we think about
 wrapping master node UI and API calls to SSL. But there are next caveat:

 a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten
 a little. But if it will be rewritten in 7.0 and HTTPS on master node will
 be forced by default, it will break upgrade from previous releases to 7.0
 due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS
 by default and fuel-nailgun-agent on all environments won't upgraded, so 
 it
 won't be able to connect to master node after upgrade. It breaks seamless
 upgrade procedure.

 What options I see there:
 1. We can forcedly enable SSL for master node and rewrite clients in
 7.0 to be able to work over it. In release notes for 7.0 we will write
 forewarning that clients which want to upgrade master node from previous
 releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
 all deployed environments.

 2. We can have both SSL and non-SSL versions enabled by default and
 rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
 availability and be able to work in plain HTTP for legacy mode. So, for 
 all
 new environments SSL will be used by default and for old ones plain HTTP
 will continue to work too. Master node upgrade will not be broken in this
 case.

 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
 save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in 
 next
 releases. It is just postponed version of first clause, so it doesn't 
 seems
 valid for me, actually.

 I would be really glad to hear what you think about this. Thank you in
 advance.


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




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




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




 --
 Vitaly Kramskikh,
 Fuel UI Tech Lead,
 Mirantis, Inc.

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



 __
 OpenStack Development Mailing 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

[Stanislaw Bogatkin]

Hi,

can we just add all needed functionality from old fuel client that fuel2
needs, then say that old fuel-client is deprecated now and will not support
some new features, then add new features to fuel2 only? It seems like best
way for me, cause with this approach:
1. Clients will can use only one version of client (new one) w/o switching
between 2 clients with different syntax
2. We won't have to add new features to two clients.

On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote:

 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


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

Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

[Stanislaw Bogatkin]

+1

On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com wrote:

 +1

 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com
 wrote:

 At the moment we have several core reviewers for the fuel-main project.

 Roman Vyalov is responsible for merging of infrastructure-related
 variables and for the lists of packages.
 I am responsible for merges in make system. And I have not so much time
 for digging into makefiles.

 Vladimir Kozhukalov is responsible for the makesystem for a long time.
 And now he works on reducing complexity of the system. I do not merge any
 single patch without his approval. It's time to give formal transfer of
 responsibility for the fuel-main to him. I nominate Vladimir to fuel-main
 core.

 Please reply with +1/-1.

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



 __
 OpenStack Development Mailing 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] SSL feature status

[Stanislaw Bogatkin]

Hi,

we have a spec that says we disable SSL by default and it was successfully
merged with that, no one was against such decision. So, if we want to
enable it by default now - we can. It should be done as a part of our usual
process, I think - I'll create a bug for it and fix it.

Current status of feature is next:
1. All codebase for SSL is merged
2. Some tests for it writing my QA - not all of them are done yet.

I'll update blueprints as soon as possible. Sorry for inconvenience.

On Mon, Jul 20, 2015 at 8:44 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 Hi guys,
 did we enable SSL for Fuel Master node and OpenStack REST API endpoints by
 default? If not, let's enable it by default. I don't know why we should not.

 Looks like we need to update blueprints as well [1], [2], as they don't
 seem to reflect current status of the feature.

 [1] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints
 [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints

 Stas, as you've been working on it, can you please provide current status?

 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

Re: [openstack-dev] [Fuel Zabbix in deployment tasks

[Stanislaw Bogatkin]

Actually, I didn't participate in that process a lot - just reviewed plugin
couple of times and as I know, we had had a commits that deleted zabbix
from current Fuel.
There is bug about that: https://bugs.launchpad.net/fuel/+bug/1455664
There is a review: https://review.openstack.org/#/c/182615/

Seems that it should be resolved and merged to have zabbix code actually
deleted from current master.

On Thu, Jul 16, 2015 at 1:29 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:

 I thought it was done...
 Stas - do you know anything about it?

 On Thu, Jul 16, 2015 at 9:18 AM Sergii Golovatiuk 
 sgolovat...@mirantis.com wrote:

 Hi,

 Working on granular deployment, I realized we still call zabbix.pp in
 deployment tasks. As far as I know zabbix was moved to plugin. Should we
 remove zabbix from
 1. Deployment graph
 2. fixtures
 3. Tests
 4. Any other places

 Are we going to clean up zabbix code as part of migration to plugin?

 --
 Best regards,
 Sergii Golovatiuk,
 Skype #golserge
 IRC #holser

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

 --
 Mike Scherbakov
 #mihgen

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

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

[Stanislaw Bogatkin]

2 weeks seems too small for me. We easy can be in situation when fix for
medium bug is done, but SCF starts. And gap between SCF and release easily
can be more than a month. So, 2 months seems okay for me if speaking about
forcibly applying auto-abandon by major vote. And I'm personally against
such innovation at all.

On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas dava...@gmail.com wrote:

 That's a very good plan (Initial feedback/triage) Mike.

 thanks,
 dims

 On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov
 mscherba...@mirantis.com wrote:
  +1 for just reusing existing script, and adjust it on the way. No need to
  immediately switch from infinite time to a couple of weeks, we can always
  adjust it later. But 1-2 month should be a good start already.
 
  Our current stats [1] look just terrible. Before we enable an
 auto-abandon,
  we need to go every single patch first, and review it / provide comment
 to
  authors. The idea is not to abandon some good patches, and not to offend
  contributors...
 
  Let's think how we can approach it. Should we have core reviewers to
 check
  their corresponding components?
 
  [1] http://stackalytics.com/report/reviews/fuel-group/open
 
  On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins s...@coreitpro.com
 wrote:
 
  Let's keep it at 4 weeks without comment, and Jenkins failed - similar
  to the script that Kyle Mestery uses for Neutron. In fact, we could
  actually just use his script ;)
 
 
 
 https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh
  --
  Sean M. Collins
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  --
  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
 



 --
 Davanum Srinivas :: https://twitter.com/dims

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

__
OpenStack Development Mailing 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] wrong network for keystone endpoint in 6.1 ?

[Stanislaw Bogatkin]

Hi Daniel,

answer is no - actually there is no strong dependency between public and
internal/admin endpoints. In your case keystone client ask keystone on
address 10.52.71.39 (which, I think, was provided by system
variable OS_AUTH_URL), auth on it and then keystone give endpoints list to
client. Client selected admin endpoint from this list (192.168.20.3
address) and tried to get information you asked. It's a normal behavior.

So, in Fuel by default we have 3 different endpoints for keystone - public
on public VIP, port 5000; internal on management VIP, port 5000, admin on
management VIP, port 35357.

On Thu, Jul 9, 2015 at 4:59 PM, Daniel Comnea comnea.d...@gmail.com wrote:

 Hi,

 I'm running Fuel 6.1 and i've seen an interesting behavior which i think
 match bug [1]

 Basically the adminUrl  publicUrl part of keystone endpoint are different

 And the result of that is that you can't run keystone cli - i.e
 create/list tenants etc

 keystone --debug tenant-list
 /usr/local/lib/python2.7/site-packages/keystoneclient/shell.py:65:
 DeprecationWarning: The keystone CLI is deprecated in favor of python-
 openstackclient. For a Python library, continue using python-keys
 toneclient.
   'python-keystoneclient.', DeprecationWarning)
 DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
 http://10.20.71.39:5000/v2.0/tokens
 INFO:requests.packages.urllib3.connectionpool:Starting new HTTP
 connection (1): 10.52.71.39
 DEBUG:requests.packages.urllib3.connectionpool:POST /v2.0/tokens
 HTTP/1.1 200 3709
 DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
 http://192.168.20.3:35357/v2.0/tenants -H User-Agent: python-
 keystoneclient -H Accept: application/json -H X-Auth-Token:
 {SHA1}cc918b89c2dca563edda43e01964b1f1979c552b

 shouldn't adminURL = publicURL = br-ex for keystone?


 Dani


 [1] https://bugs.launchpad.net/fuel/+bug/1441855

 __
 OpenStack Development Mailing 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] LBaaS in version 5.1

[Stanislaw Bogatkin]

Hi Daniel,

sorry for such late answer. Yes, exactly so - just use standard LBaaS.

On Wed, May 6, 2015 at 8:38 PM, Daniel Comnea comnea.d...@gmail.com wrote:

 Thanks Stanislaw for reply.

 sure i can do that the only unknown question i have is related to the Fuel
 HA controllers. I assume i can easily ignore the controller HA (LBaaS
 doesn't support HA :) ) and just go the standard LBaaS?



 On Wed, May 6, 2015 at 2:55 PM, Stanislaw Bogatkin sbogat...@mirantis.com
  wrote:

 Hi Daniel,

 Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system
 was introduced and LBaaS plugin was created. So, I think than docs about it
 never existed for 5.1. But as I know, you can easily install LBaaS in 5.1
 (it should be shipped in our repos) and configure it with accordance to
 standard OpenStack cloud administrator guide [1].

 [1]
 http://docs.openstack.org/admin-guide-cloud/content/install_neutron-lbaas-agent.html

 On Wed, May 6, 2015 at 2:12 PM, Daniel Comnea comnea.d...@gmail.com
 wrote:

 HI all,

 Recently i used Fuel 5.1 to deploy Openstack Icehouse on a Lab (PoC) and
 a request came with enabling Neutron LBaaS.

 I have looked up on Fuel doc to see if this is supported in the version
 i'm running but failed ot find anything.

 Anyone can point me to any docs which mentioned a) yes it is supported
 and b) how to update it via Fuel?

 Thanks,
 Dani


 __
 OpenStack Development Mailing 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] LBaaS in version 5.1

[Stanislaw Bogatkin]

Hi Daniel,

Unfortunately, we never supported LBaaS until Fuel 6.0 when plugin system
was introduced and LBaaS plugin was created. So, I think than docs about it
never existed for 5.1. But as I know, you can easily install LBaaS in 5.1
(it should be shipped in our repos) and configure it with accordance to
standard OpenStack cloud administrator guide [1].

[1]
http://docs.openstack.org/admin-guide-cloud/content/install_neutron-lbaas-agent.html

On Wed, May 6, 2015 at 2:12 PM, Daniel Comnea comnea.d...@gmail.com wrote:

 HI all,

 Recently i used Fuel 5.1 to deploy Openstack Icehouse on a Lab (PoC) and a
 request came with enabling Neutron LBaaS.

 I have looked up on Fuel doc to see if this is supported in the version
 i'm running but failed ot find anything.

 Anyone can point me to any docs which mentioned a) yes it is supported and
 b) how to update it via Fuel?

 Thanks,
 Dani

 __
 OpenStack Development Mailing 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] glusterfs plugin

[Stanislaw Bogatkin]

Hi Przemyslaw,
I would be glad to be core reviewer to fuel-plugin-glusterfs as long as
seems than I was only one person who push some commits to it.

On Thu, Apr 2, 2015 at 10:47 AM, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

 Since there is no reply here I have taken steps to become core reviewer
 of the (orphaned) repos [1], [2], [3], [4].

 Should anyone want to take responsibility for them please write me.

 I have also taken steps to get the fuel-qa script working and will make
 sure tests pass with new manifests. I will also update manifests'
 version so that there will be no deprecation warnings.

 P.

 [1]

 https://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-external-glusterfs,access
 [2]

 https://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-group-based-policy,access
 [3]

 https://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-external-nfs,access
 [4]

 https://review.openstack.org/#/admin/projects/stackforge/fuel-plugin-cinder-netapp,access

 On 04/01/2015 03:48 PM, Przemyslaw Kaminski wrote:
  Hello,
 
  I've been investigating bug [1] concentrating on the
  fuel-plugin-external-glusterfs.
 
  First of all: [2] there are no core reviewers for Gerrit for this repo
  so even if there was a patch to fix [1] no one could merge it. I saw
  also fuel-plugin-external-nfs -- same issue, haven't checked other
  repos. Why is this? Can we fix this quickly?
 
  Second, the plugin throws:
 
  DEPRECATION WARNING: The plugin has old 1.0 package format, this format
  does not support many features, such as plugins updates, find plugin in
  new format or migrate and rebuild this one.
 
  I don't think this is appropriate for a plugin that is listed in the
  official catalog [3].
 
  Third, I created a supposed fix for this bug [4] and wanted to test it
  with the fuel-qa scripts. Basically I built an .fp file with
  fuel-plugin-builder from that code, set the GLUSTER_PLUGIN_PATH variable
  to point to that .fp file and then ran the
  group=deploy_ha_one_controller_glusterfs tests. The test failed [5].
  Then I reverted the changes from the patch and the test still failed
  [6]. But installing the plugin by hand shows that it's available there
  so I don't know if it's broken plugin test or am I still missing
 something.
 
  It would be nice to get some QA help here.
 
  P.
 
  [1] https://bugs.launchpad.net/fuel/+bug/1415058
  [2] https://review.openstack.org/#/admin/groups/577,members
  [3] https://fuel-infra.org/plugins/catalog.html
  [4] https://review.openstack.org/#/c/169683/
  [5]
 
 https://www.dropbox.com/s/1mhz8gtm2j391mr/fail_error_deploy_ha_one_controller_glusterfs_simple-2015_04_01__11_39_11.tar.xz?dl=0
  [6]
 
 https://www.dropbox.com/s/ehjox554xl23xgv/fail_error_deploy_ha_one_controller_glusterfs_simple-2015_04_01__13_16_11.tar.xz?dl=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] Nominate Irina Povolotskaya for fuel-docs core

[Stanislaw Bogatkin]

+1

On Wed, Mar 25, 2015 at 10:10 PM, Dmitry Borodaenko 
dborodae...@mirantis.com wrote:

 Fuelers,

 I'd like to nominate Irina Povolotskaya for the fuel-docs-core team.
 She has contributed thousands of lines of documentation to Fuel over
 the past several months, and has been a diligent reviewer:


 http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs

 I believe it's time to grant her core reviewer rights in the fuel-docs
 repository.

 Core reviewer approval process definition:
 https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

 --
 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] Stop distributing IMG artifact and start using hybrid ISO.

[Stanislaw Bogatkin]

Hi everyone,

we have merged code that will create hybrid ISO. Current 6.1 #147 ISO
already can be booted from USB by standard method (just using dd
of=/path/to/iso of=/path/to/usb/stick).

Creating IMG artifact will be disabled soon, so, please, be aware of it.
__
OpenStack Development Mailing 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] Distribution of keys for environments

[Stanislaw Bogatkin]

Hi.
I'm vote for second option, cause if we will want to implement some unified
hierarchy (like Fuel as CA for keys on controllers for different env's)
then it will fit better than other options. If we implement 3rd option then
we will reinvent the wheel with SSL in future. Bare rsync as storage for
private keys sounds pretty uncomfortable for me.

On Wed, Jan 28, 2015 at 6:44 PM, Dmitriy Shulyak dshul...@mirantis.com
wrote:

 Hi folks,

 I want to discuss the way we are working with generated keys for
 nova/ceph/mongo and something else.

 Right now we are generating keys on master itself, and then distributing
 them by mcollective
 transport to all nodes. As you may know we are in the process of making
 this process described as
 task.

 There is a couple of options:
 1. Expose keys in rsync server on master, in folder /etc/fuel/keys, and
 then copy them with rsync task (but it feels not very secure)
 2. Copy keys from /etc/fuel/keys on master, to /var/lib/astute on target
 nodes. It will require additional
 hook in astute, smth like copy_file, which will copy data from file on
 master and put it on the node.

 Also there is 3rd option to generate keys right on primary-controller and
 then distribute them on all other nodes, and i guess it will be
 responsibility of controller to store current keys that are valid for
 cluster. Alex please provide more details about 3rd approach.

 Maybe there is more options?



 __
 OpenStack Development Mailing 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] removing single mode

[Stanislaw Bogatkin]

+1

On Tue, Jan 27, 2015 at 4:05 PM, Aleksandr Didenko adide...@mirantis.com
wrote:

 Hi,

 After starting implementing granular deployment we've faced a bunch of
 issues that would make further development of this feature much more
 complicated if we have to support both Simple and HA deployment modes. For
 example: simple mode does not require cluster (corosync, pacemaker, vips,
 etc), so we had to skip this task for Simple mode somehow - we can use
 conditional tasks, or conditional manifests in our tasks, or create
 separate task graphs for different deployment modes, etc - either way it's
 pretty much doubling the amount of work for some parts of Fuel and our
 development cycle.

 At the moment, CI blocks us from further development of fuel-library
 modularization BP [2] because we still use Simple mode in CI. So in order
 to proceed with this BP we have two options:

 1) remove Simple mode from CI/QA and thus drop it completely from Fuel
 2) double our efforts to support both Simple and HA modes in granular
 deployment

 We have a BP about single-controller HA [1]. HA with single controller
 works just fine at the moment. So if you want to test Fuel on a minimum set
 of nodes, you can do this on 3 nodes (Fuel master, controller, compute),
 just like with Simple mode before. I suppose, it's time to finally drop
 support for Simple mode in Fuel :)

 [1] https://blueprints.launchpad.net/fuel/+spec/single-controller-ha
 [2]
 https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization

 --
 Regards,
 Aleksandr Didenko


 On Tue, Aug 26, 2014 at 9:25 AM, Mike Scherbakov mscherba...@mirantis.com
  wrote:

 Definitely fuel spec is needed :)


 On Mon, Aug 25, 2014 at 8:45 PM, Evgeniy L e...@mirantis.com wrote:

 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 xar...@gmail.com
 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




 --
 Mike Scherbakov
 #mihgen


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 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] [FUEL] Bootstrap NTP sync.

[Stanislaw Bogatkin]

Hi guys,

We have a little concern related to Fuel bootstrap node NTP sync. Currently
we trying to sync time on bootstrap node with master node, but problem is
that NTP protocol has long convergence time, so if we just install master
node and right after that try to start some bootstrap node - bootstrap
fails to sync time with master due to that fact that master doesn't appear
as trust time source at that moment.
How we can solve that problem:

1. We can start bootstrap long time after master (when master will
convergence it's time) - seems that it's a bad idea, cause master node
convergence time depends on upstream NTP servers and may be quite long -
user shouldn't wait so long time to just start bootstrap node.

2. We can use master local time as trust forcibly - actually, we already
do that for case when master is a bare metal node. We can do it for virtual
node too, it is not such bad idea as many can say, especially when master
node stratum will low (10-12).

3. We can mask return value for bootstrap node ntpdate service such way
that it always will return success - it's a dirty hack, it will calm down
customers, but it doesn't solve problem - time will be unsynced.

As for me - second option is best. What do you think about it?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [FUEL] Bootstrap NTP sync.

[Stanislaw Bogatkin]

Hi Tomasz,
External NTP is good, but we should be able to deploy w/o internet access
(but slaves should be in sync with master node), so sync with master node
is better. I understand that it's slightly against standards - but at that
moment we just obligatoriness to be in sync with master node, cause some of
followed tasks depends on synced time.

On Fri, Dec 19, 2014 at 2:12 PM, Tomasz Napierala tnapier...@mirantis.com
wrote:


  On 19 Dec 2014, at 10:00, Stanislaw Bogatkin sbogat...@mirantis.com
 wrote:
 
  Hi guys,
 
  We have a little concern related to Fuel bootstrap node NTP sync.
 Currently we trying to sync time on bootstrap node with master node, but
 problem is that NTP protocol has long convergence time, so if we just
 install master node and right after that try to start some bootstrap node -
 bootstrap fails to sync time with master due to that fact that master
 doesn't appear as trust time source at that moment.
  How we can solve that problem:
 
  1. We can start bootstrap long time after master (when master will
 convergence it's time) - seems that it's a bad idea, cause master node
 convergence time depends on upstream NTP servers and may be quite long -
 user shouldn't wait so long time to just start bootstrap node.
 
  2. We can use master local time as trust forcibly - actually, we
 already do that for case when master is a bare metal node. We can do it for
 virtual node too, it is not such bad idea as many can say, especially when
 master node stratum will low (10-12).
 
  3. We can mask return value for bootstrap node ntpdate service such way
 that it always will return success - it's a dirty hack, it will calm down
 customers, but it doesn't solve problem - time will be unsynced.
 
  As for me - second option is best. What do you think about it?

 Second option looks best, although it’s still against standards. I guess
 that if we provide possibility to deifne external NTP server as an
 alternative, we are hsfa here and can live with that.

 Regards,
 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@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

Re: [openstack-dev] [Fuel] fuel master monitoring

[Stanislaw Bogatkin]

Hi all,
As I understand, we just need to monitoring one node - Fuel master. For
slave nodes we already have a solution - zabbix.
So, in that case why we need some complicated stuff like monasca? Let's use
something small, like monit or sensu.

On Mon, Nov 24, 2014 at 10:36 PM, Fox, Kevin M kevin@pnnl.gov wrote:

  One of the selling points of tripleo is to reuse as much as possible
 from the cloud, to make it easier to deploy. While monasca may be more
 complicated, if it ends up being a component everyone learns, then its not
 as bad as needing to learn two different monitoring technologies. You could
 say the same thing cobbler vs ironic. the whole Ironic stack is much more
 complicated. But for an openstack admin, its easier since a lot of existing
 knowlege applies. Just something to consider.

 Thanks,
 Kevin

 --
 *From:* Tomasz Napierala
 *Sent:* Monday, November 24, 2014 6:42:39 AM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Fuel] fuel master monitoring


  On 24 Nov 2014, at 11:09, Sergii Golovatiuk sgolovat...@mirantis.com
 wrote:
 
  Hi,
 
  monasca looks overcomplicated for the purposes we need. Also it requires
 Kafka which is Java based transport protocol.
  I am proposing Sensu. It's architecture is tiny and elegant. Also it
 uses rabbitmq as transport so we won't need to introduce new protocol.

 Do we really need such complicated stuff? Sensu is huge project, and it's
 footprint is quite large. Monit can alert using scripts, can we use it
 instead of API?

 Regards,
 --
 Tomasz 'Zen' Napierala
 Sr. OpenStack Engineer
 tnapier...@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

Re: [openstack-dev] [Fuel] fuel master monitoring

[Stanislaw Bogatkin]

As for me - zabbix is overkill for one node. Zabbix Server + Agent +
Frontend + DB + HTTP server, and all of it for one node? Why not use
something that was developed for monitoring one node, doesn't have many
deps and work out of the box? Not necessarily Monit, but something similar.

On Wed, Nov 26, 2014 at 6:22 PM, Przemyslaw Kaminski pkamin...@mirantis.com
 wrote:

 We want to monitor Fuel master node while Zabbix is only on slave nodes
 and not on master. The monitoring service is supposed to be installed on
 Fuel master host (not inside a Docker container) and provide basic info
 about free disk space, etc.

 P.


 On 11/26/2014 02:58 PM, Jay Pipes wrote:

 On 11/26/2014 08:18 AM, Fox, Kevin M wrote:

 So then in the end, there will be 3 monitoring systems to learn,
 configure, and debug? Monasca for cloud users, zabbix for most of the
 physical systems, and sensu or monit to be small?

 Seems very complicated.

 If not just monasca, why not the zabbix thats already being deployed?


 Yes, I had the same thoughts... why not just use zabbix since it's used
 already?

 Best,
 -jay

 ___
 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] NTP settings.

[Stanislaw Bogatkin]

Hi all,
Today we have a next workflow about NTP in Fuel:

1. When someone deploy a master node, we need to somehow operate with NTP
and set upstream NTP servers to Fuel NTP daemon on master node.
2. NTP will enabled by default and set to default upstream values (from
ntp.org pool).
3. If user will enter to fuelmenu then then he can change that values and
it will stored as new ones.

That can lead to some errors at deploy, some as:
1. User set upstream NTP (or use defaults).
2. By some reasons that NTP servers get unreacheable (i.e. network down).
3. User creates environment and push 'deploy' button.
4. In the middle of deploy process upstream NTP become reacheable and
master node sync with them.
If time on master node before that sync will have big shift regarding to
real time, then we will have 2 problems:
1. Deploy can fail, cause slave nodes will sync with master one time only -
right after provisioning and if master node resync with upstream in the
middle of deploy - some services can stop works (e.g. mcollective).
3. It will be more complicate to understand logs, cause it will shifted too.

As I see, we have two ways to solve this:
1. Check upstream NTP reachability and disable upstream servers if they
unreachable at fuelmenu step. It will cost us some shift with real time in
the end.

 or

2. Disable NTP upstream servers if they unreachable right after user press
'deploy' button and enable them after deploy is over.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [FUEL] Re: SSL in Fuel.

[Stanislaw Bogatkin]

I think that if we have 3 blueprints that realises some SSL stuff around
themselves then we can discuss it here.
My vision about SSL in Fuel split into 3 parts:

A) We need to implement [1] blueprint, cause it is only one way to generate
certificates.
How i see that:
1.0 We sync puppet-openssl from upstream, adapt it for Fuel tasks.
1.1 We create docker container (we already have many, so containerized
CA should work well) with OpenSSL and puppet manifests in it.
1.2 When container will start first time, it will create CA that will
store on master node.

Our workitems here is:
- Create docker container
- Sync upstream puppet-openssl and adapt it for Fuel
- Write code to create CA

B) We need to implement [2] blueprint. How I see that:
1.3 When CA container start first time and creates CA, then it will
check for keypair for master node (Fuel UI). If that keypair will not
found, then CA create it, change nginx conffile properly and restart nginx
on master node.

Our workitems here is:
- Write code to check if we already have generated certificate and generate
new if we have not.

C) Then we need to implement [3] blueprint
For next step we have 2 options:
  First:
1.3 When we create new cluster then we know all information to create
new keypair(s). When user press Deploy changes button, then we will
create new keypair(s).
Q: Main question here is - how many keypairs we will create? One for every
service or one for all?
1.4 We will distribute key(s) with mcollective agent (similar to how we
sync puppet manifests from master node to other nodes). After that private
key(s) will deleted from master node.
1.5 On nodes puppet will do all work. We need to write some code for
that
Pros of that method:
+ It's relative simple, we can create clean and lucid code that
will be easy for support
Cons of that method:
- We need to send every private key over network. We can reduce
this danger cause we will already have passwordless sync over network
between master node and other nodes, cause we will generate ssh keys for
nodes before we will distribute any data at deployment stage.

  Second:
1.3 When we create new cluster, we do all work same way as we do it
now, but after provisioning we will create keypair on first node, make csr
for every service (or for one, if we will create one certificate for all
services) and send that csr to master node, where it will signed and
certificate will send back.
1.4 Puppet will do all work on nodes. We, obviously, need to write some
code for it. But we need to sync our keys over controllers all the same
(and now we don't have reliable mechanism to do this)
Pros of that method:
+ I don't see any
Cons of that method:
- Code will be not so obvious
- To generate cert we need to rely to other service (network) and
if network will unreachable then csr signing will fail and all following
deployment will fail because we will not have valid certificate

Independing of choice (first or second), our workitems here is:
- Write code to provide functions about generating keypairs, csr's and
signing them.

1.5. When we have created CA and certs for services, we can do usual
puppet apply to deploy changes.

Workitems on that stage:
- Sync upstream modules that already have big changes to SSL support (e.g.
HAProxy) and adapt that modules to Fuel usage
- Rewrite some of manifests to support https support

As I see, at that phase we can say that Stage I for blueprint [3] is ready.
What we can do next? My thoughts is that:

2. We need to think about use case when user want to import his own
certificate to Fuel or Openstack services endpoints (cause in that case
users will not see warning popup in browser about not trusted certificate
or cause corporate policy say to do that). I see that way:

2.1 We can provide ability to change some keypairs (e.g. for Fuel UI
and Horizon)
Q: How many keys user can change? We can provide ability to change all keys
(but why we need to do that?)
Q: If user will replace some of keys with his own key - how we will check
that it is not some malicious but valid user key? Or we will trust all keys
by default?
To do that we will need to change:
- Some UI changes to provide ability to upload user keys
- Some Nailgun and Astute changes to operate with new keys
- Some puppet manifest changes to apply new keys and restart services
- Some changes to check basic validity of uploaded keys (expiry date, key
length, key type)

3. We can give user ability to change CA keypair (if user trust certificate
from that keypair then he automatically will trust all certificates that
will signed with that CA, so if user company trusted CA issue
cross-sertificate for Fuel then user automatically will agree that all
certificates in deployed by Fuel services is trusted). For do that we need:
- Some UI changes to provide ability to upload user CA key
- Some Nailgun and Astute changes to operate with new CA keys
- Write