Re: [openstack-dev] [Fuel] Getting rid of ISO

[Vladimir Kozhukalov]

Ruijing,

In a nutshell, the guide would be
0) install vanilla Centos 7
1) install fuel-release package (it configures necessary yum repos)
wget
http://packages.fuel-infra.org/repositories/centos/master-centos7/snapshots/os-2016-09-19-093900/x86_64/Packages/fuel-release-10.0.0-1.mos6376.git.a8c98d0.noarch.rpm
rpm -Uvh fuel-release-10.0.0-1.mos6376.git.a8c98d0.noarch.rpm
2) install fuel-setup package
yum install fuel-setup
3) run bootstrap script (be aware, that bootstrap script reconfigures some
of system parameters)
/usr/sbin/bootstrap_admin_node.sh

I'll describe the whole procedure on the Fuel wiki page. Fuel deployment
procedure is to be improved in Ocata.

Regarding your previous question about docker image, we are not planning to
provide a single Fuel docker image (docker containers are not VMs).
Container is an isolated process and Fuel assumes we run multiple processes
(API, RPC, etc.). Given that, Fuel should be a set of docker containers. We
used to run Fuel in containers, but those were kind of mess when we ran
puppet when building images and we put those images inside rpms and inside
ISO. We definitely don't want to have something like this again. But if you
use Docker images that are built from pure Dockerfiles (not using puppet,
from source code) and publishing them on docker registry that could be a
way to provide development environment (for plugin developers it could be
super convenient). Yes, that was in our plans for Newton, but we didn't
manage to implement this. Maybe in Ocata.




Vladimir Kozhukalov

On Mon, Sep 19, 2016 at 9:33 AM, Guo, Ruijing <ruijing@intel.com> wrote:

> Hi, Vladimir
>
>
>
> Any guide to install from rpm?
>
>
>
> Thanks,
>
> -Ruijing
>
> *From:* Vladimir Kozhukalov [mailto:vkozhuka...@mirantis.com]
> *Sent:* Tuesday, August 16, 2016 4:58 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [Fuel] Getting rid of ISO
>
>
>
> Dear colleagues,
>
> We finally have working custom deployment job that deploys Fuel admin node
> using online RPM repositories (not ISO) on vanilla Centos 7.0.
>
> Currently all Fuel system and deployment tests use ISO and we are planning
> to re-implement all these jobs (including BVT, SWARM, and Fuel CI jobs) to
> exclude ISO from the pipeline. That will allow us to get rid of ISO as our
> deliverable and instead rely totally on package repositories. Linux
> distributions like Ubuntu, Debian, RHEL, etc. are already delivered via
> ISO/qcow2/etc. images and we'd better stop reinventing a wheel and support
> our own ISO build code. That will allow us to make Fuel admin node
> deployment more flexible.
>
>
>
> I will infrom about our next steps here in the thread.
>
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] PTL non candidacy

[Vladimir Kozhukalov]

Dear colleagues,

Newton cycle is getting to its end and it is time to look at what we've
managed to achieve by the moment.

* Improved task based deployment engine (memory efficiency, code
  structure, graph sequences, noop run).
* Re-implemented OS provisioning as a graph. Now it is one of the graphs in
  the default deployment graph sequence.
* Improved graph API and UX. Now it is possible to upload/download
  custom graphs, run particular graphs, see per-task deployment
  progress.
* Aligned the functionality of the new version of fuelclient with the
  old one. Now all subcommands are available in `fuel2` and we are ready
  to deprecate old `fuel` command.
* We are on our way to get rid of ISO. (ISOless BVT is ready, review
  jobs are in progress).
* Improved LCM UX including IaC (using git repository as a source for
  cluster configuration).
* We begun implementing cluster upgrade procedure as a graph. In the
  future in-place OpenStack cluster upgrades will be a native part Fuel
  functionality.
* We also put some efforts to research container based deployment
  possibilities (K8s and Docker). We introduced a bunch of
  experimental repositories (fuel-ccp-*) where the team is now working
  on CI/CD like UX for containerized OpenStack deployment.

There are also many things that we were planning but didn't manage
to do. I'm not going to nominate myself as a PTL for Ocata cycle, but I'll
continue to contribute to Fuel to make it a perfect deployment
tool and I'm looking forward for other Fuel team members to run for PTL
role.

Thanks.


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

Re: [openstack-dev] [fuel-virtualbox] Nominate Serhii Ovsianikov to fuel-virtualbox core

[Vladimir Kozhukalov]

+1

Vladimir Kozhukalov

On Thu, Sep 8, 2016 at 1:55 AM, Maksim Malchuk <mmalc...@mirantis.com>
wrote:

> Hello,
>
> I would like to nominate Serhii Ovsianikov to fuel-virtualbox core due to
> his significant contribution to the project [1] and [2]. He is the second
> reviewer and for the last half of the year [2] acts as an unoficial QA in
> the fuel-virtualbox project.
>
> [1] http://stackalytics.com/?user_id=sovsianikov_
> type=all=all=marks=fuel-virtualbox
> [2] http://stackalytics.com/report/contribution/fuel-virtualbox/180
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> <vgor...@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] Getting rid of ISO

[Vladimir Kozhukalov]

Dear colleagues,

I'm glad to announce that we have working BVT jobs on Fuel CI that do not
use ISO but instead deploy Fuel admin node from packages onto vanilla
Centos 7.

Please take a look at [1]. There are jobs '10.0.repos.*' [2], [3], [4].

We continue to work on re-implementing review jobs like this one [5] for
example.


[1] https://ci.fuel-infra.org/view/BVT/
[2] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.snapshot/
[3] https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.bvt_2/
[4]
https://ci.fuel-infra.org/view/BVT/job/10.0.repos.main.ubuntu.smoke_neutron/
[5]
https://ci.fuel-infra.org/job/master.fuel-astute.pkgs.ubuntu.review_astute_patched/




Vladimir Kozhukalov

On Thu, Sep 1, 2016 at 1:13 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:

> This is so awesome! Thanks!
>
> On Tue, Aug 16, 2016 at 4:30 PM Jay Pipes <jaypi...@gmail.com> wrote:
>
>> On 08/16/2016 04:58 AM, Vladimir Kozhukalov wrote:
>> > Dear colleagues,
>> >
>> > We finally have working custom deployment job that deploys Fuel admin
>> > node using online RPM repositories (not ISO) on vanilla Centos 7.0.
>>
>> Bravo! :)
>>
>> > Currently all Fuel system and deployment tests use ISO and we are
>> > planning to re-implement all these jobs (including BVT, SWARM, and Fuel
>> > CI jobs) to exclude ISO from the pipeline. That will allow us to get rid
>> > of ISO as our deliverable and instead rely totally on package
>> > repositories. Linux distributions like Ubuntu, Debian, RHEL, etc. are
>> > already delivered via ISO/qcow2/etc. images and we'd better stop
>> > reinventing a wheel and support our own ISO build code. That will allow
>> > us to make Fuel admin node deployment more flexible.
>> >
>> > I will infrom about our next steps here in the thread.
>>
>> Thanks, Vova, this is an excellent step forward for ease-of-use with Fuel.
>>
>> Nice work,
>> -jay
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

[Vladimir Kozhukalov]

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

Re: [openstack-dev] [Fuel][FFE] FF exception for Role Decomposition patch

[Vladimir Kozhukalov]

Thanks for you efforts, FFE is granted, please go ahead. I hope we'll get
it merged by 09/09/2016.

Vladimir Kozhukalov

On Fri, Sep 2, 2016 at 1:02 PM, Dmitry Klenov <dkle...@mirantis.com> wrote:

> Hi Fuelers,
>
> I would like to ask for a FFE for "Role Decomposition" feature. The spec
> is merged and can be fould at [0]. We were unable to land the patch [1] to
> Newton in time. So I would like to ask for extension till 09.09.2016 to
> land this patch.
>
> Changes made in the patch would introduce concept of the tags, which would
> bring additional flexibility into nailgun role system. They are compatible
> with previous role schema so should not introduce regression.
>
> Thanks,
> Dmitry.
> ---
> [0] - https://review.openstack.org/#/c/346248/
> [1] - https://review.openstack.org/#/c/341678/
>
> __
> OpenStack Development Mailing 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] Newton Feature Freeze

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to announce FF for Newton cycle. All features must be merged
before 09/02/2016 12:00 AM PST. From this point all patches must refer to
medium and higher bugs. If some feature patches are still in progress,
please request FF exception for a respective feature.

First such feature that needs FF exception is ISOless test jobs (BVT and
gates). We have not managed to merge and all necessary patches. Since this
feature does not affect the core code of Fuel (but only fuel-qa and jenkins
jobs) I'd like we to continue working on the feature and get it merged by
next Friday 09/09/2016.


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

Re: [openstack-dev] [fuel] Propose Denis Egorenko for fuel-library core

[Vladimir Kozhukalov]

Although I am not a core in fuel-library, I am voting +1.

Vladimir Kozhukalov

On Fri, Aug 26, 2016 at 1:27 PM, Ivan Berezovskiy <iberezovs...@mirantis.com
> wrote:

> +1, great job!
>
> 2016-08-26 10:33 GMT+03:00 Bogdan Dobrelya <bdobre...@mirantis.com>:
>
>> +1
>>
>> On 25.08.2016 21:08, Stanislaw Bogatkin wrote:
>> > +1
>> >
>> > On Thu, Aug 25, 2016 at 12:08 PM, Aleksandr Didenko
>> > <adide...@mirantis.com <mailto:adide...@mirantis.com>> wrote:
>> >
>> > +1
>> >
>> > On Thu, Aug 25, 2016 at 9:35 AM, Sergey Vasilenko
>> > <svasile...@mirantis.com <mailto:svasile...@mirantis.com>> wrote:
>> >
>> > +1
>> >
>> >
>> > /sv
>> >
>> >
>> > ___
>> ___
>> > 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/opensta
>> ck-dev <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://openstack-dev-requ...@lists.openstack.org?
>> subject:unsubscribe>
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> > <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.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>> --
>> Best regards,
>> Bogdan Dobrelya,
>> Irc #bogdando
>>
>> 
>> __
>> 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
>>
>
>
>
> --
> Thanks, Ivan Berezovskiy
> MOS Puppet Team Lead
> at Mirantis <https://www.mirantis.com/>
>
> slack: iberezovskiy
> skype: bouhforever
> phone: + 7-960-343-42-46
>
>
> __
> OpenStack Development Mailing 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] Ocata design summit planning

[Vladimir Kozhukalov]

Dear colleagues,

We are two months from Ocata summit. Let's start planning topics we would
like to discuss during design sessions. Here is etherpad [1]. Please put
your topics under backlog section and we will disscuss later which of them
will be brought out to design sessions.

[1] https://etherpad.openstack.org/p/fuel-ocata-summit-planning


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

Re: [openstack-dev] [fuel] mcollective configuration on slaves

[Vladimir Kozhukalov]

Currently we use /etc/nailgun-agent/nodiscover file to prevent early run of
nailgun-agent (and thus its conflict with cloud-init). We put this file
when we build an image [0] and then we remove this file at the late stage
of system start process when cloud-init is done [1]. Anyway this does not
look good and we'd better replace cloud-init with something else like
puppet and run this configuration during provisioning even before booting
into target operating system. Besides, running Puppet during provisioning
to do initial configuration will allow us to configure other services/files
in a consistent way. So, I prefer option #3. Let's write a spec for this.

[0]
https://github.com/openstack/fuel-agent/blob/master/fuel_agent/manager.py#L961
[1]
https://github.com/openstack/fuel-agent/blob/master/cloud-init-templates/boothook_fuel_9.0_ubuntu.jinja2#L91



Vladimir Kozhukalov

On Fri, Aug 12, 2016 at 8:29 AM, Georgy Kibardin <gkibar...@mirantis.com>
wrote:

> Guys,
>
> Currently, at the time of the first boot Mcollective on slaves is
> configured by Cloud-init (host, port etc.) and by Nailgun agent when node
> identity is written. This happens in any order and already caused several
> problem which were fixed in bounds of https://bugs.launchpad.net/
> fuel/+bug/1455489. The last fix relies on hostname to figure that the
> provisioning is over and prevent Nailgun agent from messing with
> Mcollective. This solution is quite hacky and, I think, we need to come up
> with a better fix. So, the options are:
>
> 1. Do nothing
>   + No effort, no regression
>   - Existing solution is fragile and not simple enough to be sure that
> there are obviously no more bugs.
>   - Cloud-init does things on early boot stages which is a bit hard to
> debug.
>
> 2. "Manual" Mcollective configuration, triggered by Nailgun agent.
>   + Quite simple
>   - Not "cross-distro"
>   - Not consistent with the remaining configuration tasks (rewriting them
> worsens the problem above)
>
> 3. Use Puppet to configure Mcollective. (copy necessary input data into
> the chroot env and run puppet inside it)
>   + Using puppet is consistent with the way Fuel configures things
>   - It is not consistent with remaining configuration tasks, which is done
> via Cloud-init and moving them to Puppet takes some time.
>
> 4. Some other tool?
>
> New options, cons and pros are very welcome!
>
> Best,
> Georgy
>
> __
> OpenStack Development Mailing 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] Getting rid of ISO

[Vladimir Kozhukalov]

Dear colleagues,

We finally have working custom deployment job that deploys Fuel admin node
using online RPM repositories (not ISO) on vanilla Centos 7.0.

Currently all Fuel system and deployment tests use ISO and we are planning
to re-implement all these jobs (including BVT, SWARM, and Fuel CI jobs) to
exclude ISO from the pipeline. That will allow us to get rid of ISO as our
deliverable and instead rely totally on package repositories. Linux
distributions like Ubuntu, Debian, RHEL, etc. are already delivered via
ISO/qcow2/etc. images and we'd better stop reinventing a wheel and support
our own ISO build code. That will allow us to make Fuel admin node
deployment more flexible.

I will infrom about our next steps here in the thread.

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

Re: [openstack-dev] [Fuel] Patches for python-fuelclient are blocked by broken master.python-fuelclient.pkgs.ubuntu.review_fuel_client

[Vladimir Kozhukalov]

We are working on this. Will fix soon.

Vladimir Kozhukalov

On Mon, Aug 8, 2016 at 12:52 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:

> If it’s not possible to fix this job during next few hours, let’s mark in
> as non-voting until the bug(s) are fixed.
>
> > 8 серп. 2016 р. о 11:48 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> >
> > Folks,
> >
> > Since the end of last week 
> > master.python-fuelclient.pkgs.ubuntu.review_fuel_client
> [1] blocks all patches to python-fuelclient. As logs suggest this issue is
> caused by the Xenial merge party.
> >
> > Please resolve the issue ASAP because some folks are blocked and cannot
> finish their jobs in time.
> >
> >
> > 1. https://ci.fuel-infra.org/job/master.python-fuelclient.pkgs.
> ubuntu.review_fuel_client/
> >
> > - romcheg
> >
> >
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] Temporarily unstable Fuel deployment test jobs

[Vladimir Kozhukalov]

Dear colleagues,

Please be informed that we are going to merge some patches on 08/02/2016 to
Fuel repositories to switch from Mitaka to Newton packages. These patches
will likely distabilize Fuel deployment tests for several days. We are
going fix all major features till 08/08/2016 and get these jobs stable
again.

Thanks.


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

Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

[Vladimir Kozhukalov]

>1. Alter the mission statement of fuel to match the reality being

>published by the press and Mirantis's executive team

>2. Include these non-experimental repos in the projects.yaml governance

>Repository

Frankly, I don’t understand what part of the press release contradicts with
Fuel mission.

Current Fuel mission is “To streamline and accelerate the process of
deploying, testing and maintaining various configurations of OpenStack at
scale.” which means we are not bound to any specific technology when
deploying OpenStack.

At the moment Fuel deploys RPM/DEB packages using Puppet and Fuel specific
orchestration mechanism. We are not going to drop this approach
immediately, it works quite well and we are working hard to make things
better (including ability to upgrade). But we also keep in mind that
technologies are constantly changing and we’d like to benefit of this
progress. That is why we are now looking at Docker containers and
Kubernetes. Our users know that it is not our first experience of trying to
use containers. Fuel releases prior to 9.0 used to deploy Fuel services in
containers on the Fuel admin node.

Many of you know how difficult it is to upgrade OpenStack clusters. We hope
that containers could help us to solve not all but some of problems that we
encounter when upgrading cluster. Maintaining and hence upgrade of
OpenStack clusters is a part of Fuel mission and we are just trying to find
a way how to do things.

Why not Kolla but Fuel-ccp? It is not a secret that Fuel is driven by
Mirantis. At Mirantis we deploy and maintain OpenStack. In attempts to find
a way how to make OpenStack easily maintainable, some of Mirantis folks
spent some time to contribute to Kolla and Mesos. But there were some
concerns that were discussed several times (including this Kolla spec
https://review.openstack.org/#/c/330575) that would make it not so easy to
use Kolla containers for our use cases. Fuel-ccp is just an attempt to
address these concerns. Frankly, I don’t see anything bad in having more
than one set of container images (like we have more than one set of RPM/DEB
distributions).

Those concerns are, for example, container images should not be bound to
any specific deployment technology. Containers in some sense are a similar
concept to RPM/DEB packages and it does not matter what deployment tool
(puppet, ansible) one uses to install them. There should be mature CI
pipeline for building/testing/publishing images. There should be a
convenient way (kind of DSL) to deal with dozens of images. I’d like to
avoid discussing this here once again.

Fuel-ccp repositories are public, everyone is welcome to participate. I
don’t see where we violate “4 opens”. These repos are now experimental. At
the moment the team is working on building CI pipeline and developing
functional tests that are to be run as a part of CI process. These repos
are not to be a part of Fuel Newton release. From time to time we add and
retire git repos and it is a part of development process. Not all these
repos are to become a part of Big tent.



Vladimir Kozhukalov

On Thu, Jul 28, 2016 at 7:45 AM, Steven Dake (stdake) <std...@cisco.com>
wrote:

>
>
> On 7/27/16, 2:12 PM, "Jay Pipes" <jaypi...@gmail.com> wrote:
>
> >On 07/27/2016 04:42 PM, Ed Leafe wrote:
> >> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:
> >>
> >>> Its not an "end user" facing thing, but it is an "operator" facing
> >>>thing.
> >>
> >> Well, the end user for Kolla is an operator, no?
> >>
> >>> I deploy kolla containers today on non kolla managed systems in
> >>>production, and rely on that api being consistent.
> >>>
> >>> I'm positive I'm not the only operator doing this either. This sounds
> >>>like a consumable api to me.
> >>
> >> I don¹t think that an API has to be RESTful to be considered an
> >>interface for we should avoid duplication.
> >
> >Application *Programming* Interface. There's nothing that is being
> >*programmed* or *called* in Kolla's image definitions.
> >
> >What Kolla is/has is not an API. As Stephen said, it's more of an
> >Application Binary Interface (ABI). It's not really an ABI, though, in
> >the traditional sense of the term that I'm used to.
> >
> >It's an agreed set of package bases, installation procedures/directories
> >and configuration recipes for OpenStack and infrastructure components.
>
> Jay,
>
> From my perspective, this isn't about ABI proliferation or competition.
> This is about open public discourse.
>
> It is the responsibility of all community members to protect the four
> opens.
>
> Given the intent of fuel-ccp to fully adopt K8S into Fuel described here:
> https://tec

Re: [openstack-dev] [Fuel] Mitaka stable branch

[Vladimir Kozhukalov]

>
> Few Q:
> - Is the stable/mitaka the only stable branch in the scope of the changes?
>
​Yes, this announce is only about Mitaka branch. All other stable branches
are to be treated as usual, i.e. no feature backports, bug fixes only
following "master first" policy, etc.

>
> - As the master and stable/mitaka will diverge, the former might contain
> backwards incompatible changes, ending up the upgrade paths from
> stable/mitaka to future >=10.x releases will likely be *blocked* for its
> life time. Any plans how to address that?
>
> - What about upgrade paths availability from the stable/* branches to:
>   a) stable/mitaka
>   b) future >=10.x releases?
>
> ​Fortunately, Fuel now has nice built-in LCM that allows to run
complicated custom scenarios (including reconfigurations/upgrades of
existent OpenStack clusters). Vladimir Kuklin is working hard on making
this LCM capabilities applicable to cases stable/* -> stable/mitaka. I
believe later we'll be able to implement stable/mitaka -> Newton, etc.

Let's try to imagine we removed old role based serializers from Nailgun in
Newton release. The question is how are we going, for example, to
add/remove nodes to/from Kilo/Liberty clusters. The answer would be we
could add custom task graph and task based deployment engine to modify old
clusters. I'd like Vladimir Kuklin to give some additional details.



>
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] Mitaka stable branch

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to announce some of our plans on how we are going to
support/develop Fuel Mitaka stable branch. The plan is as follows:

0) We have been working hard and have fixed a lot of bugs in Mitaka branch
as for late. This week we are going to announce 9.0.1 release which is
stable and production ready.

1) We are planning to backport onto stable Mitaka branch some (NOT all)
features that are more or less regression safe. All such features will be
thoroughly tested so to avoid lack of stability. Given this we expect
master and stable branches will soon diverge a lot and thus it will soon be
impossible to just cherry-pick  majority of features and bug fixes from
master to stable and instead they often are to be re-implemented. It will
likely require to spend twice as much time as we usually spend for every
change that is to be landed both in master and stable.

2) We are planning to make stable Mitaka branch even more stable and
continue to fix bugs (even medium and low). We are not planning to always
follow Stable Branches policy [1] and backport onto stable Mitaka branch
only those bugs that are already merged to master. Some bugs will be first
merged to stable and then ported to master. It is just for conveniece and
development velocity. Since master and stable will diverge significantly,
it won't make much sense to follow "master first" policy. But still all
bugs that make sense both for master and for stable must be fixed in both
these branches.

3) Since Mitaka branch is expected to stay stable all the time, we are
planning to set release tags (9.x) on stable branch approximately every
month or so. We won't be forced to spend months on code freezing and
stabilizing and thus we will be able to release features frequently (not
all features but those are to be backported onto stable branch).


[1] http://docs.openstack.org/project-team-guide/stable-branches.html


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

Re: [openstack-dev] [Fuel] Deprecation of fuel-mirror tool

[Vladimir Kozhukalov]

Please review this patch [1]. It is to remove the code from master branch.
We still need test jobs for stable branches.

[1] https://review.openstack.org/#/c/335868/

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 1:14 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Fuel-mirror python module itself will be removed from fuel-mirror
> repository, but perestroika is to be there until Packetary is able to
> substitute perestroika totally (work is now in progress).
>
> Just a reminder: According to our plan Packetary is to cover the whole
> rpm/deb domain including building deb/rpm packages and repositories.
> Sincing these repos over multiple locations as well as tracking repository
> snapshots will be a matter of Trsync project (Fuel infra team project).
>
> Vladimir Kozhukalov
>
> On Mon, Jun 27, 2016 at 11:38 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>
>> Vladimir,
>>
>> Thanks for driving this! What about fuel-mirror itself? Does it mean it's
>> deprecated? If so, what will happen to perestroika scripts inside it [1]?
>> It seems strange that fuel-mirror contains them.
>>
>> Thanks,
>> Igor
>>
>> [1] https://github.com/openstack/fuel-mirror/tree/master/perestroika
>>
>>
>> > On Jun 23, 2016, at 13:31, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>> >
>> > Dear colleagues.
>> >
>> > I'd like to announce that fuel-mirror tool is not going to be a part of
>> Fuel any more. Its functionality is to build/clone rpm/deb repos and modify
>> Fuel releases repository lists (metadata).
>> >
>> > Since Fuel 10.0 it is recommended to use other available tools for
>> managing local deb/rpm repositories.
>> >
>> > Packetary is a good example [0]. Packetary is ideal if one needs to
>> create a partial mirror of a deb/rpm repository, i.e. mirror that contains
>> not all available packages but only a subset of packages. To create full
>> mirror it is better to use debmirror or rsync or any other tools that are
>> available.
>> >
>> > To modify releases repository lists one can use commands which are to
>> available by default on the Fuel admin node since Newton.
>> >
>> > # list of available releases
>> > fuel2 release list
>> > # list of repositories for a release
>> > fuel2 release repos list 
>> > # save list of repositories for a release in yaml format
>> > fuel2 release repos list  -f yaml | tee repos.yaml
>> > # modify list of repositories
>> > vim repos.yaml
>> > # update list of repositories for a release from yaml file
>> > fuel2 release repos update  -f repos.yaml
>> >
>> > They are provided by python-fuelclient [1] package and were introduced
>> by this [2] patch.
>> >
>> >
>> > [0] https://wiki.openstack.org/wiki/Packetary
>> > [1] https://github.com/openstack/python-fuelclient
>> > [2] https://review.openstack.org/#/c/326435/
>> >
>> >
>> > Vladimir Kozhukalov
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Deprecate fuel-upgrade repository

[Vladimir Kozhukalov]

Yet another patch [1] that makes fuel-upgrade read only.

[1] https://review.openstack.org/#/c/335841/

Vladimir Kozhukalov

On Wed, Jun 29, 2016 at 6:42 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> This is yet another related patch [1], that removes the code from master
> branch and adds retirement warning. Review is welcome.
>
> [1] https://review.openstack.org/#/c/334949/
>
>
> Vladimir Kozhukalov
>
> On Wed, Jun 29, 2016 at 4:00 PM, Ilya Kharin <ikha...@mirantis.com> wrote:
>
>> Hi Vladimir,
>>
>> This change is reasonable because the fuel-upgrade repository is not
>> supported since the 8.0 release due to the fact that upgrade activities
>> were consolidated in the fuel-octane repository. Also, as I know upgrade
>> tarballs are no longer supported for the old releases (less or equal 7.0).
>>
>> I see only one concern here that it can prevent to create some fixes for
>> upgrade tarballs for old realease. Otherwise I have not any objections to
>> send this repository on the retirement.
>>
>> Best regards,
>> Ilya Kharin.
>>
>> On Tue, Jun 28, 2016 at 6:18 PM Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> This patch [1] is a part of project retirement procedure [2]. Review is
>>> welcome.
>>>
>>> [1] https://review.openstack.org/#/c/335085/
>>> [2]
>>> http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Jun 28, 2016 at 1:41 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
>>>> Dear colleagues,
>>>>
>>>> Please be informed that fuel-upgrade [1] repository is going to be
>>>> deprecated. We used to develop Fuel admin node upgrade scenarios in this
>>>> repo, but now all upgrade related stuff is in fuel-octane [2] repo. So,
>>>> fuel-upgrade is to be removed from the list of official Fuel repos [3].
>>>> Fuel-upgrade will stay available for a while perhaps for about a year or so
>>>> in case some of Fuel users want to build upgrade tarball.
>>>>
>>>>
>>>> [1] https://github.com/openstack/fuel-upgrade
>>>> [2] https://github.com/openstack/fuel-octane
>>>> [3] https://review.openstack.org/#/c/334903/
>>>>
>>>> Vladimir Kozhukalov
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Deprecate fuel-upgrade repository

[Vladimir Kozhukalov]

This is yet another related patch [1], that removes the code from master
branch and adds retirement warning. Review is welcome.

[1] https://review.openstack.org/#/c/334949/


Vladimir Kozhukalov

On Wed, Jun 29, 2016 at 4:00 PM, Ilya Kharin <ikha...@mirantis.com> wrote:

> Hi Vladimir,
>
> This change is reasonable because the fuel-upgrade repository is not
> supported since the 8.0 release due to the fact that upgrade activities
> were consolidated in the fuel-octane repository. Also, as I know upgrade
> tarballs are no longer supported for the old releases (less or equal 7.0).
>
> I see only one concern here that it can prevent to create some fixes for
> upgrade tarballs for old realease. Otherwise I have not any objections to
> send this repository on the retirement.
>
> Best regards,
> Ilya Kharin.
>
> On Tue, Jun 28, 2016 at 6:18 PM Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> This patch [1] is a part of project retirement procedure [2]. Review is
>> welcome.
>>
>> [1] https://review.openstack.org/#/c/335085/
>> [2]
>> http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Jun 28, 2016 at 1:41 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dear colleagues,
>>>
>>> Please be informed that fuel-upgrade [1] repository is going to be
>>> deprecated. We used to develop Fuel admin node upgrade scenarios in this
>>> repo, but now all upgrade related stuff is in fuel-octane [2] repo. So,
>>> fuel-upgrade is to be removed from the list of official Fuel repos [3].
>>> Fuel-upgrade will stay available for a while perhaps for about a year or so
>>> in case some of Fuel users want to build upgrade tarball.
>>>
>>>
>>> [1] https://github.com/openstack/fuel-upgrade
>>> [2] https://github.com/openstack/fuel-octane
>>> [3] https://review.openstack.org/#/c/334903/
>>>
>>> Vladimir Kozhukalov
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Deprecate fuel-upgrade repository

[Vladimir Kozhukalov]

This patch [1] is a part of project retirement procedure [2]. Review is
welcome.

[1] https://review.openstack.org/#/c/335085/
[2] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project

Vladimir Kozhukalov

On Tue, Jun 28, 2016 at 1:41 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> Please be informed that fuel-upgrade [1] repository is going to be
> deprecated. We used to develop Fuel admin node upgrade scenarios in this
> repo, but now all upgrade related stuff is in fuel-octane [2] repo. So,
> fuel-upgrade is to be removed from the list of official Fuel repos [3].
> Fuel-upgrade will stay available for a while perhaps for about a year or so
> in case some of Fuel users want to build upgrade tarball.
>
>
> [1] https://github.com/openstack/fuel-upgrade
> [2] https://github.com/openstack/fuel-octane
> [3] https://review.openstack.org/#/c/334903/
>
> Vladimir Kozhukalov
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Deprecate fuel-upgrade repository

[Vladimir Kozhukalov]

Dear colleagues,

Please be informed that fuel-upgrade [1] repository is going to be
deprecated. We used to develop Fuel admin node upgrade scenarios in this
repo, but now all upgrade related stuff is in fuel-octane [2] repo. So,
fuel-upgrade is to be removed from the list of official Fuel repos [3].
Fuel-upgrade will stay available for a while perhaps for about a year or so
in case some of Fuel users want to build upgrade tarball.


[1] https://github.com/openstack/fuel-upgrade
[2] https://github.com/openstack/fuel-octane
[3] https://review.openstack.org/#/c/334903/

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

Re: [openstack-dev] [Fuel] Replace OSTF with Rally

[Vladimir Kozhukalov]

As far as I understand, Rally is pluggable and one can implement any
scenario we need in pure Python (totally out of Tempest). See for example
[1].


[1] http://rally.readthedocs.io/en/latest/plugins/scenario_plugin.html

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 4:46 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

>
> > On Jun 27, 2016, at 16:23, Alex Schultz <aschu...@mirantis.com> wrote:
> >
> > I thought Rally was more for benchmarking.  Wouldn't Tempest make more
> sense?
>
> According to Rally wiki page [1], it seems they have a verification layer
> (Tempest so far). Hm, I wonder does it mean we will need to rewrite our
> scenarios for Tempest?
>
> - igor
>
>
> [1] https://wiki.openstack.org/wiki/Rally
> __
> OpenStack Development Mailing 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] Replace OSTF with Rally

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to suggest to replace Fuel-ostf with Rally. Rally is quite popular
project and as far as I know it has all necessary features (including
dashboard). We only need to implement testing scenarios.

In particular the suggestion is as follows

1) Implement necessary testing scenarios to achieve feature parity with
Fuel-ostf (including those which test Fuel HA features).
2) Prepare necessary rpm/deb packages (Rally itself + scenarios)
3) Modify Fuel-qa so it uses Rally instead of Fuel-ostf.
4) Deprecate Fuel-ostf (including removal of ostf tab on UI). I'd prefer
Fuel users to rely on Rally user interface (both CLI and dashboard).

What do you think? Are there any volunteers to implement this?


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

Re: [openstack-dev] [Fuel] Deprecation of fuel-mirror tool

[Vladimir Kozhukalov]

Fuel-mirror python module itself will be removed from fuel-mirror
repository, but perestroika is to be there until Packetary is able to
substitute perestroika totally (work is now in progress).

Just a reminder: According to our plan Packetary is to cover the whole
rpm/deb domain including building deb/rpm packages and repositories.
Sincing these repos over multiple locations as well as tracking repository
snapshots will be a matter of Trsync project (Fuel infra team project).

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 11:38 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Vladimir,
>
> Thanks for driving this! What about fuel-mirror itself? Does it mean it's
> deprecated? If so, what will happen to perestroika scripts inside it [1]?
> It seems strange that fuel-mirror contains them.
>
> Thanks,
> Igor
>
> [1] https://github.com/openstack/fuel-mirror/tree/master/perestroika
>
>
> > On Jun 23, 2016, at 13:31, Vladimir Kozhukalov <vkozhuka...@mirantis.com>
> wrote:
> >
> > Dear colleagues.
> >
> > I'd like to announce that fuel-mirror tool is not going to be a part of
> Fuel any more. Its functionality is to build/clone rpm/deb repos and modify
> Fuel releases repository lists (metadata).
> >
> > Since Fuel 10.0 it is recommended to use other available tools for
> managing local deb/rpm repositories.
> >
> > Packetary is a good example [0]. Packetary is ideal if one needs to
> create a partial mirror of a deb/rpm repository, i.e. mirror that contains
> not all available packages but only a subset of packages. To create full
> mirror it is better to use debmirror or rsync or any other tools that are
> available.
> >
> > To modify releases repository lists one can use commands which are to
> available by default on the Fuel admin node since Newton.
> >
> > # list of available releases
> > fuel2 release list
> > # list of repositories for a release
> > fuel2 release repos list 
> > # save list of repositories for a release in yaml format
> > fuel2 release repos list  -f yaml | tee repos.yaml
> > # modify list of repositories
> > vim repos.yaml
> > # update list of repositories for a release from yaml file
> > fuel2 release repos update  -f repos.yaml
> >
> > They are provided by python-fuelclient [1] package and were introduced
> by this [2] patch.
> >
> >
> > [0] https://wiki.openstack.org/wiki/Packetary
> > [1] https://github.com/openstack/python-fuelclient
> > [2] https://review.openstack.org/#/c/326435/
> >
> >
> > Vladimir Kozhukalov
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Thanks everyone for your opinions.

All #fuel-* channels have been notified as deprecated. Now #fuel is our
official and the only channel (updated https://wiki.openstack.org/wiki/IRC).
As for renaming #fuel into #openstack-fuel I think it makes little sense
and not necessary, since some (even core) OpenStack projects don't use
'openstack' prefix. Besides, many Fuel users already got used to #fuel and
deprecating it would introduce extra efforts and inconveniencies.

Vladimir Kozhukalov

On Mon, Jun 27, 2016 at 11:42 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> > On Jun 25, 2016, at 12:39, Roman Prykhodchenko <m...@romcheg.me> wrote:
> >
> > Since Fuel is a part of OpenStack now, should we rename #fuel to
> #openstack-fuel?
> >
> > - romcheg
>
> +1. Let's be consistent in naming convention with most Big Tent projects.
>
> - igor
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Nice. #fuel-infra is to merged as well.

Vladimir Kozhukalov

On Fri, Jun 24, 2016 at 1:50 PM, Aleksandra Fedorova <afedor...@mirantis.com
> wrote:

> And +1 for #fuel-infra
>
> As of now it will be more useful if infra issues related to project will
> be visible for project developers. We don't have much infra-related traffic
> on IRC for now, and we will be able to split again if we got it.
>
> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> We have a few IRC channels but the level of activity there is quite low.
>>
>> #fuel
>> #fuel-dev
>> #fuel-python
>> #fuel-infra
>>
>> My suggestion is to merge all these channels into a single IRC channel
>> #fuel.
>> Other #fuel-* channels are to be deprecated.
>>
>> What do you think of this?
>>
>>
>> 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
>>
>>
>
>
> --
> Aleksandra Fedorova
> Fuel CI Engineer
> bookwar
>
> __
> OpenStack Development Mailing 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] Merge IRC channels

[Vladimir Kozhukalov]

Ok, let's then start from merger of

#fuel-dev
#fuel-python
#fuel-ui
#fuel-library

into a single channel #fuel. #fuel-infra is to stay separate for a while.

Vladimir Kozhukalov

On Fri, Jun 24, 2016 at 1:41 PM, Andrew Maksimov <amaksi...@mirantis.com>
wrote:

> +1 for merging #fuel #fuel-dev #fuel-python and #fuel-library to #fuel.
>
> Not sure about #fuel-infra though, one of the purposes of #fuel-infra -
> support requests to infra team, I think #fuel channel will be too noisy if
> we redirect all support requests to it.
>
> Regards,
> Andrey
>
>
> On Fri, Jun 24, 2016 at 1:26 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> We have a few IRC channels but the level of activity there is quite low.
>>
>> #fuel
>> #fuel-dev
>> #fuel-python
>> #fuel-infra
>>
>> My suggestion is to merge all these channels into a single IRC channel
>> #fuel.
>> Other #fuel-* channels are to be deprecated.
>>
>> What do you think of this?
>>
>>
>> Vladimir Kozhukalov
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Merge IRC channels

[Vladimir Kozhukalov]

Dear colleagues,

We have a few IRC channels but the level of activity there is quite low.

#fuel
#fuel-dev
#fuel-python
#fuel-infra

My suggestion is to merge all these channels into a single IRC channel
#fuel.
Other #fuel-* channels are to be deprecated.

What do you think of this?


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

[openstack-dev] [Fuel] Deprecation of fuel-mirror tool

[Vladimir Kozhukalov]

Dear colleagues.

I'd like to announce that fuel-mirror tool is not going to be a part of
Fuel any more. Its functionality is to build/clone rpm/deb repos and modify
Fuel releases repository lists (metadata).

Since Fuel 10.0 it is recommended to use other available tools for managing
local deb/rpm repositories.

Packetary is a good example [0]. Packetary is ideal if one needs to create
a partial mirror of a deb/rpm repository, i.e. mirror that contains not all
available packages but only a subset of packages. To create full mirror it
is better to use debmirror or rsync or any other tools that are available.

To modify releases repository lists one can use commands which are to
available by default on the Fuel admin node since Newton.

# list of available releases
fuel2 release list
# list of repositories for a release
fuel2 release repos list 
# save list of repositories for a release in yaml format
fuel2 release repos list  -f yaml | tee repos.yaml
# modify list of repositories
vim repos.yaml
# update list of repositories for a release from yaml file
fuel2 release repos update  -f repos.yaml

They are provided by python-fuelclient [1] package and were introduced by
this [2] patch.


[0] https://wiki.openstack.org/wiki/Packetary
[1] https://github.com/openstack/python-fuelclient
[2] https://review.openstack.org/#/c/326435/


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

[openstack-dev] [Fuel] Pinning upstream puppet modules

[Vladimir Kozhukalov]

Dear colleagues,

We are approaching 9.0.1 release and for higher level of stability we are
going to pin [1] upstream puppet modules temporarily. Once 9.0.1 tag is
created we will unpin upstream to make it possible to get upstream fixes.

[1] https://review.openstack.org/#/c/325807/


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

Re: [openstack-dev] [Fuel] Fuel - Rack Scale Architecture integration

[Vladimir Kozhukalov]

Absolutely agree with Jay. Fuel is a community project.
Please keep discussion public including technical details.

Anyway, integration is welcome, please go ahead and
create BP (btw, spec review request is the best place to
discuss technical details).


Vladimir Kozhukalov

On Fri, May 13, 2016 at 4:43 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> On 05/13/2016 07:26 AM, Andrian Noga wrote:
>
>> Hi Deepti,
>>
>> We have already a vision about Fuel-UI implementation for RSA.
>>
>> I've replied already to you in private email.
>>
>> Let's continue this thread in private conversation.
>>
>
> Please, no.
>
> Fuel is an OpenStack Big Tent project. The Fuel roadmap, feature set, and
> development MUST be discussed in public channels. If not, then Fuel does
> not meet one of the requirements for being in the OpenStack Big Tent, which
> is that the project will abide by the four Opens of OpenStack:
>
> https://wiki.openstack.org/wiki/Open
>
> Please note that Open Design, Open Community and Open Development mean
> that communication about the Fuel roadmap and development must be done on
> public mailing lists and discussion areas. This is a non-negotiable
> condition for being a member project in OpenStack's Big Tent.
>
> Thanks,
> -jay
>
> On Fri, May 13, 2016 at 2:08 PM, <deepti.ramakris...@intel.com
>> <mailto:deepti.ramakris...@intel.com>> wrote:
>>
>> Hello Fuel team,
>>
>> I am a software engineer working in the OpenStack team at Intel. You
>> may have heard of Rack Scale Architecture [1] that Intel is
>> pioneering. It is a new data center architecture that "simplifies
>> resource management and provides the ability to dynamically compose
>> resources based on workload-specific demands". It is supported by
>> multiple industry partners.
>>
>> We would like to propose Fuel integration with this. The first step
>> would be UI integration [2] and we would like to have a tab similar
>> to the VMWare tab (whose visibility is controlled by a config flag)
>> that talks to the Redfish API [3] for displaying resources such as
>> pods, racks, etc as exposed by this API. Note that Redfish API is an
>> open industry standard API supported by multiple companies.
>>
>> I plan to write up a blueprint/spec for the same, but I wanted to
>> know if there is any immediate feedback on this idea before I even
>> get started.
>>
>> Thanks,
>> Deepti
>>
>> [1]
>>
>> http://www.intel.com/content/www/us/en/architecture-and-technology/intel-rack-scale-architecture.html
>> [2] http://i.imgur.com/vLJIbwx.jpg
>> [3] https://www.dmtf.org/standards/redfish
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing 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] Newton Design Summit sessions planning

[Vladimir Kozhukalov]

​Done.

Wed 11:00-11:40 Finalizing of HA reference architecture with event-based
control and fencing
Thu 11:00-11:40 Fuel UI Modularization approaches discussion

Vladimir Kozhukalov

On Mon, Apr 25, 2016 at 10:14 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> Fuelers
>
> I am OK with the proposed change
> 21 апр. 2016 г. 12:34 пользователь "Vitaly Kramskikh" <
> vkramsk...@mirantis.com> написал:
>
> Folks,
>>
>> I'd like to request workroom sessions swap.
>>
>> I planned to lead a discussion of Fuel UI modularization on Wed
>> 11.00-11.40, but at the same time there will be discussion of handling JS
>> dependencies of Horizon which I'd really like to attend.
>>
>> So I request to swap my discussion with discussion of finalizing of HA
>> reference architecture with event-based control and fencing led by V.
>> Kuklin on Thu 11.00-11.40.
>>
>> Do you have any objections?
>>
>> 2016-04-14 17:55 GMT+03:00 Alexey Shtokolov <ashtoko...@mirantis.com>:
>>
>>> Hi, +1 from my side.
>>>
>>> ---
>>> WBR, Alexey Shtokolov
>>>
>>> 2016-04-14 16:47 GMT+03:00 Evgeniy L <e...@mirantis.com>:
>>>
>>>> Hi, no problem from my side.
>>>>
>>>> On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov <
>>>> vkozhuka...@mirantis.com> wrote:
>>>>
>>>>> Dear colleagues,
>>>>>
>>>>> I'd like to request workrooms sessions swap.
>>>>>
>>>>> We have a session about Fuel/Ironic integration and I'd like
>>>>> this session not to overlap with Ironic sessions, so Ironic
>>>>> team could attend Fuel sessions. At the same time, we have
>>>>> a session about orchestration engine and it would be great to
>>>>> invite there people from Mistral and Heat.
>>>>>
>>>>> My suggestion is as follows:
>>>>>
>>>>> Wed:
>>>>> 9:50 Astute -> Mistral/Heat/???
>>>>> Thu:
>>>>> 9.00 Fuel/Ironic/Ironic-inspector
>>>>>
>>>>> If there are any objections, please let me know asap.
>>>>>
>>>>>
>>>>>
>>>>> Vladimir Kozhukalov
>>>>>
>>>>> On Fri, Apr 1, 2016 at 9:47 PM, Vladimir Kozhukalov <
>>>>> vkozhuka...@mirantis.com> wrote:
>>>>>
>>>>>> Dear colleagues,
>>>>>>
>>>>>> Looks like we have final version sessions layout [1]
>>>>>> for Austin design summit. We have 3 fishbows,
>>>>>> 11 workrooms, full day meetup.
>>>>>>
>>>>>> Here you can find some useful information about design
>>>>>> summit [2]. All session leads must read this page,
>>>>>> be prepared for their sessions (agenda, slides if needed,
>>>>>> etherpads for collaborative work, etc.) and follow
>>>>>> the recommendations given in "At the Design Summit" section.
>>>>>>
>>>>>> Here is Fuel session planning etherpad [3]. Almost all suggested
>>>>>> topics have been put there. Please put links to slide decks
>>>>>> and etherpads next to respective sessions. Here is the
>>>>>> page [4] where other teams publish their planning pads.
>>>>>>
>>>>>> If session leads want for some reason to swap their slots it must
>>>>>> be requested in this ML thread. If for some reason session lead
>>>>>> can not lead his/her session, it must be announced in this ML thread.
>>>>>>
>>>>>> Fuel sessions are:
>>>>>> ===
>>>>>> Fishbowls:
>>>>>> ===
>>>>>> Wed:
>>>>>> 15:30-16:10
>>>>>> 16:30:17:10
>>>>>> 17:20-18:00
>>>>>>
>>>>>> ===
>>>>>> Workrooms:
>>>>>> ===
>>>>>> Wed:
>>>>>> 9:00-9:40
>>>>>> 9:50-10:30
>>>>>> 11:00-11:40
>>>>>> 11:50-12:30
>>>>>> 13:50-14:30
>>>>>> 14:40-15:20
>>>>>> Thu:
>>>>>> 9:00-9:40
>>>>>> 9:50-10:30
>>>>>> 11:00-11:40
>>>>>> 11:50-12:30
>>>>>> 13:30-14:10
>>>>>

[openstack-dev] [Fuel] Fuel 9.0 is released

[Vladimir Kozhukalov]

Dear all,

I am glad to announce Mitaka release of Fuel (a.k.a Fuel 9.0) - deployment

and lifecycle management tool for OpenStack.

This release introduces support for OpenStack Mitaka and adds

a number of new features and enhancements.

Some highlights:
- Support lifecycle management operations (a.k.a ‘day 2’ operations).
Now cluster settings tab on UI is unlocked after deployment
(cluster configuration could be changed). [1]
- Support of custom deployment graphs. Default deployment graph
could be overridden either by plugins or by a user. [2]
- Support of DPDK capabilities [3]
- Support of Huge Pages capabilities [4]
- Support of CPU pinning (NUMA) capabilities [5]
- Support of QoS capabilities [6]
- Support of SR-IOV capabilities [7]
- Support of multipath devices [8]
- Support of deployment using UCA packages [9]

Please be aware that it is not intended for production use and

there are still about 90 known High bugs [10]. We are planning

to address them all in Fuel 9.0.1 release which is scheduled

for late June [11].

We are looking forward to your feedback.
Great work, Fuel team. Thanks to everyone.

[1]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/unlock-settings-tab.rst

[2]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/execute-custom-graph.rst

[1]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-dpdk.rst


[3]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/execute-custom-graph.rst
[4]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-hugepages.rst
[5]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-numa-cpu-pinning.rst
[6]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-qos.rst
[7]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/support-sriov.rst
[8]
https://github.com/openstack/fuel-specs/blob/master/specs/9.0/fc-multipath-disks.rst
[9] https://blueprints.launchpad.net/fuel/+spec/deploy-with-uca-packages

[10] https://goo.gl/qXfrhQ

[11] https://wiki.openstack.org/wiki/Fuel/9.0_Release_Schedule


Learn more about Fuel:
https://wiki.openstack.org/wiki/Fuel

How we work:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute

Specs for features in 9.0 and other Fuel releases:
http://specs.openstack.org/openstack/fuel-specs/

ISO image:
http://seed.fuel-infra.org/fuelweb-community-release/fuel-community-9.0.iso.torrent

Test results of the release build:
https://ci.fuel-infra.org/job/9.0-community.test_all/61/

Documentation:
http://docs.openstack.org/developer/fuel-docs/


RPM packages:
http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7/

DEB packages:
http://mirror.fuel-infra.org/mos-repos/ubuntu/9.0/

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

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

[Vladimir Kozhukalov]

Colleagues,

Whether we are going to continue using Shotgun or
substitute it with something else, we still need to
decouple it from Fuel because Shotgun is a generic
tool. Please review these [1], [2].

[1] https://review.openstack.org/#/c/298603
[2] https://review.openstack.org/#/c/298615


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

Vladimir Kozhukalov

On Thu, Mar 31, 2016 at 1:32 PM, Evgeniy L <e...@mirantis.com> wrote:

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

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

[Vladimir Kozhukalov]

Dear colleagues,

Looks like we have consensus (lazy, but still consensus)
on this topic: we don't need this role CL exposed to Fuel
project. I have prepared a change [1] for our team structure
policy.

My suggestion is to make Fuel is an aggregator
of independent components. Component teams could have their
formal or informal leads (i.e. component PTL) if needed
but it is irrelevant to Fuel as a whole.

As far as Fuel features usually require coordinated changes
in multiple components, we need all Fuel specs to be reviewed
by engineers from different backgrounds.

"Avengers" approach (described above) has been rejected
by Openstack Infra team, but we can use more traditional
core group approach. I.e. Fuel-specs core team is responsible for
reviewing and merging specs and in the proposed patch [1]
it is explicitly written down that each spec must be
approved by at least Puppet, UI, REST SMEs.
It is also a responsibility of Fuel-specs core group
to involve other SMEs if needed.

[1] https://review.openstack.org/#/c/301194/



Vladimir Kozhukalov

On Thu, Mar 31, 2016 at 6:47 PM, Serg Melikyan <smelik...@mirantis.com>
wrote:

> Hi fuelers,
>
> only few hours left until period of self-nomination will be closed, but so
> far we don't have neither consensus regarding how to proceed further nor
> candidates.
>
> I've increased period of self-nomination for another week (until April 7,
> 23:59 UTC) and expect to have decision about how we are going to proceed
> further if no one nominate himself or candidates for each of the three
> projects.
>
> I propose to start with defining steps that we are going to take if no one
> nominate himself by April 7 and move forward with separate discussion
> regarding governance.
>
> P.S. I strongly believe that declaring Component Leads role as obsolete
> require agreement among all members of Fuel team, which may take quite a
> lot of time. I think we should propose change-request to existing spec with
> governance [0], and have decision by end of Newton cycle.
>
> References:
> [0]
> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
>
> On Thu, Mar 31, 2016 at 3:22 AM, Evgeniy L <e...@mirantis.com> wrote:
>
>> Hi,
>>
>> I'm not sure if it's a right place to continue this discussion, but if
>> there are doubts that such role is needed, we should not wait for another
>> half a year to drop it.
>>
>> Also I'm not sure if a single engineer (or two engineers) can handle
>> majority of upcoming patches + specs + meetings around features. Sergii and
>> Igor put a lot of efforts to make it work, but does it really scale?
>>
>> I think it would be better to offload more responsibilities to core
>> groups, and if core team (of specific project) wants to see formal or
>> informal leader, let them decide.
>>
>> I would be really interested to see feedback from current component leads.
>>
>> Thanks,
>>
>>
>> On Wed, Mar 30, 2016 at 2:20 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Dmitry,
>>>
>>> "No need to rush" does not mean we should postpone
>>> team structure changes until Ocata. IMO, CL role
>>> (when it is exposed to Fuel) contradicts to our
>>> modularization activities. Fuel should be an aggregator
>>> of components. What if we decide to use Ironic or
>>> Neutron as Fuel components? Should we chose also
>>> Ironic CL? NO! Ironic is an independent
>>> project with its own PTL.
>>>
>>> I agree with Mike that we could remove this CL
>>> role in a month if have consensus. But does it
>>> make any sense to chose CLs now and then
>>> immediately remove this role? Probably, it is better
>>> to make a decision right now. I'd really like to
>>> see here in this ML thread opinions of our current
>>> CLs and other people.
>>>
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
>>> dborodae...@mirantis.com> wrote:
>>>
>>>> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
>>>> > > I think this call is too late to change a structure for now. I
>>>> suggest
>>>> > > that we always respect the policy we've accepted, and follow it.
>>>> > >
>>>> > > If Component Leads role is under a question, then I'd continue the
>>>> > > discussion, hear opinion of current component leads, and give this
>>>> a time
>>>> > > to be discussed. I'd have nothing against rem

[openstack-dev] [Fuel] 9.0 Soft Code Freeze

[Vladimir Kozhukalov]

Dear colleagues,

Soft Code Freeze [1] for Fuel 9.0 release is in action.

Infra team will shortly declare merge freeze and create stable/9.0
branches in all necessary git repositories. Once it is done
master branches will be open for Newton development cycle.

Branches stable/9.0 must adopt only fixes for High and Critical
bugs. Backporting procedure is described here [2].

[1] https://wiki.openstack.org/wiki/Fuel/Soft_Code_Freeze
[2]
https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Backport_bugfixes_to_stable_release_series


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

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

[Vladimir Kozhukalov]

Dear colleagues,

Looks like we have final version sessions layout [1]
for Austin design summit. We have 3 fishbows,
11 workrooms, full day meetup.

Here you can find some useful information about design
summit [2]. All session leads must read this page,
be prepared for their sessions (agenda, slides if needed,
etherpads for collaborative work, etc.) and follow
the recommendations given in "At the Design Summit" section.

Here is Fuel session planning etherpad [3]. Almost all suggested
topics have been put there. Please put links to slide decks
and etherpads next to respective sessions. Here is the
page [4] where other teams publish their planning pads.

If session leads want for some reason to swap their slots it must
be requested in this ML thread. If for some reason session lead
can not lead his/her session, it must be announced in this ML thread.

Fuel sessions are:
===
Fishbowls:
===
Wed:
15:30-16:10
16:30:17:10
17:20-18:00

===
Workrooms:
===
Wed:
9:00-9:40
9:50-10:30
11:00-11:40
11:50-12:30
13:50-14:30
14:40-15:20
Thu:
9:00-9:40
9:50-10:30
11:00-11:40
11:50-12:30
13:30-14:10

===
Meetup:
===
Fri:
9:00-12:30
14:00-17:30

[1]
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/d59d38b7/attachment.pdf
[2] https://wiki.openstack.org/wiki/Design_Summit
[3] https://etherpad.openstack.org/p/fuel-newton-summit-planning
[4] https://wiki.openstack.org/wiki/Design_Summit/Planning

Thanks.

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

Re: [openstack-dev] [Fuel] [RDO] Volunteers needed

[Vladimir Kozhukalov]

Aleksandra,

You are right, we need to split this task into several
smaller work items. For the start, I have created BP [1].
Let's discuss this on Fuel IRC meeting [2] today. I have
put this topic to the agenda.

And this is a great idea to put this task into the list
for interns. I'll certainly do this.

[1] https://blueprints.launchpad.net/fuel/+spec/deploy-rdo-using-fuel
[2] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda


Vladimir Kozhukalov

On Wed, Mar 30, 2016 at 8:41 PM, Aleksandra Fedorova <afedor...@mirantis.com
> wrote:

> Hi, Vladimir,
>
> this is a great feature, which can make Fuel truly universal. But i
> think it is hard to fully commit to the whole thing at once,
> especially for new contributors.
>
> Let's start with splitting it into some observable chunks of work, in
> a form of wiki page, blueprint or spec. This way it will become
> visible - where to start and how much effort it would take.
>
> Also, do you think it fits into Internship ideas [1] ?
>
> [1] https://wiki.openstack.org/wiki/Internship_ideas
>
>
> On Tue, Mar 29, 2016 at 3:48 PM, Vladimir Kozhukalov
> <vkozhuka...@mirantis.com> wrote:
> > Dear all,
> >
> > Fuel currently supports deployment of OpenStack using DEB packages
> > (particularly Ubuntu, and Debian in near future). But we also used to
> deploy
> > OpenStack on CentOS, but at some point we switched our focus on Ubuntu.
> It
> > is not so hard to implement deployment of RDO using Fuel. Volunteers are
> > welcome. You can contact Fuel team here in [openstack-dev] maling list
> or in
> > #fuel IRC channel. It would be nice to see more people from different
> > backgrounds contributing to Fuel.
> >
> >
> > 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
> >
>
>
>
> --
> Aleksandra Fedorova
> CI Team Lead
> bookwar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

​Igor,

I can not agree more. Wherever possible we should
use existent mature solutions. Ansible is really
convenient and well known solution, let's try to
use it.

Yet another thing should be taken into account.
One of Shotgun features is diagnostic report
that could then be attached to bugs to identify
the content of env. This report could also be
used to reproduce env and then fight a bug.
I'd like we to have this kind of report.
Is it possible to implement such a feature
using Ansible? If yes, then let's switch to Ansible
as soon as possible.

​

Vladimir Kozhukalov

On Wed, Mar 30, 2016 at 3:31 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Neil Jerram wrote:
> > But isn't Ansible also over-complicated for just running commands over
> SSH?
>
> It may be not so "simple" to ignore that. Ansible has a lot of modules
> which might be very helpful. For instance, Shotgun makes a database
> dump and there're Ansible modules with the same functionality [1].
>
> Don't think I advocate Ansible as a replacement. My point is, let's
> think about reusing ready solutions. :)
>
> - igor
>
>
> [1]: http://docs.ansible.com/ansible/list_of_database_modules.html
>
> On Wed, Mar 30, 2016 at 1:14 PM, Neil Jerram <neil.jer...@metaswitch.com>
> wrote:
> >
> > FWIW, as a naive bystander:
> >
> > On 30/03/16 11:06, Igor Kalnitsky wrote:
> >> Hey Fuelers,
> >>
> >> I know that you probably wouldn't like to hear that, but in my opinion
> >> Fuel has to stop using Shotgun. It's nothing more but a command runner
> >> over SSH. Besides, it has well known issues such as retrieving remote
> >> directories with broken symlinks inside.
> >
> > It makes sense to me that a command runner over SSH might not need to be
> > a whole Fuel-specific component.
> >
> >> So I propose to find a modern alternative and reuse it. If we stop
> >> supporting Shotgun, we can spend extra time to focus on more important
> >> things.
> >>
> >> As an example, we can consider to use Ansible. It should not be tricky
> >> to generate Ansible playbook instead of generating Shotgun one.
> >> Ansible is a  well known tool for devops and cloud operators, and they
> >> we will only benefit if we provide possibility to extend diagnostic
> >> recipes in usual (for them) way. What do you think?
> >
> > But isn't Ansible also over-complicated for just running commands over
> SSH?
> >
> > Neil
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Dmitry,

"No need to rush" does not mean we should postpone
team structure changes until Ocata. IMO, CL role
(when it is exposed to Fuel) contradicts to our
modularization activities. Fuel should be an aggregator
of components. What if we decide to use Ironic or
Neutron as Fuel components? Should we chose also
Ironic CL? NO! Ironic is an independent
project with its own PTL.

I agree with Mike that we could remove this CL
role in a month if have consensus. But does it
make any sense to chose CLs now and then
immediately remove this role? Probably, it is better
to make a decision right now. I'd really like to
see here in this ML thread opinions of our current
CLs and other people.



Vladimir Kozhukalov

On Tue, Mar 29, 2016 at 11:21 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:

> On Tue, Mar 29, 2016 at 03:19:27PM +0300, Vladimir Kozhukalov wrote:
> > > I think this call is too late to change a structure for now. I suggest
> > > that we always respect the policy we've accepted, and follow it.
> > >
> > > If Component Leads role is under a question, then I'd continue the
> > > discussion, hear opinion of current component leads, and give this a
> time
> > > to be discussed. I'd have nothing against removing this role in a month
> > > from now if we reach a consensus on this topic - no need to wait for
> the
> > > cycle end.
> >
> > Sure, there is no need to rush. I'd also like to see current CL opinions.
>
> Considering that, while there's an ongoing discussion on how to change
> Fuel team structure for Ocata, there's also an apparent consensus that
> we still want to have component leads for Newton, I'd like to call once
> again for volunteers to self-nominate for component leads of
> fuel-library, fuel-web, and fuel-ui. We've got 2 days left until
> nomination period is over, and no volunteer so far :(
>
> --
> Dmitry Borodaenko
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Austin Design Summit track layout

[Vladimir Kozhukalov]

On Wed, Mar 30, 2016 at 11:01 AM, Thierry Carrez 
wrote:

> John Dickinson wrote:
>
>> On Thursday, I'd like to proposed swapping Swift's 1:30pm session with
>> Fuel's 2:20pm session. This will give Swift a contiguous time block in the
>> afternoon, and Fuel's session would line up right after their full morning
>> (albeit after the lunch break).
>>
>> I have not had a chance to talk to anyone on the Fuel team about this.
>>
>
> John,
>
> You are giving a conference talk at 2:20pm on Thursday, which is why I
> left that as a hole in the Swift Design Summit schedule.
>
> Swapping is definitely possible, but I figured you would not intentionally
> create a conflict for you here ?


​It is ok for us to swap these two slots.
__
OpenStack Development Mailing 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] Component based testing pipeline

[Vladimir Kozhukalov]

Dear colleagues,

I have prepared a document [1] that describes some aspects
of possible testing pipeline in a component based
development environment. The main idea of the proposed
pipeline is to untie two steps:

1) Merge the code to git
2) Adopt changes to Fuel

By that I mean Fuel should be an aggregator of
RPM/DEB packages not of source code. We can merge
the code that successfully passes unit and functional tests.
Then we build package, but we don't put this package into
current master package repository. Then we use those packages
to run integration tests and if integration test succeeds,
get this package (not re-building it) and put it into the
current master package repo.

Feel free to leave your comments.


[1]
https://docs.google.com/document/d/1Yp63s3ctO0FNRhqrWNpLmXxMOaJT2tb8H0W80Jr_kjM

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

[openstack-dev] [Fuel] [RDO] Volunteers needed

[Vladimir Kozhukalov]

Dear all,

Fuel currently supports deployment of OpenStack using DEB packages
(particularly Ubuntu, and Debian in near future). But we also used to
deploy OpenStack on CentOS, but at some point we switched our focus on
Ubuntu. It is not so hard to implement deployment of RDO using Fuel.
Volunteers are welcome. You can contact Fuel team here in [openstack-dev]
maling list or in #fuel IRC channel. It would be nice to see more people
from different backgrounds contributing to Fuel.


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

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

[Vladimir Kozhukalov]

nto work, to
> ensure that enough time is dedicated to code review and other activities.
>

​Nope. A component team makes decisions (consensus). If a team wants to
delegate their voice to a particular person (a member of the team), it is
ok. Consensus is a sum of arguments, not a sum of opinions. Opinions could
depend on many things (including salary, career). What you are describing
is a manager role. And it is ok to have managers (fuel-web or fuel-ui
manager) who help to coordinate resources. I'm only against this practice
of exposing enterprise roles to the community.


>
> Thanks,
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
> [2]
> https://github.com/openstack/governance/blob/master/reference/projects.yaml#L593
> [3]
> https://github.com/openstack/fuel-specs/blob/master/policy/team-structure.rst#code-review-workflow
>
> Thanks,
>
> On Fri, Mar 25, 2016 at 9:10 AM Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear all,
>>
>> Let me raise my hand here. We introduced this role CL a while ago for two
>> major reasons:
>>  1) improve review process (CL are responsible for review SLA)
>>  2) introduce review of overall architecture and avoid cross-feature,
>> cross-component conflicts.
>> These two points, in fact, mean the following:
>>  1) CL ask other developers (including cores) to help to review patches
>> if there any that did not get enough attention
>>  2) CL spend 50% of their time reviewing specs and we don't merge specs
>> w/o their +2
>>
>> I think that is not exactly what we meant. Our CL role is rather a
>> mixture of a manager and an architect. Both these roles are enterprise
>> roles. I think in community having Core Reviewers is more than enough.
>>
>> Real motivation (salary, career, etc.) of a particular contributor should
>> NOT be a matter of community. If a particular manager wants to have a
>> person who is to be responsible for asking people to review patches, then
>> it is a matter of this manager to motivate a particular person. In
>> community a team of core reviewers is responsible for review, not a person.
>>
>> To prevent cross-feature and cross-component conflicts we can use CI gate
>> that will put -1 to a spec that is merged without necessary +2 from trusted
>> people from various components. For example, we could create a yaml file
>>
>> avengers:
>>   fuel-web:
>> Hawkeye
>> Captain America
>>   fuel-ui:
>> Black Widow
>>   fuel-library
>> Hulk
>> Ironman
>>
>> and CI gate will check if there is +2 from at least one superhero from
>> every project and fail if not. Superheros should be volunteers (no matter
>> what their real motivation is).
>>
>> I propose to get rid of official CL role in Fuel. Instead it should be
>> totally up to a particular component team to decide if they want CL or
>> other roles. What do you guys think?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> Serg,
>>>
>>> Thanks for agreeing to officiate this cycle's component lead elections
>>> for us!
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>>
>>> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:
>>> > Hi folks,
>>> >
>>> > I'd like to announce that we're running the Component Leads elections.
>>> > Detailed information is available on wiki [0].
>>> >
>>> > Component Lead: defines architecture of a particular module or
>>> > component in Fuel, resolves technical disputes in their area of
>>> > responsibility. All design specs that impact a component must be
>>> > approved by the corresponding component lead [1].
>>> >
>>> > Fuel has three large sub-teams, with roughly comparable codebases,
>>> > that need dedicated component leads:
>>> >
>>> > * fuel-library
>>> > * fuel-web
>>> > * fuel-ui
>>> >
>>> > Nominees propose their candidacy by sending an email to the
>>> > openstack-dev@lists.openstack.org mailing-list, with the subject:
>>> > "[fuel]  lead candidacy"
>>> > (for example, "[fuel] fuel-library lead candidacy").
>>> >
>>> > Timeline:
>&

Re: [openstack-dev] [Fuel] FFE request for ConfigDB service

[Vladimir Kozhukalov]

Oleg and team,

Thanks very much for your efforts to make this happened. I'm sure this
experience will help us to implement thorough "Day 2" maintenance flow in
future Fuel releases.



Vladimir Kozhukalov

On Tue, Mar 29, 2016 at 12:06 PM, Oleg Gelbukh <ogelb...@mirantis.com>
wrote:

> Greetings,
>
> Please, be informed that the source code of Nailgun API extension has
> landed to the designated repository [1]. Project was code named
> 'tuning-box'. We are working to integrate it into the build and testing
> systems provided by Fuel infra. I suggest that the FFE can be closed.
>
> I'd like to thank the community for the trust you've put in us. Hope we
> laid a foundation for more flexible and modular architecture for the future
> Fuel versions.
>
> Sorry for the delay with this heads up.
>
> [1] https://git.openstack.org/openstack/tuning-box.git
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, Mar 4, 2016 at 12:27 AM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> Granted, merge deadline March 24, no impact expected in core components
>> (fuel-library, fuel-web, fuel-ui).
>>
>> --
>> Dmitry Borodaenko
>>
>>
>> On Tue, Mar 01, 2016 at 04:22:05PM +0300, Oleg Gelbukh wrote:
>> > Greetings,
>> >
>> > As you might know, we are working on centralised storage for
>> > deployment configuration data in Fuel. Such store will allow external
>> > 3rd-party services to consume the entirety of settings provided by
>> > Fuel to deployment mechanisms on target nodes. It will also allow to
>> > manage and override the settings via simple client application.
>> >
>> > This change is required to enable Puppet Master based LCM solution.
>> >
>> > We request a FFE for this feature for 3 weeks, until Mar 24. By that
>> > time, we will provide tested solution in accordance with the following
>> > specifications [1] [2]
>> >
>> > The feature includes 3 main components:
>> > 1. Extension to Nailgun API with separate DB structure to store
>> serialized data
>> > 2. Backend library for Hiera to consume the API in question to lookup
>> > values of the certain parameters
>> > 3. Astute task to download all serialized data from nodes and upload
>> > them to ConfigDB API upon successful deployment of cluster
>> >
>> > Since introduction of stevedore-based extensions [3], we could develop
>> > extensions in separate code repos. This makes change to Nailgun
>> > non-intrusive to core code.
>> > Backend library will be implemented in fuel-library code tree and
>> > packaged as a sub-package. This change also doesn't require changes in
>> > the core code.
>> > Astute task will add a task in the flow. We will make this task
>> > configurable, i.e. normally this code path won't be used at all. It
>> > also won't touch core code of Astute.
>> >
>> > Overall, I consider this change as low risk for integrity and timeline
>> > of the release.
>> >
>> > Please, consider our request and share concerns so we could properly
>> > resolve them.
>> >
>> > [1]
>> https://blueprints.launchpad.net/fuel/+spec/upload-deployment-facts-to-configdb
>> > [2]
>> https://blueprints.launchpad.net/fuel/+spec/serialized-facts-nailgun-api
>> > [3]
>> https://blueprints.launchpad.net/fuel/+spec/stevedore-extensions-discovery
>> >
>> > --
>> > Best regards,
>> > Oleg Gelbukh
>> > 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
>
>
__
OpenStack Development Mailing 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] [Shotgun] Decoupling Shotgun from Fuel

[Vladimir Kozhukalov]

Dear colleagues,

This is a part of our plan to make Fuel even more modular.

Governance patch: https://review.openstack.org/#/c/298603/
Project-config patch: https://review.openstack.org/#/c/298615/
Launchpad project: https://launchpad.net/shotgun
Wiki page: https://wiki.openstack.org/wiki/Shotgun

If we have a consensus here and merge these
governance and project-config patches (not earlier than Fuel 9.0 SCF),
all new bug reports should be sent to https://bugs.launchpad.net/shotgun
Yet another thing is that Shotgun roadmap and releases will
be up to a Shotgun independent team.

BTW, volunteers are needed to drive Shotgun project. We need to inspect
its possible use cases, we should make it even more generic, convenient
and well documented. We also need to figure out what
we can improve in the project and how and then create roadmap.


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

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

[Vladimir Kozhukalov]

​Guys, you are awesome. Thank you all very much.​

Vladimir Kozhukalov

On Mon, Mar 28, 2016 at 11:50 PM, Alexey Shtokolov <ashtoko...@mirantis.com>
wrote:

> Fuelers!
>
> I'm glad to announce that all patches [0] were merged!
>
> Many thanks to all of you who help us to make Fuel more flexible and
> unlimited.
>
> Special thanks to our code and design reviewers: Igor Kalnitsky, Sergii
> Golovatiuk, Vitaly Kramskikh.
>
> And especially to the Team: Bulat Gaifullin, Ilya Kutukov, Vladimir
> Sharshov, Julia Aranovich, Stanislaw Bogatkin, Evgeniy L and Vladimir Kuklin
> My sincerest thanks and appreciation for your great efforts, sleepless
> nights and sense of purpose!
>
> WBR, Alexey Shtokolov
>
> [0] - https://goo.gl/kSwej5
>
> 2016-03-25 21:48 GMT+03:00 Vladimir Kozhukalov <vkozhuka...@mirantis.com>:
>
>> Granted. New deadline is 21:00 UTC 03/28/2016.
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov <
>> ashtoko...@mirantis.com> wrote:
>>
>>> Fuelers!
>>>
>>>
>>> We are very close to landing our feature "Unlock Settings Tab". But we
>>> still have a set of reviews [0] to be merged due to several reasons (incl.
>>> the migration to python27-db gates on OpenStack Infra). I would like to
>>> request extra time till Monday to land them.
>>>
>>>
>>> [0] - https://goo.gl/kSwej5
>>>
>>> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko <dborodae...@mirantis.com>:
>>>
>>>> Thanks for working this out! Confirming that task history remains
>>>> included in the scope of this FFE until the merge deadline, March 24.
>>>>
>>>> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
>>>> > Hey Dmitry,
>>>> >
>>>> > I confirm that we agreed on feature design, and you can proceed with
>>>> > granting exception.
>>>> >
>>>> > ,- Igor
>>>> >
>>>> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
>>>> > <ashtoko...@mirantis.com> wrote:
>>>> > > Hi Dmitry,
>>>> > >
>>>> > > We've reached the design consensus with Igor today. Could you
>>>> please remove
>>>> > > the conditional status of the FFE request?
>>>> > > As agreed: the merge deadline is March 24.
>>>> > >
>>>> > > --
>>>> > > WBR, Alexey Shtokolov
>>>> > >
>>>> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <
>>>> dborodae...@mirantis.com>:
>>>> > >>
>>>> > >> Granted. Design consensus deadline for the task history part of
>>>> this
>>>> > >> feature is extended to March 11. This does not change the merge
>>>> deadline
>>>> > >> for other parts of this feature, which is still March 24.
>>>> > >>
>>>> > >> --
>>>> > >> Dmitry Borodaenko
>>>> > >>
>>>> > >>
>>>> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>>>> > >> > Dmitry,
>>>> > >> >
>>>> > >> > We are really close to have the consensus, but we need one more
>>>> meeting
>>>> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>>>> > >> > decision.
>>>> > >> > All patches [0] are on review. The meeting is scheduled for
>>>> tomorrow
>>>> > >> > (03/11
>>>> > >> > 1:30pm CET).
>>>> > >> > Could you please grant us one more day for it?
>>>> > >> >
>>>> > >> > [0] -
>>>> > >> >
>>>> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>>>> > >> >
>>>> > >> > --
>>>> > >> > WBR, Alexey Shtokolov
>>>> > >> >
>>>> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
>>>> dborodae...@mirantis.com>:
>>>> > >> >
>>>> > >> > > Granted, merge deadline March 24, task history part of the
>>>> feature is
>>>> > >> > > to
>>>> > >> > > be excluded from this exception grant unless a con

Re: [openstack-dev] [Fuel] [FFE] Unlock Settings Tab

[Vladimir Kozhukalov]

Granted. New deadline is 21:00 UTC 03/28/2016.

Vladimir Kozhukalov

On Fri, Mar 25, 2016 at 8:17 PM, Alexey Shtokolov <ashtoko...@mirantis.com>
wrote:

> Fuelers!
>
>
> We are very close to landing our feature "Unlock Settings Tab". But we
> still have a set of reviews [0] to be merged due to several reasons (incl.
> the migration to python27-db gates on OpenStack Infra). I would like to
> request extra time till Monday to land them.
>
>
> [0] - https://goo.gl/kSwej5
>
> 2016-03-14 11:00 GMT+03:00 Dmitry Borodaenko <dborodae...@mirantis.com>:
>
>> Thanks for working this out! Confirming that task history remains
>> included in the scope of this FFE until the merge deadline, March 24.
>>
>> On Fri, Mar 11, 2016 at 11:48:51PM +0200, Igor Kalnitsky wrote:
>> > Hey Dmitry,
>> >
>> > I confirm that we agreed on feature design, and you can proceed with
>> > granting exception.
>> >
>> > ,- Igor
>> >
>> > On Fri, Mar 11, 2016 at 8:27 PM, Alexey Shtokolov
>> > <ashtoko...@mirantis.com> wrote:
>> > > Hi Dmitry,
>> > >
>> > > We've reached the design consensus with Igor today. Could you please
>> remove
>> > > the conditional status of the FFE request?
>> > > As agreed: the merge deadline is March 24.
>> > >
>> > > --
>> > > WBR, Alexey Shtokolov
>> > >
>> > > 2016-03-11 2:27 GMT+03:00 Dmitry Borodaenko <dborodae...@mirantis.com
>> >:
>> > >>
>> > >> Granted. Design consensus deadline for the task history part of this
>> > >> feature is extended to March 11. This does not change the merge
>> deadline
>> > >> for other parts of this feature, which is still March 24.
>> > >>
>> > >> --
>> > >> Dmitry Borodaenko
>> > >>
>> > >>
>> > >> On Fri, Mar 11, 2016 at 01:02:52AM +0300, Alexey Shtokolov wrote:
>> > >> > Dmitry,
>> > >> >
>> > >> > We are really close to have the consensus, but we need one more
>> meeting
>> > >> > with Fuel-Python Component Lead Igor Kalnitsky to make the final
>> > >> > decision.
>> > >> > All patches [0] are on review. The meeting is scheduled for
>> tomorrow
>> > >> > (03/11
>> > >> > 1:30pm CET).
>> > >> > Could you please grant us one more day for it?
>> > >> >
>> > >> > [0] -
>> > >> >
>> https://review.openstack.org/#/q/topic:bp/store-deployment-tasks-history
>> > >> >
>> > >> > --
>> > >> > WBR, Alexey Shtokolov
>> > >> >
>> > >> > 2016-03-04 3:13 GMT+03:00 Dmitry Borodaenko <
>> dborodae...@mirantis.com>:
>> > >> >
>> > >> > > Granted, merge deadline March 24, task history part of the
>> feature is
>> > >> > > to
>> > >> > > be excluded from this exception grant unless a consensus is
>> reached by
>> > >> > > March 10.
>> > >> > >
>> > >> > > Relevant part of the meeting log starts at:
>> > >> > >
>> > >> > >
>> > >> > >
>> http://eavesdrop.openstack.org/meetings/fuel/2016/fuel.2016-03-03-16.00.log.html#l-198
>> > >> > >
>> > >> > > --
>> > >> > > Dmitry Borodaenko
>> > >> > >
>> > >> > >
>> > >> > > On Wed, Mar 02, 2016 at 06:00:40PM +0700, Vitaly Kramskikh wrote:
>> > >> > > > Oh, so there is a spec. I was worried that this patch has
>> > >> > > > "WIP-no-bprint-assigned-yet" string in the commit message, so I
>> > >> > > > thought
>> > >> > > > there is no spec for it. So the commit message should be
>> updated to
>> > >> > > > avoid
>> > >> > > > such confusion.
>> > >> > > >
>> > >> > > > It's really good I've seen this spec. There are plans to
>> overhaul UI
>> > >> > > > data
>> > >> > > > format description which we use for cluster and node settings
>> to
>> > >> > > > solve
>> > >> > > some
>> > >> > 

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

[Vladimir Kozhukalov]

Dear all,

Let me raise my hand here. We introduced this role CL a while ago for two
major reasons:
 1) improve review process (CL are responsible for review SLA)
 2) introduce review of overall architecture and avoid cross-feature,
cross-component conflicts.
These two points, in fact, mean the following:
 1) CL ask other developers (including cores) to help to review patches if
there any that did not get enough attention
 2) CL spend 50% of their time reviewing specs and we don't merge specs w/o
their +2

I think that is not exactly what we meant. Our CL role is rather a mixture
of a manager and an architect. Both these roles are enterprise roles. I
think in community having Core Reviewers is more than enough.

Real motivation (salary, career, etc.) of a particular contributor should
NOT be a matter of community. If a particular manager wants to have a
person who is to be responsible for asking people to review patches, then
it is a matter of this manager to motivate a particular person. In
community a team of core reviewers is responsible for review, not a person.

To prevent cross-feature and cross-component conflicts we can use CI gate
that will put -1 to a spec that is merged without necessary +2 from trusted
people from various components. For example, we could create a yaml file

avengers:
  fuel-web:
Hawkeye
Captain America
  fuel-ui:
Black Widow
  fuel-library
Hulk
Ironman

and CI gate will check if there is +2 from at least one superhero from
every project and fail if not. Superheros should be volunteers (no matter
what their real motivation is).

I propose to get rid of official CL role in Fuel. Instead it should be
totally up to a particular component team to decide if they want CL or
other roles. What do you guys think?

















Vladimir Kozhukalov

On Thu, Mar 24, 2016 at 11:58 PM, Dmitry Borodaenko <
dborodae...@mirantis.com> wrote:

> Serg,
>
> Thanks for agreeing to officiate this cycle's component lead elections
> for us!
>
> --
> Dmitry Borodaenko
>
>
> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote:
> > Hi folks,
> >
> > I'd like to announce that we're running the Component Leads elections.
> > Detailed information is available on wiki [0].
> >
> > Component Lead: defines architecture of a particular module or
> > component in Fuel, resolves technical disputes in their area of
> > responsibility. All design specs that impact a component must be
> > approved by the corresponding component lead [1].
> >
> > Fuel has three large sub-teams, with roughly comparable codebases,
> > that need dedicated component leads:
> >
> > * fuel-library
> > * fuel-web
> > * fuel-ui
> >
> > Nominees propose their candidacy by sending an email to the
> > openstack-dev@lists.openstack.org mailing-list, with the subject:
> > "[fuel]  lead candidacy"
> > (for example, "[fuel] fuel-library lead candidacy").
> >
> > Timeline:
> > * March 25 - March 31: Open candidacy for Component leads positions
> > * April 1 - April 7: Component leads elections
> >
> > References
> > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016
> > [1]
> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html
> >
> > --
> > Serg Melikyan, Development Manager at Mirantis, Inc.
> > http://mirantis.com | smelik...@mirantis.com
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [shotgun] New shotgun2 command: short-report

[Vladimir Kozhukalov]

Alex,

>This should have been created before removing the thing providing this
information previously.

Once again, using version.yaml you could NOT reproduce the env, because
what was really installed on the Fuel node had nothing in common with what
it was written in version.yaml. The information you think was actual was,
in fact, not actual.

Having 'shotgun report' output you can see real SHA sums, not ephemeral
(like in version.yaml).

And without removal version.yaml we could not implement some features in
make system, so, this new build/test package based approach could not have
been implemented before version.yaml removal. We are moving towards better
developer experience NOT making things worse. In fact version.yaml removal
and substitution it with 'shotgun report' was a fix for broken version.yaml
content.

As for attaching short report to bugs instead of long report, I don't know
what motivation was for this change except their convenience. Probably
short report is to be used for internal QA team purposes only.





Vladimir Kozhukalov

On Mon, Mar 21, 2016 at 11:20 PM, Alex Schultz <aschu...@mirantis.com>
wrote:

>
> On Mon, Mar 21, 2016 at 1:59 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Alex,
>>
>> That is just a short report that QA team needs for their convenience.
>> Please consider this letter as just FYI, nothing more.
>>
>>
> If a bug only contains the short report, how do we work on fixing the
> bug?  My question is valid and should be answered.  What good is this
> information if I cannot reproduce an environment with this information? How
> does one translate or locate specific package versions for reproducing
> issues?  Is this documented?  If not, will it be?  I'd like to know what
> the point of this short report is since I'm not sure how it could be
> consumed by QA/Devs?
>
>
>
>> 'shotgun report' allows you to see commit SHA from which a package was
>> built. It is even more information than it was available in version.yaml
>> and this information is actual unlike the content of version.yaml.
>>
>> I know you were opposing getting rid of version.yaml but the thing is
>> Fuel now can be installed on any CentOS 7.2 node directly from RPM
>> repository. You don't even need the Fuel ISO, and thus version.yaml could
>> not be an artifact that we could rely on (no ISO build id any more, no sha
>> sums). Instead, now we rely on packages that are currently installed on the
>> master node. The only issue with this approach is the ability to easily
>> reproduce the env having just this list of packages attached to a bug. But
>> it is not worse that it was with version.yaml.
>>
>>
> I was only opposed to getting rid of it without a proper replacement which
> is why I keep asking the same questions as an equivalent replacement does
> not seem to exist.  Also it is much worse now that we don't have
> version.yaml because I may have no way to locate these mystical package
> versions that keep getting reported.  At least with git hashes I could at
> least look at the same code base across everything. Now without this
> information I have no way of building a complete picture of the code being
> utilized in the environment.
>
>
>> I'm currently working on design draft about modular data driven
>> functional testing. This could also help for troubleshooting. In a nutshell
>> the developer experience will be like:
>>  1) you look at log files (`shotgun dump`) and roughly locate the issue
>> (that allows you to choose respective test case)
>>  2) you run script passing some data to it (data are to come from
>> 'shotgun report --machinereadable' or smth like this)
>>  3) this script builds testing/experimental env for you (env is to
>> include only those components that are respective to chosen test case)
>>  5) you run some tests against this lab and manually do some experiments
>> to kill the bug
>>
>>
>>
>
> This should have been created before removing the thing providing this
> information previously. Yes I know I sound like a broken record on this,
> but it's very hard to address issues if you cannot reproduce the
> environment they occur on.  I'm trying to make sure we are providing all
> the information to aid in reproducing issues to get them fixed and not just
> providing more information that is ultimately ignored because it's useless.
>
> Thanks,
> -Alex
>
>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Mon, Mar 21, 2016 at 5:28 PM, Alex Schultz <aschu...@mirantis.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 21, 2016 at 7:21 AM, Volodymyr Shypyguzov <
>>> vshypyg

Re: [openstack-dev] [Fuel] [shotgun] New shotgun2 command: short-report

[Vladimir Kozhukalov]

Alex,

That is just a short report that QA team needs for their convenience.
Please consider this letter as just FYI, nothing more.

'shotgun report' allows you to see commit SHA from which a package was
built. It is even more information than it was available in version.yaml
and this information is actual unlike the content of version.yaml.

I know you were opposing getting rid of version.yaml but the thing is Fuel
now can be installed on any CentOS 7.2 node directly from RPM repository.
You don't even need the Fuel ISO, and thus version.yaml could not be an
artifact that we could rely on (no ISO build id any more, no sha sums).
Instead, now we rely on packages that are currently installed on the master
node. The only issue with this approach is the ability to easily reproduce
the env having just this list of packages attached to a bug. But it is not
worse that it was with version.yaml.

I'm currently working on design draft about modular data driven functional
testing. This could also help for troubleshooting. In a nutshell the
developer experience will be like:
 1) you look at log files (`shotgun dump`) and roughly locate the issue
(that allows you to choose respective test case)
 2) you run script passing some data to it (data are to come from 'shotgun
report --machinereadable' or smth like this)
 3) this script builds testing/experimental env for you (env is to include
only those components that are respective to chosen test case)
 5) you run some tests against this lab and manually do some experiments to
kill the bug




Vladimir Kozhukalov

On Mon, Mar 21, 2016 at 5:28 PM, Alex Schultz <aschu...@mirantis.com> wrote:

>
>
> On Mon, Mar 21, 2016 at 7:21 AM, Volodymyr Shypyguzov <
> vshypygu...@mirantis.com> wrote:
>
>> Hi, all
>>
>> Just wanted to inform you, that shotgun2 now has new command
>> short-report, which allows you to receive shorter and cleaner output for
>> attaching to bug description, sharing, etc.
>>
>> Usage: shotgun2 short-report
>> Example output: http://paste.openstack.org/show/491256/
>>
>>
> How will we be able to find those specific packages and how will we be
> able to correlate them with the equivalent commit in the git repository?
>
> Thanks,
> -Alex
>
>
>> Regards,
>> Volodymyr
>>
>> __
>> OpenStack Development Mailing 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] [Infra][Fuel] Increasing deadlock_timeout for PostgreSQL

[Vladimir Kozhukalov]

Roman,

According to documentation [1] this setting is responsible for the amount
of time to wait a lock to be released before trying to check if it is, in
fact, a deadlock. This time just allows not to spend resources for
unnecessary checks.
If a lock is not a deadlock, this check will just skip it and request will
continue to wait for a lock to be released until lock_timeout is exceeded.

[1] http://www.postgresql.org/docs/9.3/static/runtime-config-locks.html

Vladimir Kozhukalov

On Mon, Mar 21, 2016 at 7:39 PM, Roman Prykhodchenko <m...@romcheg.me> wrote:

> Folks,
>
> We have been analyzing a bunch of random failures in Fuel tests and
> encountered several ones caused by detector raising errors occasionally
> [1]. After attempts to reproduce the same behavior have failed we’ve
> decided to run the same test suit on overloaded nodes. Those test-runs
> allowed us to catch the same behavior we’ve seen on CI slaves. After
> analyzing both PostgreSQL logs and Nailgun’s code we’ve found no reasons
> for those deadlocks to occur.
>
> Thinking about the facts mentioned we came up with the idea that those
> random deadlocks occur in cases when CI slaves are overloaded by other jobs
> and transactions start hitting deadlock timeout. Thus I propose to change
> PostgreSQL’s deadlock_timeout value from the default one to 3-5 seconds.
> That will slow down tests, if they run on an overloaded CI slave but will
> help to avoid random and false-positive deadlock warnings.
>
>
> References:
>
> 1. https://bugs.launchpad.net/fuel/+bug/1556070
>
>
> - romcheg
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Sorry, typo:

*cloud case does NOT assume running any kind of agent
inside user instance

Vladimir Kozhukalov

On Fri, Mar 18, 2016 at 7:26 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

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

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

[Vladimir Kozhukalov]

>Well, there's a number of reasons. Ironic is not meant only for an
>"undercloud" (deploying OpenStack on ironic instances). There are both
>public and private cloud deployments of ironic in production today, that
>make bare metal instances available to users of the cloud. Those users
>may not want an agent running inside their instance, and more
>importantly, the operators of those clouds may not want to expose the
>ironic or inspector APIs to their users.

>I'm not sure ironic should say "no, that isn't allowed" but at a minimum
>it would need to be opt-in behavior.

For me it's absolutely clear why cloud case does assume running any kind of
agent
inside user instance. It is clear why cloud case does not assume exposing
API
to the user instance. But cloud is not the only case that exists.
Fuel is a deployment tool. Fuel case is not cloud.  It is 'cattle' (cattle
vs. pets), but
it is not cloud in a sense that instances are 'user instances'.
Fuel 'user instances' are not even 'user' instances.
Fuel manages the content of instances throughout their whole life cycle.

As you might remember we talked about this about two years ago (when we
tried to contribute lvm and md features to IPA). I don't know why this case
(deployment) was rejected again and again while it's still viable and
widely used.
And I don't know why it could not be implemented to be 'opt-in'.
Since that we have invented our own fuel-agent (that supports lvm, md) and
a driver for Ironic conductor that allows to use Ironic with fuel-agent.

>Is the fuel team having a summit session of some sort about integrating
>with ironic better? I'd be happy to come to that if it can be scheduled
>at a time that ironic doesn't have a session. Otherwise maybe we can
>catch up on Friday or something.

>I'm glad to see Fuel wanting to integrate better with Ironic.

We are still quite interested in closer integration with Ironic (we need
power
management features that Ironic provides). We'll be happy to schedule yet
another discussion on closer integration with Ironic.

BTW, about a year ago (in Grenoble) we agreed that it is not even
necessary to merge such custom things into Ironic tree. Happily, Ironic is
smart enough to consume drivers using stevedore. About ironic-inspector
the case is the same. Whether we are going to run it inside 'user instance'
or inside ramdisk it does not affect ironic-inspector itself. If Ironic
team is
open for merging "non-cloud" features (of course 'opt-in') we'll be happy
to contribute.

Vladimir Kozhukalov

On Fri, Mar 18, 2016 at 6:03 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Fri, Mar 18, 2016 at 05:26:13PM +0300, Evgeniy L wrote:
> > On Thu, Mar 17, 2016 at 3:16 PM, Dmitry Tantsur <dtant...@redhat.com>
> wrote:
> >
> > > On 03/16/2016 01:39 PM, Evgeniy L wrote:
> > >
> > >> Hi Dmitry,
> > >>
> > >> I can try to provide you description on what current Nailgun agent is,
> > >> and what are potential requirements we may need from HW discovery
> system.
> > >>
> > >> Nailgun agent is a one-file Ruby script [0] which is periodically run
> > >> under cron. It collects information about HW using ohai [1], plus it
> > >> does custom parsing, filtration, retrieval of HW information. After
> the
> > >> information is collected, it is sent to Nailgun, that is how node gets
> > >> discovered in Fuel.
> > >>
> > >
> > > Quick clarification: does it run on user instances? or does it run on
> > > hardware while it's still not deployed to? The former is something that
> > > Ironic tries not to do. There is an interest in the latter.
> >
> >
> > Both, on user instances (with deployed OpenStack) and on instances which
> > are not deployed and in bootstrap.
> > What are the reasons Ironic tries not to do that (running HW discovery on
> > deployed node)?
>
> Well, there's a number of reasons. Ironic is not meant only for an
> "undercloud" (deploying OpenStack on ironic instances). There are both
> public and private cloud deployments of ironic in production today, that
> make bare metal instances available to users of the cloud. Those users
> may not want an agent running inside their instance, and more
> importantly, the operators of those clouds may not want to expose the
> ironic or inspector APIs to their users.
>
> I'm not sure ironic should say "no, that isn't allowed" but at a minimum
> it would need to be opt-in behavior.
>
> >
> >
> > >
> > >
> > >> To summarise entire process:
> > >> 1. After Fuel master node is installed, user restarts the nodes and
> they
> > >> get boo

Re: [openstack-dev] [Fuel] Packaging CI for Fuel

[Vladimir Kozhukalov]

Hi,

> Are there any effort on OpenStack packaging?

The short answer is yes. We are putting efforts to migrate all
our packaging activities to the community RPM/DEB projects.

Long story is as follows:

At the moment Fuel is distributed as a set of RPM packages. This
Packaging CI that Aleksandra mentioned is nothing more
but a copy of CI that we have been using at Mirantis for about
two years. At the moment we are working hard to split Fuel
into upstream (community) and downstream (part of MOS) and this
CI is a part of this work.

Currently, OpenStack RPM project is at the early development stage.
It is another project (not Fuel) and I hope it will be finally
possible to build RPM packages using OpenStack Infrastructure.
We (Fuel) are in contact with OpenStack RPM team and we are planning
to move all Fuel RPM specs under this project. I hope this migration
will be finished in Newton cycle.

Besides, packaging is not just preparing RPM/DEB specs. We also
need tools to build packages as well as CI strategy
 - get spec here
 - get source code there
 - prepare build environment
 - build packages
 - publish packages to testing repository
 - test packages
 - publish packages to current public repository
Fuel Packaging CI already does this. And the fact that we made a public
Packaging CI instance reflects our intention to share our experience.

I'd also like to mention our recent initiative Packetary [1] which is
a tool that is to cover the whole RPM/DEB packaging domain
(building packages, building repositories, clonning repositories).
It is not something totally new, it is to become a single convenient API to
widely used tools like createrepo, python-debian, mock, sbuild, etc.
This tools could be potentially used as a part of whatever CI or by
a regular user via CLI.

As for DEB packaging, as Thomas wrote, he is currently working on making
this possible to build DEB packages (including Fuel) using OpenStack
Infrastructure.

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


Vladimir Kozhukalov

On Fri, Mar 18, 2016 at 12:11 AM, Thomas Goirand <z...@debian.org> wrote:

> On 03/16/2016 06:22 PM, Emilien Macchi wrote:
> > Are they any effort on OpenStack packaging?
> >
> > http://governance.openstack.org/reference/projects/packaging-deb.html
> > http://governance.openstack.org/reference/projects/packaging-rpm.html
> >
> > I would like to see packaging built & tested by OpenStack Infra, so
> > downstream CI (Fuel, Puppet OpenStack, TripleO, Kolla, etc) could use
> > it as a single place and efforts would converge.
>
> Hi Emilien,
>
> As you know, things were a bit stuck, with the Debian image patch not
> being approved. But it has changed, and we do have a debian-jessie image
> in infra now. Therefore, I've move to the next step, which is actually
> building packages. Here's the CR:
>
> https://review.openstack.org/#/c/294022/
>
> I've been able to test the pkgdeb-install-sbuild.sh script that I'm
> proposing to setup sbuild on a copy of the Debian image (thanks a lot to
> Pabelanger and Fungi copy the image, and give it to me for download),
> and sbuild was setup properly. The pkgdeb-build-pkg.sh also worked,
> though I'm not 100% sure yet about the content of
> /home/jenkins/workspace/${JOB_NAME}, if it will have the correct branch
> or what, but everything else should be working to build packages.
>
> Once packages are built, then we will want to publish them somewhere.
> That's the part where there's lots of unknown. This has so far never
> been done on OpenStack infra. Hopefully, our new PTL will probably help
> here (or someone else from infra)! :) Also, managing a Debian repository
> isn't really hard to do: one can generate the necessary artifacts with a
> small shell script which uses apt-ftparchive (you can look how its done
> at src/pkgos-scan-repo in openstack-pkg-tools).
>
> Finally, we'll need a way to build backports from Sid and also publish
> them.
>
> That's where we are now. Let's go back to the first step, which is the
> CR linked above. Help and comments welcome.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing 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] [all] Newton Design Summit - Proposed slot allocation

[Vladimir Kozhukalov]

It would be great if at least one Fuel slot did not overlap with Ironic
sessions.

Vladimir Kozhukalov

On Fri, Mar 18, 2016 at 6:26 PM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-03-18 08:53:11 +0530 (+0530), Armando M. wrote:
> > It's be nice if Neutron didn't overlap as much with Nova, Ironic, QA and
> > infra sessions, but I appreciate this could be a tall order.
>
> It seems like every project wants to avoid overlap with Infra
> sessions, so I'm not sure it will be easy to accommodate since we
> have to have our sessions _sometime_. However, we do usually try to
> make sure we have scouts in any Infra-relevant sessions for other
> teams, so give us a heads up on which ones those are and we will try
> to get someone to volunteer to sit in if we're not already spread
> too thin.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing 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] PTL Candidacy

[Vladimir Kozhukalov]

Hi all,

I'd like to announce my candidacy to be Fuel PTL for the Newton cycle.
I've been a member of Fuel team since the very beginning of the project.
Fuel started as a proprietary deployment tool for OpenStack, but since
that we have been smothly moving towards being more and more open and
more and more community oriented. In the beginning of Mitaka cycle Fuel
was approved to become an official OpenStack project under Big Tent.
But being an offcial project is not enough. 95% of Fuel contributions
during Mitaka are from Mirantis [1].

Fuel is huge and it is hard for companies and individuals to catch
tendencies in Fuel project and thus it is hard for them to decide how,
what and why they could contribute. One of the biggest problems I see is
Fuel is not modular enough.

Some Fuel components have already been brought out of Fuel and now they
are fully independent. These are Bareon and Packetary. Bareon is a fork of
Fuel-agent and is to become a generic OS provisioning tool. It already has
third party contributions. Fuel is to switch to Bareon in Newton cycle.
Packetary is a former part of Fuel-mirror. It is to become a generic tool
to deal with DEB and RPM repositories and packages, so its use case
is much broader than Fuel.

Some current Fuel components are quite generic and thus they could
be brought out of Fuel project. For example, Shotgun is a tool for
collecting log files and commands output from an environment, but this
functionality could potentially be useful for other projects.
The same is about Network-checker.

Some Fuel components strictly depend on Fuel but their purpose is generic.
We could put some efforts to make these components fully data driven and
thus expand their use case. For example, Fuel-menu is a tool that provides
user configuration dialog. Why should it be Fuel specific? Could we make it
data driven and expand its use case? The same is about Fuel-virtualbox,
which
is just a set of configurable shell scripts that could be used for non-Fuel
virtualbox environments. Fuel-ostf also could be potentially used out of
Fuel.

Some Fuel components could potentially be substituted with generic community
tools. For example, Fuel-nailgun-agent is a discovery/inventory tool.
Ironic-inspector does the same. Ironic itself could be used as a power
management tool. Perhaps Neutron could be used for network allocation and
configuration. Anyway, we should put more efforts in integrating with
other OpenStack projects (i.e. avoid duplicating code as well as
functionality).

Besides, Fuel development process is feature driven. Contributors are
encouraged to merge changes that implement a feature but they are not
encouraged to think of how maintainable that change is and how it is
related to the component architecture. Last couple cycles we suffered a lot
when many features were to be merged by feature freeze. There were many
feature
freeze exceptions, we merged features that had not been tested well.

My suggestion for Newton cycle is to switch from feature driven approach
to component driven. All components should have dedicated teams that should
plan
components road map taking into account not only feature requests but also
tech
debt and components architecture. It is better when people are focused on
their
particular field like REST API, network configuration, OS provisioning, etc.
That is going to make feature planning more predictable, help to avoid
feature
freeze rush and increase the quality of code. Component teams
should also be responsible for thorough test coverage
(including functional and system/integration tests) and for
promotion of their components.

If we make Fuel components as much independent and generic as
possible, that will help us to expand component use cases and thus
to to attract third party contributors.

My primary goals for Newton cycle are:
1) Switch to component driven development approach
   (i.e. by-component teams, by-component releases)
2) Introduce by-component and cross-component functional testing
3) Attract third party contributors, so they contribute at least 10%

There are lots of things that I'd like to be implemented (integrating with
OpenStack packaging, UEFI support, torrent based OS provisioning,
OpenStack deployment from source code, power management, LCM, etc.)
but I'm going to rely on component teams opinions in such particular fields.

Thanks for reading. If you like the plan, please vote.

[1] http://stackalytics.com/?module=fuel-group=commits


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

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

[Vladimir Kozhukalov]

Alexander,

We have many other places where use Ruby (astute, puppet custom types,
etc.). I don't think it is a good reason to re-write something just because
it is written in Ruby. You are right about tests, about plugins, but let's
look around. Ironic community has already invented discovery component (btw
written in python) and I can't see any reason why we should continue
putting efforts in nailgun agent and not try to switch to ironic-inspector.





Vladimir Kozhukalov

On Mon, Mar 14, 2016 at 7:41 PM, Evgeniy L <e...@mirantis.com> wrote:

> Hi Alexander, thanks for bringing this up.
>
> From your list of problems the only problem which I see is 1st, 2nd and
> 3rd are solvable even with current implementation.
>
> Also I don't think that we should continue developing our own HW discovery
> mechanism, we should consider switching to ironic-inspector, and get common
> discovery system [0]. We need to evaluate it and get a list of features
> which we may need from it and discuss with ironic team.
>
> Thanks,
>
> [0] https://github.com/openstack/ironic-inspector
>
> On Mon, Mar 14, 2016 at 6:13 PM, Alexander Saprykin <
> asapry...@mirantis.com> wrote:
>
>> Hi,
>>
>> We have fuel-nailgun-agent project which was initially written on Ruby.
>> It is 900 lines of code single script, that collects and provides to the
>> nailgun information about node's hardware.
>>
>> In the past several iteration we had to introduce new modifications to
>> that script we discovered couple of major problems with it.
>>
>> 1. Most of our software engineers are Python programmers and it's quite
>> complicated to add new features. We have or to write ugly ruby code or to
>> wait for somebody who knows it to write it.
>>
>> 2. Nailgun agent doesn't have tests. At all.
>>
>> 3. It would be good to have a plugins support in the nailgun agent. In
>> case if customer wants to collect any extra information about nodes that
>> can be used in fuel plugins.
>>
>> Possible obstacles:
>>
>> Nailgun agent depends from Ruby library called *ohai* which provides
>> hardware information.
>>
>> Our proposal is to:
>>
>> 1. Rewrite fuel nailgun agent to Python.
>>
>> 2. Add proper unit tests.
>>
>> 3. Ohai library can be used as CLI tool or it can be replaced with pure
>> python solution (to be investigated)
>>
>> 4. Nailgun agent can be extended with plugins based on steevedore.
>>
>>
>> Best regards,
>> Alexander Saprykin
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

​Evge​niy,

Right. There is only nailgun python project, development documentation [1]
and some minor scripts [2] which are outdated. Our further plan is to move
nailgun itself to a separate repo fuel-nailgun, remove outdated code, and
then move development doc pages to corresponding git repos.

[1] https://github.com/openstack/fuel-web/tree/master/docs
[2] https://github.com/openstack/fuel-web/tree/master/bin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Vitaly,

As we decided yesterday custom job with fuel-ui and fuel-web refspec
parameters could help here. Is it not enough for our case? In general, the
case when two PRs depends on each other was deliberately denied to be
handled automatically. Please read this thread [1] for details.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-February/056515.html




Vladimir Kozhukalov

On Thu, Mar 3, 2016 at 7:01 PM, Vitaly Kramskikh <vkramsk...@mirantis.com>
wrote:

> Fuel UI code has been completely removed from fuel-web repo and CI jobs to
> verify fuel-web RR with fuel-ui code and fuel-ui RR with fuel-web code have
> been set up. So the code separation can be considered as done.
>
> Though there is one thing needs to be done and we don't know how to solve
> that task properly: how do we test and merge RRs to fuel-web and fuel-ui
> which are dependent on each other? Example of such RR:
> https://review.openstack.org/#/c/286547/. It has -1 from CI because this
> change needs to be tested against corresponding RR to fuel-web repo.
>
> If you have any ideas, feel free to tell us.
>
> 2016-03-01 16:09 GMT+07:00 Vitaly Kramskikh <vkramsk...@mirantis.com>:
>
>> The new repo has been created: https://github.com/openstack/fuel-ui.
>> Please move all change requests there. Fuel UI code in fuel-web repo is
>> going to be removed soon.
>>
>> 2016-02-26 19:53 GMT+07:00 Vladimir Kozhukalov <vkozhuka...@mirantis.com>
>> :
>>
>>> Dear colleagues,
>>>
>>> We are ready for moving UI javascript code to a separate git repository.
>>> Since now all review requests for fuel-web@master that are related to
>>> UI must be marked -2 and later abandoned. Once new project fuel-ui is
>>> created those changes should be backported to this new repository.
>>>
>>> Checklist:
>>>
>>>
>>>- Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
>>>- openstack-infra
>>>   - project-config https://review.openstack.org/#/c/260455 (ON
>>>   REVIEW)
>>>   - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
>>>- fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
>>>- label jenkins slaves for the new job (ci team)
>>>- UI directory freeze (DONE)
>>>- prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
>>>- waiting for openstack-infra patches to be merged
>>>- .gitreview .gitignore MAINTAINERS (TODO)
>>>- rpm spec (TODO)
>>>- custom ci jobs (TODO)
>>>- fuel-main (TODO)
>>>- packaging ci (TODO)
>>>- remove old files (TODO)
>>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Vitaly Kramskikh,
>> Fuel UI Tech Lead,
>> Mirantis, Inc.
>>
>
>
>
> --
> Vitaly Kramskikh,
> Fuel UI Tech Lead,
> Mirantis, Inc.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] [FFE] Use packetary for building ISO

[Vladimir Kozhukalov]

Andrew,

I think everything will be ready by Wednesday 03/09/2016. We have just
fixed one critical bug in Packetary, now it seems working.

Vladimir Kozhukalov

On Wed, Mar 2, 2016 at 4:21 PM, Andrew Maksimov <amaksi...@mirantis.com>
wrote:

> Hi Vladimir,
>
> Till what date do you want FFE ?
>
> Regards,
> Andrey Maximov
> Fuel Project Manager
>
> On Tue, Mar 1, 2016 at 5:36 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> I'd like to request a feature freeze exception for "Use packetary for
>> building ISO". BP [0]
>>
>> There is PR in packetary itself [1]. And one pull request in fuel-main
>> [2].
>>
>> For ISO build process this feature means we will use the same command
>> 'make iso' but another set of environment variables.
>>
>> This change is going to make ISO build process fully data driven (yaml).
>> It will allow us to build ISO with various sets of repositories (upstream
>> fuel repo, custom repos, etc.) Also it is going to make ISO build process
>> even faster (about 5 minutes).
>>
>> Risk to affect other teams is medium. Merge plan is as follows:
>>
>> 1) We will create a parallel ISO build job with new set of variables and
>> make it use fuel-main request (not merging it)
>> 2) We will run this job for couple of days and run smoke and BVT tests
>> 3) Once everything is ready and working we will merge fuel-main patch and
>> declare this new job as our product ISO job
>> 4) We will create custom jobs with this new set of variables
>>
>> [0] https://blueprints.launchpad.net/fuel/+spec/use-packetary-in-fuel
>> [1] https://review.openstack.org/#/c/286576
>> [2] https://review.openstack.org/#/c/283976
>>
>>
>> Vladimir Kozhukalov
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] [FFE] Use packetary for building ISO

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to request a feature freeze exception for "Use packetary for
building ISO". BP [0]

There is PR in packetary itself [1]. And one pull request in fuel-main [2].

For ISO build process this feature means we will use the same command 'make
iso' but another set of environment variables.

This change is going to make ISO build process fully data driven (yaml). It
will allow us to build ISO with various sets of repositories (upstream fuel
repo, custom repos, etc.) Also it is going to make ISO build process even
faster (about 5 minutes).

Risk to affect other teams is medium. Merge plan is as follows:

1) We will create a parallel ISO build job with new set of variables and
make it use fuel-main request (not merging it)
2) We will run this job for couple of days and run smoke and BVT tests
3) Once everything is ready and working we will merge fuel-main patch and
declare this new job as our product ISO job
4) We will create custom jobs with this new set of variables

[0] https://blueprints.launchpad.net/fuel/+spec/use-packetary-in-fuel
[1] https://review.openstack.org/#/c/286576
[2] https://review.openstack.org/#/c/283976


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

[openstack-dev] [Fuel] UI code freeze

[Vladimir Kozhukalov]

Dear colleagues,

We are ready for moving UI javascript code to a separate git repository.
Since now all review requests for fuel-web@master that are related to UI
must be marked -2 and later abandoned. Once new project fuel-ui is created
those changes should be backported to this new repository.

Checklist:


   - Launchpad UI bug: https://bugs.launchpad.net/fuel/+bug/1471763
   - openstack-infra
  - project-config https://review.openstack.org/#/c/260455 (ON REVIEW)
  - governance https://review.openstack.org/#/c/285270/ (ON REVIEW)
   - fuel-ci job https://review.fuel-infra.org/#/c/15487 (ON REVIEW)
   - label jenkins slaves for the new job (ci team)
   - UI directory freeze (DONE)
   - prepare upstream https://github.com/kozhukalov/fuel-ui.git (DONE)
   - waiting for openstack-infra patches to be merged
   - .gitreview .gitignore MAINTAINERS (TODO)
   - rpm spec (TODO)
   - custom ci jobs (TODO)
   - fuel-main (TODO)
   - packaging ci (TODO)
   - remove old files (TODO)


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

Re: [openstack-dev] [fuel] Move virtualbox scripts to a separate directory

[Vladimir Kozhukalov]

New git repository fuel-virtualbox has been created
https://github.com/openstack/fuel-virtualbox.git and since now all review
requests that are related to virtualbox scripts for releases 9.0 and later
should be sent to the new git repository.

Checklist status:

   - Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1544271
   - project-config patch https://review.openstack.org/#/c/279074 (MERGED)
   - governance patch https://review.openstack.org/#/c/281653/ (ON REVIEW)
   - prepare upstream https://github.com/kozhukalov/fuel-virtualbox (DONE)
   - .gitreview file https://review.openstack.org/#/c/283265 (ON REVIEW)
   - .gitignore file https://review.openstack.org/#/c/283265 (ON REVIEW)
   - MAINTAINERS file https://review.openstack.org/#/c/283265 (ON REVIEW)
   - remove old files from fuel-main https://review.openstack.org/#/c/283272
   (ON REVIEW)



Vladimir Kozhukalov

On Wed, Feb 17, 2016 at 9:11 PM, Maksim Malchuk <mmalc...@mirantis.com>
wrote:

> Hi Fabrizio,
>
> The project-config patch is on the review now, waiting for a
> core-reviewers to merge the changes.
>
>
> On Wed, Feb 17, 2016 at 5:47 PM, Fabrizio Soppelsa <fsoppe...@mirantis.com
> > wrote:
>
>> Vladimir,
>> a dedicated repo - good to hear.
>> Do you have a rough estimate for how long this directory will be in
>> freeze state?
>>
>> Thanks,
>> Fabrizio
>>
>>
>> On Feb 15, 2016, at 5:16 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>> Dear colleagues,
>>
>> I'd like to announce that we are next to moving fuel-main/virtualbox
>> directory to a separate git repository. This directory contains a set of
>> bash scripts that could be used to easily deploy Fuel environment and try
>> to deploy OpenStack cluster using Fuel. Virtualbox is used as a
>> virtualization layer.
>>
>> Checklist for this change is as follows:
>>
>>1. Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1544271
>>2. project-config patch https://review.openstack.org/#/c/279074/2 (ON
>>REVIEW)
>>3. prepare upstream (DONE)
>>https://github.com/kozhukalov/fuel-virtualbox
>>4. .gitreview file (TODO)
>>5. .gitignore file (TODO)
>>6. MAINTAINERS file (TODO)
>>7. remove old files from fuel-main (TODO)
>>
>> Virtualbox directory is not actively changed, so freezing this directory
>> for a while is not going to affect the development process significantly.
>> From this moment virtualbox directory is declared freezed and all changes
>> in this directory that are currently in work should be later backported to
>> the new git repository (fuel-virtualbox).
>>
>> Vladimir Kozhukalov
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org
>> ?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Best Regards,
> Maksim Malchuk,
> Senior DevOps Engineer,
> MOS: Product Engineering,
> Mirantis, Inc
> <vgor...@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-dev] [fuel] Move virtualbox scripts to a separate directory

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to announce that we are next to moving fuel-main/virtualbox
directory to a separate git repository. This directory contains a set of
bash scripts that could be used to easily deploy Fuel environment and try
to deploy OpenStack cluster using Fuel. Virtualbox is used as a
virtualization layer.

Checklist for this change is as follows:

   1. Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1544271
   2. project-config patch https://review.openstack.org/#/c/279074/2 (ON
   REVIEW)
   3. prepare upstream (DONE) https://github.com/kozhukalov/fuel-virtualbox
   4. .gitreview file (TODO)
   5. .gitignore file (TODO)
   6. MAINTAINERS file (TODO)
   7. remove old files from fuel-main (TODO)

Virtualbox directory is not actively changed, so freezing this directory
for a while is not going to affect the development process significantly.
>From this moment virtualbox directory is declared freezed and all changes
in this directory that are currently in work should be later backported to
the new git repository (fuel-virtualbox).

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

Re: [openstack-dev] [Fuel] CentOS bootstrap image retirement

[Vladimir Kozhukalov]

Colleagues,

Centos bootstrap image (that we used to build together with the ISO) code
has been removed from fuel-main. Now the only available option is the
Ubuntu based bootstrap image that is built on the master node in run time.
>From this moment we are ready to get rid of building Fuel packages at the
ISO build time and instead download them from Fuel Packaging CI.




Vladimir Kozhukalov

On Wed, Feb 3, 2016 at 6:03 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> +1
>
>
> On Wed, Feb 3, 2016 at 4:45 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>
>> No objections from my side. Let's do it.
>>
>> On Tue, Feb 2, 2016 at 8:35 PM, Dmitry Klenov <dkle...@mirantis.com>
>> wrote:
>> > Hi Sergey,
>> >
>> > I fully support this idea. It was our plan as well when we were
>> developing
>> > Ubuntu Bootstrap feature. So let's proceed with CentOS bootstrap
>> removal.
>> >
>> > BR,
>> > Dmitry.
>> >
>> > On Tue, Feb 2, 2016 at 2:55 PM, Sergey Kulanov <skula...@mirantis.com>
>> > wrote:
>> >>
>> >> Hi Folks,
>> >>
>> >> I think it's time to declare CentOS bootstrap image retirement.
>> >> Since Fuel 8.0 we've switched to Ubuntu bootstrap image usage [1, 2]
>> and
>> >> CentOS one became deprecated,
>> >> so in Fuel 9.0 we can freely remove it [2].
>> >> For now we are building CentOS bootstrap image together with ISO and
>> then
>> >> package it into rpm [3], so by removing fuel-bootstrap-image [3] we:
>> >>
>> >> * simplify patching/update story, since we don't need to
>> rebuild/deliver
>> >> this
>> >>   package on changes in dependent packages [4].
>> >>
>> >> * speed-up ISO build process, since building centos bootstrap image
>> takes
>> >> ~ 20%
>> >>   of build-iso time.
>> >>
>> >> We've prepared related blueprint for this change [5] and spec [6]. We
>> also
>> >> have some draft patchsets [7]
>> >> which passed BVT tests.
>> >>
>> >> So the next steps are:
>> >> * get feedback by reviewing the spec/patches;
>> >> * remove related code from the rest fuel projects (fuel-menu,
>> fuel-devops,
>> >> fuel-qa).
>> >>
>> >>
>> >> Thank you
>> >>
>> >>
>> >> [1]
>> >>
>> https://specs.openstack.org/openstack/fuel-specs/specs/7.0/fuel-bootstrap-on-ubuntu.html
>> >> [2]
>> >>
>> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/dynamically-build-bootstrap.html
>> >> [3]
>> >>
>> https://github.com/openstack/fuel-main/blob/master/packages/rpm/specs/fuel-bootstrap-image.spec
>> >> [4]
>> >>
>> https://github.com/openstack/fuel-main/blob/master/bootstrap/module.mk#L12-L50
>> >> [5]
>> >>
>> https://blueprints.launchpad.net/fuel/+spec/remove-centos-bootstrap-from-fuel
>> >> [6] https://review.openstack.org/#/c/273159/
>> >> [7]
>> >>
>> https://review.openstack.org/#/q/topic:bp/remove-centos-bootstrap-from-fuel
>> >>
>> >>
>> >> --
>> >> Sergey
>> >> DevOps Engineer
>> >> IRC: SergK
>> >> Skype: Sergey_kul
>> >>
>> >>
>> __
>> >> OpenStack Development Mailing 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
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

+1 to enable it ASAP.

It will also affect our deployment tests (~1 hour vs. ~2.5 hours).

Vladimir Kozhukalov

On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin <bgaiful...@mirantis.com>
wrote:

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

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

[Vladimir Kozhukalov]

Vladimir,

I have other activities planned for the time immediately after SCF
(separating UI from fuel-web, maybe it is even more invasive :-)) and it is
not a big deal to postpone this feature or another. I am against the
approach itself of postponing something because it is too invasive. If we
create stable branch master becomes open. That was our primary intention to
open master earlier than later when we decided to move stable branch
creation.




Vladimir Kozhukalov

On Wed, Dec 16, 2015 at 8:28 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

> Vladimir
>
> I am pretty much for removing docker, but I do not think that we should
> startle our developers/QA folks with additional efforts on fixing 2
> different environments. Let's just think from the point of development
> velocity here and at delay such changes for at least after NY. Because if
> we do it immediately after SCF there will be a whole bunch of holidays and
> Russian holidays are Jan 1st-10th and you (who is the SME for docker
> removal) will be offline. Do you really want to fix things instead of
> enjoying holidays?
>
> On Wed, Dec 16, 2015 at 4:09 PM, Evgeniy L <e...@mirantis.com> wrote:
>
>> +1 to Vladimir Kozhukalov,
>>
>> Entire point of moving branches creation to SCF was to perform such
>> changes as
>> early as possible in the release, I see no reasons to wait for HCF.
>>
>> Thanks,
>>
>> On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> -1
>>>
>>> We already discussed this and we have made a decision to move stable
>>> branch creation from HCF to SCF. There were reasons for this. We agreed
>>> that once stable branch is created, master becomes open for new features.
>>> Let's avoid discussing this again.
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Wed, Dec 16, 2015 at 9:55 AM, Bulat Gaifullin <
>>> bgaiful...@mirantis.com> wrote:
>>>
>>>> +1
>>>>
>>>> Regards,
>>>> Bulat Gaifullin
>>>> Mirantis Inc.
>>>>
>>>>
>>>>
>>>> On 15 Dec 2015, at 22:19, Andrew Maksimov <amaksi...@mirantis.com>
>>>> wrote:
>>>>
>>>> +1
>>>>
>>>> Regards,
>>>> Andrey Maximov
>>>> Fuel Project Manager
>>>>
>>>> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin <vkuk...@mirantis.com>
>>>> wrote:
>>>>
>>>>> Folks
>>>>>
>>>>> This email is a proposal to push Docker containers removal from the
>>>>> master node to the date beyond 8.0 HCF.
>>>>>
>>>>> Here is why I propose to do so.
>>>>>
>>>>> Removal of Docker is a rather invasive change and may introduce a lot
>>>>> of regressions. It is well may affect how bugs are fixed - we might have 2
>>>>> ways of fixing them, while during SCF of 8.0 this may affect velocity of
>>>>> bug fixing as you need to fix bugs in master prior to fixing them in 
>>>>> stable
>>>>> branches. This actually may significantly increase our bugfixing pace and
>>>>> put 8.0 GA release on risk.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Yours Faithfully,
>>>>> Vladimir Kuklin,
>>>>> Fuel Library Tech Lead,
>>>>> Mirantis, Inc.
>>>>> +7 (495) 640-49-04
>>>>> +7 (926) 702-39-68
>>>>> Skype kuklinvv
>>>>> 35bk3, Vorontsovskaya Str.
>>>>> Moscow, Russia,
>>>>> www.mirantis.com <http://www.mirantis.ru/>
>>>>> www.mirantis.ru
>>>>> vkuk...@mirantis.com
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> <http://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
>>>> ?su

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

[Vladimir Kozhukalov]

-1

We already discussed this and we have made a decision to move stable branch
creation from HCF to SCF. There were reasons for this. We agreed that once
stable branch is created, master becomes open for new features. Let's avoid
discussing this again.

Vladimir Kozhukalov

On Wed, Dec 16, 2015 at 9:55 AM, Bulat Gaifullin <bgaiful...@mirantis.com>
wrote:

> +1
>
> Regards,
> Bulat Gaifullin
> Mirantis Inc.
>
>
>
> On 15 Dec 2015, at 22:19, Andrew Maksimov <amaksi...@mirantis.com> wrote:
>
> +1
>
> Regards,
> Andrey Maximov
> Fuel Project Manager
>
> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
>
>> Folks
>>
>> This email is a proposal to push Docker containers removal from the
>> master node to the date beyond 8.0 HCF.
>>
>> Here is why I propose to do so.
>>
>> Removal of Docker is a rather invasive change and may introduce a lot of
>> regressions. It is well may affect how bugs are fixed - we might have 2
>> ways of fixing them, while during SCF of 8.0 this may affect velocity of
>> bug fixing as you need to fix bugs in master prior to fixing them in stable
>> branches. This actually may significantly increase our bugfixing pace and
>> put 8.0 GA release on risk.
>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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] Separate master node provisioning and deployment

[Vladimir Kozhukalov]

> Meantime we can provide fuel-menu which will become a configuration
> gate for different subprojects. Perhaps we could consider to use
> pluggable approach, so each component will export plugin for fuel-menu
> with own settings.

fuel-menu could be a configuration gate for fuel deployment script

> The wrong thing is that with such approach it would be impossible to
> setup Fuel with just something like

>$ yum install fuel

I see nothing wrong here. 'yum install fuel' would be appropriate approach
if fuel was a service,
not a bunch of services some of which are not even limited to be installed
on the master node.

when you run

# yum install fuel
# fuel-menu

it the same as you run

# yum install fuel
# fuel_deploy_script (which runs fuel-menu and then runs puppet which
installs everything else)

I like the idea when fuel (let's rename it into fuel-deploy) package
provides just a deployment script.
It does not require a lot of changes and it corresponds to what we really
do. Besides, it is more flexible
because deployment could be modular (several stages).

One of potential disadvantages is that it is harder to track package
dependencies, but I think
a deployment script should be a root of the package dependency tree.



Vladimir Kozhukalov

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

> Vladimir,
>
> Thanks for raising this question. I totally support idea of separating
> provisioning and deployment steps. I believe it'll simplify a lot of
> things.
>
> However I have some comments regarding this topic, see them inline. :)
>
> > For a package it is absolutely normal to throw a user dialog.
>
> It kills idea of fuel-menu, since each package will need to implement
> configuration menu of its own. Moreover, having such configuration
> menu in fuel-menu and in each package is too expensive, it will
> require more effort that I'd like to have.
>
> > Fuel package could install default astute.yaml (I'd like to rename it
> > into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the
> > file by default not running fuelmenu
>
> I don't like idea of having one common configuration file for Fuel
> components. I think it'd be better when each component (subproject)
> has its own configuration file, and knows nothing about external ones.
>
> Meantime we can provide fuel-menu which will become a configuration
> gate for different subprojects. Perhaps we could consider to use
> pluggable approach, so each component will export plugin for fuel-menu
> with own settings.
>
> > What is wrong with 'deployment script' approach?
>
> The wrong thing is that with such approach it would be impossible to
> setup Fuel with just something like
>
> $ yum install fuel
>
> In my opinion we should go into the following approach:
>
> * yum install fuel
> * fuel-menu
>
> The first command should install a basic Fuel setup, and everything
> should work when it's done.
>
> While the second one prompts a configuration menu where one might
> change default settings (reconfigure default installation).
>
> Thanks,
> Igor
>
> On Mon, Dec 14, 2015 at 9:30 AM, Vladimir Kozhukalov
> <vkozhuka...@mirantis.com> wrote:
> > Oleg,
> >
> > Thanks a lot for your opinion. Here are some more thoughts on this topic.
> >
> > 1) For a package it is absolutely normal to throw a user dialog. But
> > probably there is kind of standard for the dialog that does not allow to
> use
> > fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial
> [0]
> > how to get user input during post install. I don't know if there is such
> a
> > standard for RPM packages. In some MLs it is written that any command
> line
> > program could be run in %post section including those like fuel-menu.
> >
> > 2) Fuel package could install default astute.yaml (I'd like to rename it
> > into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the
> file
> > by default not running fuelmenu. A user then is supposed to run fuelmenu
> if
> > he/she needs to re-configure fuel installation. However, it is gonna be
> > quite intrusive. What if a user installs fuel and uses it for a while
> with
> > default configuration. What if some clusters are already in use and then
> the
> > user decides to re-configure the master node. Will it be ok?
> >
> > 3) What is wrong with 'deployment script' approach? Why can not fuel just
> > install kind of deployment script? Fuel is not a service, it consists of
> > many components. Moreover some of these components could be optional (not
> > currently but who knows?), some of this components could be run on an
> > ext

Re: [openstack-dev] [Fuel] Separate master node provisioning and deployment

[Vladimir Kozhukalov]

Oleg,

Thanks a lot for your opinion. Here are some more thoughts on this topic.

1) For a package it is absolutely normal to throw a user dialog. But
probably there is kind of standard for the dialog that does not allow to
use fuelmenu. AFAIK, for DEB packages it is debconf and there is a tutorial
[0] how to get user input during post install. I don't know if there is
such a standard for RPM packages. In some MLs it is written that any
command line program could be run in %post section including those like
fuel-menu.

2) Fuel package could install default astute.yaml (I'd like to rename it
into /etc/fuel.yaml or /etc/fuel/config.yaml) and use values from the file
by default not running fuelmenu. A user then is supposed to run fuelmenu if
he/she needs to re-configure fuel installation. However, it is gonna be
quite intrusive. What if a user installs fuel and uses it for a while with
default configuration. What if some clusters are already in use and then
the user decides to re-configure the master node. Will it be ok?

3) What is wrong with 'deployment script' approach? Why can not fuel just
install kind of deployment script? Fuel is not a service, it consists of
many components. Moreover some of these components could be optional (not
currently but who knows?), some of this components could be run on an
external node (after all Fuel components use REST, AMQP, XMLRPC to interact
with each other).
Imagine you want to install OpenStack. It also consists of many components.
Some components like database or AMQP service could be deployed using HA
architecture. What if one needs Fuel to be run with external HA database,
amqp? From this perspective I'd say Fuel package should not exist at all.
Let's maybe think of Fuel package as a convenient way to deploy Fuel on a
single node, i.e single node deployment script.

4) If Fuel is just a deployment script, then I'd say we should not run any
post install dialog. Deployment script is to run this dialog (fuelmenu) and
then run puppet. IMO it sounds reasonable.


[0] http://www.fifi.org/doc/debconf-doc/tutorial.html

Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 11:14 PM, Oleg Gelbukh <ogelb...@mirantis.com>
wrote:

> For the package-based deployment, we need to get rid of 'deployment
> script' whatsoever. All configuration stuff should be done in package
> specs, or by the user later on (maybe via some fuelmenu-like lightweight
> UI, or via WebUI).
>
> Thus, fuel package must install everything that is required for running
> base Fuel as it's dependencies (or dependencies of it's dependencies, as it
> could be more complicated with cross-deps between our components).
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, Dec 11, 2015 at 10:45 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> At the moment part of the Fuel master deployment logic is located in ISO
>> kickstart file, which is bad. We'd better carefully split provisioning and
>> deployment stages so as to install base operating system during
>> provisioning stage and then everything else on the deployment stage. That
>> would make it possible to deploy Fuel on pre-installed vanilla Centos 7.
>> Besides, if we have deb packages for all Fuel components it will be easy to
>> support Fuel deployment on pre-installed Ubuntu and Debian.
>>
>> We (Fuel build team) are going to do this ASAP [0]. Right now we are on
>> the stage of writing design spec for the change [1].
>>
>> Open questions are:
>> 1) Should fuel package have all other fuel packages like nailgun, astute,
>> etc. as its dependencies? Or maybe it should install only puppet modules
>> and deployment script that then could be used to deploy everything else?
>>
>> 2) bootstrap_admin_node.sh runs fuelmenu and then puppet to deploy Fuel
>> components. Should we run this script as post-install script or maybe we
>> should leave this up to a user to run this script later when fuel package
>> is already installed?
>>
>> Anyway, the final goal is to make ISO just one of possible delivery
>> schemes. Primary delivery approach should be rpm/deb repo, not ISO.
>>
>> [0]
>> https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
>> [1] https://review.openstack.org/#/c/254270/
>>
>> Vladimir Kozhukalov
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing L

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

Regarding to UI. Of course, we could provide native format to a user on UI.
Although I don't think it would be much easier to edit, but it is flexible
enough to define something like this:

http://url trusty main
http://anotherurl trusty universe multiverse restricted
http://yet-another-url trusty-my-favorite-updates my-favorite-section

While we (for some reasons) limited our UI to define only base url and base
suite. That should be fixed.


Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> > Do we really need a custom format? Why can not we use native format
> > for yum.conf and apt.sources files
>
> Because we don't want to parse this format each time we want to verify
> / handle particular component of this format. Moreover, there's no,
> for example, priority in Debian repo format. Priority is used by apt
> preference (not by repo itself).
>
> We're talking about Fuel internal representation, and it would be nice
> to have one internal format across various Fuel projects.
>
>
> > But UI, in my opinion, should follow practices that already exist, not
> define something new.
>
> AFAIU, the idea is to unified internal representation and keep UI as
> close to distributive standards.
>
> On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova
> <afedor...@mirantis.com> wrote:
> > Hi,
> >
> > I agree with the idea of unification for repo configurations, but it
> > looks like we are developing yet another standard.
> >
> > Do we really need a custom format? Why can not we use native format
> > for yum.conf and apt.sources files, and native tooling (all those
> > python bindings, cli utils and so on) which is already developed to
> > work with them?
> >
> > On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
> >> Hey folks -
> >>
> >> +1 from my side on the idea of having the unified repo format. It will
> >> simplify a cross-project contribution. I think we can file a blueprint
> >> for 9.0.
> >>
> >> I have only two questions to discuss:
> >>
> >> * We need to declare format for RPM repos either.
> >> * Shouldn't we use slightly different set of fields for flat Debian
> repos?
> >>
> >> - Igor
> >>
> >> On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev <fzhad...@mirantis.com>
> wrote:
> >>> Hello Vladimir,
> >>>
> >>> I definitely agree that using one uri for generating number of repos
> is not
> >>> the best solution.
> >>> According to Fuel Menu - there was the discussion in gerrit [1] about
> >>> repositories format. The first version of my patch implements actually
> your
> >>> idea about equality and independence of repositories. It meets
> disagreements
> >>> and no one voted for this POV. So I had to change the implementation in
> >>> favor to the current version.
> >>>
> >>> According to this situation I would like to discuss if proposed
> changes are
> >>> needed before making new patch. Guys, who took part in the previous
> patch
> >>> discussion, please share your opinions.
> >>>
> >>> [1] https://review.openstack.org/#/c/242646/
> >>>
> >>> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <
> vkozhuka...@mirantis.com>:
> >>>>
> >>>> Dear colleagues,
> >>>>
> >>>> At the moment we have several places where we configure multiple
> rpm/deb
> >>>> repositories. Those are:
> >>>>
> >>>> Web UI (cluster settings tab) where we define repos for cluster
> deployment
> >>>> Fuel-menu (bootstrap section) where we define repos for building
> ubuntu
> >>>> bootstrap image
> >>>> Fuel-mirror where we define repos that are to be cloned (full or
> partial
> >>>> mirrors)
> >>>>
> >>>> I'd prefer all these places to provide the same UX. By that I mean
> that
> >>>> these components should use the same input data structure like this
> [0],
> >>>> i.e. a flat list of fully independent repositories (see an example
> below).
> >>>> First repo in the list is supposed to be a base OS repo (i.e.
> contains base
> >>>> packages like libc).
> >>>>
> >>>> [
> >>>>  {
> >>>> type: deb,
> >>>> url: some-url,
> >>>> section: some-section,
> >>&

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

This thread is not about format itself, but about the approach when all
repos are thought independently. I.e. no patterns like this suite,
suite-updates, suite-security, no limitations for suite and suite-updates
should be located on the same host. It should be flat list of independent
repos. There is an opinion that I am opposing to that when defining repos a
user should define only base url and base suite:

http://archive.ubuntu.com/ubuntu
trusty

and then we are supposed to derive a set of repos like this:

http://archive.ubuntu.com/ubuntu/dists/trusty main universe
multiverse restricted
http://archive.ubuntu.com/ubuntu/dists/trusty-updates main universe
multiverse restricted
http://archive.ubuntu.com/ubuntu/dists/trusty-security main universe
multiverse restricted

That is exactly what we have in fuel-menu at the moment. That is wrong
(IMO). Why I think it is wrong to hard code "-updates -security" suffixes
and "main universe multiverse restricted" sections is described in the very
first letter of the ML thread. Again, repos should be independent. There
should not be any assumptions about -updates or something like this. That
is the main topic of the thread.

Regarding to format of the repo data I think the format that is now used by
nailgun [0] (list of dicts) is very convenient and easily extendable. And
we should use this format wherever we need to serialize/de-serialize
repository data (you can think of this format as a part of Fuel internal
communication protocol). We'd better avoid using native formats like apt
sources or yum.conf for passing data between Fuel components because it
requires having complicated (and thus fragile) code to serialize and
de-serialize these data. Native formats should be used only when yum or apt
should be directly configured.

[0]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053


Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 1:56 PM, Aleksandr Mogylchenko <
amogylche...@mirantis.com> wrote:

> There are common practices developed by operating system developers, and
> thousands of people using them every day.
>
> Redefining that experience will bring nothing more but questions and
> misunderstanding, because if someone has questions, instead of hundreds
> already written manuals a person would be forced to go to us.
>
> There is nothing wrong in storing it *internally* in whatever format is
> suitable for Fuel. But UI, in my opinion, should follow practices that
> already exist, not define something new.
>
> And, btw, URIs are not repositories, but just one component:
> https://wiki.debian.org/RepositoryFormat
>
> --
> Aleksandr Mogylchenko
>
>
> > On Dec 11, 2015, at 12:29, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
> >
> > Hey folks -
> >
> > +1 from my side on the idea of having the unified repo format. It will
> > simplify a cross-project contribution. I think we can file a blueprint
> > for 9.0.
> >
> > I have only two questions to discuss:
> >
> > * We need to declare format for RPM repos either.
> > * Shouldn't we use slightly different set of fields for flat Debian
> repos?
> >
> > - Igor
> >
> > On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev <fzhad...@mirantis.com>
> wrote:
> >> Hello Vladimir,
> >>
> >> I definitely agree that using one uri for generating number of repos is
> not
> >> the best solution.
> >> According to Fuel Menu - there was the discussion in gerrit [1] about
> >> repositories format. The first version of my patch implements actually
> your
> >> idea about equality and independence of repositories. It meets
> disagreements
> >> and no one voted for this POV. So I had to change the implementation in
> >> favor to the current version.
> >>
> >> According to this situation I would like to discuss if proposed changes
> are
> >> needed before making new patch. Guys, who took part in the previous
> patch
> >> discussion, please share your opinions.
> >>
> >> [1] https://review.openstack.org/#/c/242646/
> >>
> >> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <
> vkozhuka...@mirantis.com>:
> >>>
> >>> Dear colleagues,
> >>>
> >>> At the moment we have several places where we configure multiple
> rpm/deb
> >>> repositories. Those are:
> >>>
> >>> Web UI (cluster settings tab) where we define repos for cluster
> deployment
> >>> Fuel-menu (bootstrap section) where we define repos for building ubuntu
> >>> bootstrap image
> >>> Fuel-mirror where we define repos that are to be cloned (full or
> par

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go to
any cluster and see Repositories section on the settings tab.

Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 5:46 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> I'd like this module
> https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py
> to be fixed so a user can define several repos independently. This
> particular ML thread is not about internal repo data format, it is not
> about particular format that we expose to end user. This thread is rather
> about flexibility of repo configuration. Whether we expose Fuel internal
> format or native format, UI must be flexible enough to allow a user to
> define repos independently. That is it.
>
> There is no reason to think that repository structure will always follow
> the pattern suite suite-updates suite-security, there is no reason to think
> that sections will always be main, universe, multiverse, restricted, there
> is no reason to think that all suites will be located on the same host.
>
> I am not a big expert in UX. I like what we currently have on Web UI (is
> native format). I don't suggest to change this. I suggest to use something
> similar of what we have on Web UI in our fuel-menu.
>
>
>
> Vladimir Kozhukalov
>
> On Fri, Dec 11, 2015 at 5:10 PM, Alexander Kostrikov <
> akostri...@mirantis.com> wrote:
>
>> Hello, Vladimir.
>> Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap
>> than 'You Get What You See' because system administrator should not learn
>> new standard:
>> http://url trusty main
>> http://anotherurl trusty universe multiverse restricted
>> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>>
>> Can You point to difference between current scheme rpm/deb libraries in
>> Python and 'New Format' If You are talking about their representation in
>> fuel code to understand pros of such format.
>>
>> Like generalization of algorithms in such way:
>> >I'd like to focus on the fact that these repositories should be defined
>> independently (no base url, no base suite, etc.) That makes little sense to
>> speculate about consistency of a particular repository. We only should talk
>> about consistency of the whole list of repositories together.
>>
>>
>> On Fri, Dec 11, 2015 at 2:44 PM, Vladimir Kozhukalov <
>> vkozhuka...@mirantis.com> wrote:
>>
>>> Regarding to UI. Of course, we could provide native format to a user on
>>> UI. Although I don't think it would be much easier to edit, but it is
>>> flexible enough to define something like this:
>>>
>>> http://url trusty main
>>> http://anotherurl trusty universe multiverse restricted
>>> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>>>
>>> While we (for some reasons) limited our UI to define only base url and
>>> base suite. That should be fixed.
>>>
>>>
>>> Vladimir Kozhukalov
>>>
>>> On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <ikalnit...@mirantis.com
>>> > wrote:
>>>
>>>> > Do we really need a custom format? Why can not we use native format
>>>> > for yum.conf and apt.sources files
>>>>
>>>> Because we don't want to parse this format each time we want to verify
>>>> / handle particular component of this format. Moreover, there's no,
>>>> for example, priority in Debian repo format. Priority is used by apt
>>>> preference (not by repo itself).
>>>>
>>>> We're talking about Fuel internal representation, and it would be nice
>>>> to have one internal format across various Fuel projects.
>>>>
>>>>
>>>> > But UI, in my opinion, should follow practices that already exist,
>>>> not define something new.
>>>>
>>>> AFAIU, the idea is to unified internal representation and keep UI as
>>>> close to distributive standards.
>>>>
>>>> On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova
>>>> <afedor...@mirantis.com> wrote:
>>>> > Hi,
>>>> >
>>>> > I agree with the idea of unification for repo configurations, but it
>>>> > looks like we are developing yet another standard.
>>>> >
>>>> > Do we really need a custom format? Why can not we use native format
>>>> > for yum.conf and apt.sources files, and native tooling (all those
>>>> > python bindings, cli utils and so on

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

I'd like this module
https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py
to be fixed so a user can define several repos independently. This
particular ML thread is not about internal repo data format, it is not
about particular format that we expose to end user. This thread is rather
about flexibility of repo configuration. Whether we expose Fuel internal
format or native format, UI must be flexible enough to allow a user to
define repos independently. That is it.

There is no reason to think that repository structure will always follow
the pattern suite suite-updates suite-security, there is no reason to think
that sections will always be main, universe, multiverse, restricted, there
is no reason to think that all suites will be located on the same host.

I am not a big expert in UX. I like what we currently have on Web UI (is
native format). I don't suggest to change this. I suggest to use something
similar of what we have on Web UI in our fuel-menu.



Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 5:10 PM, Alexander Kostrikov <
akostri...@mirantis.com> wrote:

> Hello, Vladimir.
> Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap
> than 'You Get What You See' because system administrator should not learn
> new standard:
> http://url trusty main
> http://anotherurl trusty universe multiverse restricted
> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>
> Can You point to difference between current scheme rpm/deb libraries in
> Python and 'New Format' If You are talking about their representation in
> fuel code to understand pros of such format.
>
> Like generalization of algorithms in such way:
> >I'd like to focus on the fact that these repositories should be defined
> independently (no base url, no base suite, etc.) That makes little sense to
> speculate about consistency of a particular repository. We only should talk
> about consistency of the whole list of repositories together.
>
>
> On Fri, Dec 11, 2015 at 2:44 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Regarding to UI. Of course, we could provide native format to a user on
>> UI. Although I don't think it would be much easier to edit, but it is
>> flexible enough to define something like this:
>>
>> http://url trusty main
>> http://anotherurl trusty universe multiverse restricted
>> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>>
>> While we (for some reasons) limited our UI to define only base url and
>> base suite. That should be fixed.
>>
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>
>>> > Do we really need a custom format? Why can not we use native format
>>> > for yum.conf and apt.sources files
>>>
>>> Because we don't want to parse this format each time we want to verify
>>> / handle particular component of this format. Moreover, there's no,
>>> for example, priority in Debian repo format. Priority is used by apt
>>> preference (not by repo itself).
>>>
>>> We're talking about Fuel internal representation, and it would be nice
>>> to have one internal format across various Fuel projects.
>>>
>>>
>>> > But UI, in my opinion, should follow practices that already exist, not
>>> define something new.
>>>
>>> AFAIU, the idea is to unified internal representation and keep UI as
>>> close to distributive standards.
>>>
>>> On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova
>>> <afedor...@mirantis.com> wrote:
>>> > Hi,
>>> >
>>> > I agree with the idea of unification for repo configurations, but it
>>> > looks like we are developing yet another standard.
>>> >
>>> > Do we really need a custom format? Why can not we use native format
>>> > for yum.conf and apt.sources files, and native tooling (all those
>>> > python bindings, cli utils and so on) which is already developed to
>>> > work with them?
>>> >
>>> > On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky <
>>> ikalnit...@mirantis.com> wrote:
>>> >> Hey folks -
>>> >>
>>> >> +1 from my side on the idea of having the unified repo format. It will
>>> >> simplify a cross-project contribution. I think we can file a blueprint
>>> >> for 9.0.
>>> >>
>>> >> I have only two questions to discuss:
>>> >>
>>> >> * We need to declare format for RPM re

Re: [openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

If there are no any objections, let's do fix fuel-menu ASAP. As Fedor said
this approach was suggested first, but then it was rejected during review
process. It should not be so hard to get it back. Fedor, could you please
confirm that it is possible to do this before SCF? Here is the bug
https://bugs.launchpad.net/fuel/+bug/1525323

Vladimir Kozhukalov

On Fri, Dec 11, 2015 at 5:48 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> BTW, here you can see an example http://demo.fuel-infra.org:8000 Just go
> to any cluster and see Repositories section on the settings tab.
>
> Vladimir Kozhukalov
>
> On Fri, Dec 11, 2015 at 5:46 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> I'd like this module
>> https://github.com/openstack/fuel-menu/blob/master/fuelmenu/modules/bootstrapimg.py
>> to be fixed so a user can define several repos independently. This
>> particular ML thread is not about internal repo data format, it is not
>> about particular format that we expose to end user. This thread is rather
>> about flexibility of repo configuration. Whether we expose Fuel internal
>> format or native format, UI must be flexible enough to allow a user to
>> define repos independently. That is it.
>>
>> There is no reason to think that repository structure will always follow
>> the pattern suite suite-updates suite-security, there is no reason to think
>> that sections will always be main, universe, multiverse, restricted, there
>> is no reason to think that all suites will be located on the same host.
>>
>> I am not a big expert in UX. I like what we currently have on Web UI (is
>> native format). I don't suggest to change this. I suggest to use something
>> similar of what we have on Web UI in our fuel-menu.
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Fri, Dec 11, 2015 at 5:10 PM, Alexander Kostrikov <
>> akostri...@mirantis.com> wrote:
>>
>>> Hello, Vladimir.
>>> Seems nothing is better for end-user in UI/fuel-mirror/image-bootstrap
>>> than 'You Get What You See' because system administrator should not learn
>>> new standard:
>>> http://url trusty main
>>> http://anotherurl trusty universe multiverse restricted
>>> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>>>
>>> Can You point to difference between current scheme rpm/deb libraries in
>>> Python and 'New Format' If You are talking about their representation in
>>> fuel code to understand pros of such format.
>>>
>>> Like generalization of algorithms in such way:
>>> >I'd like to focus on the fact that these repositories should be
>>> defined independently (no base url, no base suite, etc.) That makes little
>>> sense to speculate about consistency of a particular repository. We only
>>> should talk about consistency of the whole list of repositories together.
>>>
>>>
>>> On Fri, Dec 11, 2015 at 2:44 PM, Vladimir Kozhukalov <
>>> vkozhuka...@mirantis.com> wrote:
>>>
>>>> Regarding to UI. Of course, we could provide native format to a user on
>>>> UI. Although I don't think it would be much easier to edit, but it is
>>>> flexible enough to define something like this:
>>>>
>>>> http://url trusty main
>>>> http://anotherurl trusty universe multiverse restricted
>>>> http://yet-another-url trusty-my-favorite-updates my-favorite-section
>>>>
>>>> While we (for some reasons) limited our UI to define only base url and
>>>> base suite. That should be fixed.
>>>>
>>>>
>>>> Vladimir Kozhukalov
>>>>
>>>> On Fri, Dec 11, 2015 at 2:33 PM, Igor Kalnitsky <
>>>> ikalnit...@mirantis.com> wrote:
>>>>
>>>>> > Do we really need a custom format? Why can not we use native format
>>>>> > for yum.conf and apt.sources files
>>>>>
>>>>> Because we don't want to parse this format each time we want to verify
>>>>> / handle particular component of this format. Moreover, there's no,
>>>>> for example, priority in Debian repo format. Priority is used by apt
>>>>> preference (not by repo itself).
>>>>>
>>>>> We're talking about Fuel internal representation, and it would be nice
>>>>> to have one internal format across various Fuel projects.
>>>>>
>>>>>
>>>>> > But UI, in my opinion, should follow practices that already exist,
>>>>

[openstack-dev] [Fuel] Separate master node provisioning and deployment

[Vladimir Kozhukalov]

Dear colleagues,

At the moment part of the Fuel master deployment logic is located in ISO
kickstart file, which is bad. We'd better carefully split provisioning and
deployment stages so as to install base operating system during
provisioning stage and then everything else on the deployment stage. That
would make it possible to deploy Fuel on pre-installed vanilla Centos 7.
Besides, if we have deb packages for all Fuel components it will be easy to
support Fuel deployment on pre-installed Ubuntu and Debian.

We (Fuel build team) are going to do this ASAP [0]. Right now we are on the
stage of writing design spec for the change [1].

Open questions are:
1) Should fuel package have all other fuel packages like nailgun, astute,
etc. as its dependencies? Or maybe it should install only puppet modules
and deployment script that then could be used to deploy everything else?

2) bootstrap_admin_node.sh runs fuelmenu and then puppet to deploy Fuel
components. Should we run this script as post-install script or maybe we
should leave this up to a user to run this script later when fuel package
is already installed?

Anyway, the final goal is to make ISO just one of possible delivery
schemes. Primary delivery approach should be rpm/deb repo, not ISO.

[0]
https://blueprints.launchpad.net/fuel/+spec/separate-fuel-node-provisioning
[1] https://review.openstack.org/#/c/254270/

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

[openstack-dev] [Fuel] Multiple repos UX

[Vladimir Kozhukalov]

Dear colleagues,

At the moment we have several places where we configure multiple rpm/deb
repositories. Those are:

   1. Web UI (cluster settings tab) where we define repos for cluster
   deployment
   2. Fuel-menu (bootstrap section) where we define repos for building
   ubuntu bootstrap image
   3. Fuel-mirror where we define repos that are to be cloned (full or
   partial mirrors)

I'd prefer all these places to provide the same UX. By that I mean that
these components should use the same input data structure like this [0],
i.e. a flat list of fully independent repositories (see an example below).
First repo in the list is supposed to be a base OS repo (i.e. contains base
packages like libc).

[
 {
type: deb,
url: some-url,
section: some-section,
suite: some-suite,
priority: some-priority
  },
  {
type: deb,
url: another-url,
section: another-section,
suite: another-suite,
priority: another-priority
  },
...
]

I'd like to focus on the fact that these repositories should be defined
independently (no base url, no base suite, etc.) That makes little sense to
speculate about consistency of a particular repository. We only should talk
about consistency of the whole list of repositories together.

I'll try to explain. In the real world we usually deal with sets of
repositories which look like this:

http://archive.ubuntu.com/ubuntu/dists/trusty/
http://archive.ubuntu.com/ubuntu/dists/trusty-updates/
http://archive.ubuntu.com/ubuntu/dists/trusty-security/
http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/
http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/
http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/

As you can see these repositories have common hosts and base suites and it
instills us to think that repositories should not be defined separately
which is wrong. This special case does not break the whole approach. It is
just a special case. Repositories are nothing more than just sets of
packages that can depend on each other forming a tree when taken together.
Package relation does matter, not repository location, not suite name.
Parsing package tree for a set of repositories we can easily figure out
whether this set is consistent or not (e.g. python-packetary allows to do
this).

Taking into account the above, I'd say UI should allow a user to define
repositories independently not forcing to use special patterns like suite +
suite-updates + suite-security, not forcing repositories to be located on
the same host. That means we should modify fuel-menu bootstrap section
which currently allows a user to define a base url that is then used to
form a group of repos (base, base-updates, base-security). Besides, it
contradicts to our use case when we put mosX.Y locally on the master node
while mosX.Y-updates and mosX.Y-security are supposed to be available
online.

What do you guys think of that?


[0]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053


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

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

[Vladimir Kozhukalov]

Mike,

Yes, probably the best place to describe further plans is README file. I'll
create a patch.

Vladimir Kozhukalov

On Tue, Dec 1, 2015 at 8:30 PM, Mike Scherbakov <mscherba...@mirantis.com>
wrote:

> Vladimir,
> if you've been behind of this, could you please share further plans in
> separate email thread or (better) provide plans in README in the repo, so
> everyone can be aware of planned changes and can review them too? If you or
> someone else propose a change, please post a link here...
>
> Thanks,
>
> On Tue, Dec 1, 2015 at 6:27 AM Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Thomas,
>>
>> You are right about two independent modules in the repo. That is because
>> the former intention was to get rid of fuel-mirror (and fuel-createmirror)
>> and perestroika and leave only packetary there. Packetary is to be
>> developed so it is able to build not only repositories but  packages as
>> well. So we'll be able to remove perestroika once it is ready. Two major
>> capabilities of fuel-mirror are:
>> 1) create mirror (and partial mirror) and packetary can be used for this
>> instead
>> 2) apply mirror to nailgun (which is rather a matter of python-fuelclient)
>> So fuel-mirror also should be removed in the future to avoid
>> functionality duplication.
>>
>> Those were the reasons not to put them separately. (C) "There can be only
>> one".
>>
>>
>>
>>
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Dec 1, 2015 at 1:25 PM, Thomas Goirand <z...@debian.org> wrote:
>>
>>> On 12/01/2015 09:25 AM, Mike Scherbakov wrote:
>>> >  4. I don't quite understand how repo is organized. I see a lot of
>>> > Python code regarding to fuel-mirror itself and packetary, which is
>>> > used as fuel-mirrors core and being written and maintained mostly
>>> by
>>> > Bulat [5]. There are seem to be bash scripts now related to
>>> > Perestroika, and. I don't quite get how these things relate each to
>>> > other, and if we expect core reviewers to be merging code into both
>>> > Perestroika and Packetary? Unless mission of repo, code gets clear,
>>> > I'd abstain from giving +1...
>>>
>>> Also, why isn't packetary living in its own repository? It seems wrong
>>> to me to have 2 python modules living in the same source repo, unless
>>> they share the same egg-info. It feels weird to have to call setup.py
>>> install twice in the resulting Debian source package. That's not how
>>> things are done elsewhere, and I'd like to avoid special cases, just
>>> because it's fuel...
>>>
>>> Cheers,
>>>
>>> Thomas Goirand (zigo)
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Fox,  this is one of the reasons. There are others listed in my original
letter.

Guys, I have prepared two patches [1] and [2] that can properly deploy the
master node. I still have not got any positive feedback on the spec [3]. My
intention was to wait until Centos 7 feature is merged and then to rebase
my patches, but now it seems too late. FF is tomorrow and my suggestion is
to make these two patches fully compatible with master so as to make it
possible to build ISO both with and without docker containers. Then we can
remove docker after SCF.

[1] https://review.openstack.org/#/c/248649/
[2] https://review.openstack.org/#/c/248650/
[3] https://review.openstack.org/#/c/248814/

Vladimir Kozhukalov

On Mon, Nov 30, 2015 at 11:19 PM, Fox, Kevin M <kevin@pnnl.gov> wrote:

> Is that because of trying to shoehorn docker containers into rpm's though?
> I've never seen anyone else try and use them that way. Maybe they belong in
> a docker repo like the hub or something openstack.org hosted instead?
>
> Thanks,
> Kevin
> 
> From: Igor Kalnitsky [ikalnit...@mirantis.com]
> Sent: Friday, November 27, 2015 1:22 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Fuel] Getting rid of Docker containers on
> the Fuel master node
>
> Hey Vladimir,
>
> Thanks for your effort on doing this job. Unfortunately we have not so
> much time left and FF is coming, so I'm afraid it's become unreal to
> make it before FF. Especially if it takes 2-3 days to fix system
> tests.
>
>
> Andrew,
>
> I had the same opinion some time ago, but it was changed because
> nobody puts effort to fix our Docker experience. Moreover Docker is
> still buggy and we have a plenty of issues such as stale mount points
> for instance. Besides, I don't like our upgrade procedure -
>
> 1. Install fuel-docker-images.rpm
> 2. Load images from installed tarball to Docker
> 3. Re-create containers from new images
>
> Where (2) and (3) are manual steps and breaks idea of "yum update"
> delivery approach.
>
> Thanks,
> Igor
>
> On Wed, Nov 25, 2015 at 9:43 PM, Andrew Woodward <xar...@gmail.com> wrote:
> > 
> > IMO, removing the docker containers is a mistake v.s. fixing them and
> using
> > them properly. They provide an isolation that is necessary (and that we
> > mangle) to make services portable and scaleable. We really should sit
> down
> > and document how we really want all of the services to interact before we
> > rip the containers out.
> >
> > I agree, the way we use containers now still is quite wrong, and brings
> us
> > some negative value, but I'm not sold on stripping them out now just
> because
> > they no longer bring the same upgrades value as before.
> > 
> >
> > My opinion aside, we are rushing into this far to late in the feature
> cycle.
> > Prior to moving forward with this, we need a good QA plan, the spec is
> quite
> > light on that and must receive review and approval from QA. This needs to
> > include an actual testing plan.
> >
> > From the implementation side, we are pushing up against the FF deadline.
> We
> > need to document what our time objectives are for this and when we will
> no
> > longer consider this for 8.0.
> >
> > Lastly, for those that are +1 on the thread here, please review and
> comment
> > on the spec, It's received almost no attention for something with such a
> > large impact.
> >
> > On Tue, Nov 24, 2015 at 4:58 PM Vladimir Kozhukalov
> > <vkozhuka...@mirantis.com> wrote:
> >>
> >> The status is as follows:
> >>
> >> 1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
> >> w/o docker containers
> >> 2) I've not built experimental ISO yet (have been testing and debugging
> >> manually)
> >> 3) There are still some flaws (need better formatting, etc.)
> >> 4) Plan for tomorrow is to build experimental ISO and to begin fixing
> >> system tests and fix the spec.
> >>
> >> [1] https://review.openstack.org/#/c/248649
> >> [2] https://review.openstack.org/#/c/248650
> >>
> >> Vladimir Kozhukalov
> >>
> >> On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov
> >> <vkozhuka...@mirantis.com> wrote:
> >>>
> >>> Colleagues,
> >>>
> >>> I've started working on the change. Here are two patches (fuel-main [1]
> >>> and fuel-library [2]). They are not ready to review (still does not
> work and
> >>> under active development). Changes are not go

Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror

[Vladimir Kozhukalov]

Thomas,

You are right about two independent modules in the repo. That is because
the former intention was to get rid of fuel-mirror (and fuel-createmirror)
and perestroika and leave only packetary there. Packetary is to be
developed so it is able to build not only repositories but  packages as
well. So we'll be able to remove perestroika once it is ready. Two major
capabilities of fuel-mirror are:
1) create mirror (and partial mirror) and packetary can be used for this
instead
2) apply mirror to nailgun (which is rather a matter of python-fuelclient)
So fuel-mirror also should be removed in the future to avoid functionality
duplication.

Those were the reasons not to put them separately. (C) "There can be only
one".





Vladimir Kozhukalov

On Tue, Dec 1, 2015 at 1:25 PM, Thomas Goirand <z...@debian.org> wrote:

> On 12/01/2015 09:25 AM, Mike Scherbakov wrote:
> >  4. I don't quite understand how repo is organized. I see a lot of
> > Python code regarding to fuel-mirror itself and packetary, which is
> > used as fuel-mirrors core and being written and maintained mostly by
> > Bulat [5]. There are seem to be bash scripts now related to
> > Perestroika, and. I don't quite get how these things relate each to
> > other, and if we expect core reviewers to be merging code into both
> > Perestroika and Packetary? Unless mission of repo, code gets clear,
> > I'd abstain from giving +1...
>
> Also, why isn't packetary living in its own repository? It seems wrong
> to me to have 2 python modules living in the same source repo, unless
> they share the same egg-info. It feels weird to have to call setup.py
> install twice in the resulting Debian source package. That's not how
> things are done elsewhere, and I'd like to avoid special cases, just
> because it's fuel...
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

The status is as follows:

1) Fuel-main [1] and fuel-library [2] patches can deploy the master node
w/o docker containers
2) I've not built experimental ISO yet (have been testing and debugging
manually)
3) There are still some flaws (need better formatting, etc.)
4) Plan for tomorrow is to build experimental ISO and to begin fixing
system tests and fix the spec.

[1] https://review.openstack.org/#/c/248649
[2] https://review.openstack.org/#/c/248650

Vladimir Kozhukalov

On Mon, Nov 23, 2015 at 7:51 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Colleagues,
>
> I've started working on the change. Here are two patches (fuel-main [1]
> and fuel-library [2]). They are not ready to review (still does not work
> and under active development). Changes are not going to be huge. Here is a
> spec [3]. Will keep the status up to date in this ML thread.
>
>
> [1] https://review.openstack.org/#/c/248649
> [2] https://review.openstack.org/#/c/248650
> [3] https://review.openstack.org/#/c/248814
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy <
> amarets...@mirantis.com> wrote:
>
>>
>>
>> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
>> wrote:
>>
>>> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
>>> > Hi all,
>>> >
>>> > as you know, Rally runs inside docker on Fuel master node, so docker
>>> > removal (good improvement) is a problem for Rally users.
>>> >
>>> > To solve this, I'm planning to make native Rally installation on Fuel
>>> > master node that is running on CentOS 7,
>>> > and then make a step-by-step instruction how to make this installation.
>>> >
>>> > So I hope docker removal will not make issues for Rally users.
>>>
>>> I believe the most backwards compatible scenario is to keep the docker
>>> installed while removing the fuel-* docker things back to the host OS.
>>> So nothing would prevent user from pulling and running whichever docker
>>> containers he wants to put on the Fuel master node. Makes sense?
>>>
>>>
>> Sounds good
>>
>> __
>> OpenStack Development Mailing 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] CentOS-7 Transition Plan

[Vladimir Kozhukalov]

In fact, we (I and Dmitry) are on the same page of how to merge these two
features (Centos7 and Docker removal). We agreed that Dmitry's feature is
much more complicated and of higher priority. So, Centos 7 should be merged
first and then I'll rebase my patches (mostly supervisor -> systemd).





Vladimir Kozhukalov

On Tue, Nov 24, 2015 at 1:57 AM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Hey Dmitry,
>
> Thank you for your effort. I believe it's a huge step forward that
> opens number of possibilities.
>
> > Every container runs systemd as PID 1 process instead of
> > supervisord or application / daemon.
>
> Taking into account that we're going to drop Docker containers, I
> think it was unnecessary complication of your work.
>
> Please sync-up with Vladimir Kozhukalov, he's working on getting rid
> of containers.
>
> > Every service inside a container is a systemd unit. Container build
> > procedure was modified, scripts setup.sh and start.sh were introduced
> > to be running during building and configuring phases respectively.
>
> Ditto. :)
>
> Thanks,
> Igor
>
> P.S: I wrote the mail and forgot to press "send" button. It looks like
> Oleg is already pointed out that I wanted to.
>
> On Mon, Nov 23, 2015 at 2:37 PM, Oleg Gelbukh <ogelb...@mirantis.com>
> wrote:
> > Please, take into account the plan to drop the containerization of Fuel
> > services:
> >
> > https://review.openstack.org/#/c/248814/
> >
> > --
> > Best regards,
> > Oleg Gelbukh
> >
> > On Tue, Nov 24, 2015 at 12:25 AM, Dmitry Teselkin <
> dtesel...@mirantis.com>
> > wrote:
> >>
> >> Hello,
> >>
> >> We've been working for some time on bringing CentOS-7 to master node,
> >> and now is the time to share and discuss the transition plan.
> >>
> >> First of all, what have been changed:
> >> * Master node itself runs on CentOS-7. Since all the containers share
> >>   the same repo as master node they all have been migrated to CentOS-7
> >>   too. Every container runs systemd as PID 1 process instead of
> >>   supervisord or application / daemon.
> >> * Every service inside a container is a systemd unit. Container build
> >>   procedure was modified, scripts setup.sh and start.sh were introduced
> >>   to be running during building and configuring phases respectively.
> >>   The main reason for this was the fact that many puppet manifests use
> >>   service management commands that require systemd daemon running. This
> >>   also allowed to simplify Dockerfiles by removing all actions to
> >>   setup.sh file.
> >> * We managed to find some bugs in various parts that were fixed too.
> >> * Bootstrap image is also CentOS-7 based. It was updated to better
> >>   support it - some services converted to systemd units and fixes to
> >>   support new network naming schema were made.
> >> * ISO build procedure was updated to reflect changes in CentOS-7
> >>   distribution and to support changes in docker build procedure.
> >> * Many applications was updated (puppet, docker, openstack
> >>   components).
> >> * Docker containers moved to LVM volume to improve performance and get
> >>   rid of annoying warning messages during master node deployment.
> >>   bootstrap_admin_node.sh script was updated to fix some deployment
> >>   issues (e.g. dracut behavior when there are multiple network
> >>   interfaces available) and simplified by removing outdated
> >>   functionality. It was also converted to a "run once" logon script
> >>   instead of being run as a service, primarily because of a way it's
> >>   used.
> >>
> >> As you can see there are a lot of changes were made. Some of them might
> >> be merged into current master if surrounded by conditionals to be
> >> compatible with current master node, but some of them simply can't.
> >>
> >> To simplify the code review process we've splitted CRs that we were
> >> using during active development to  a set of smaller CRs and assigned
> >> the same topic centos7-master-nod to all of them [0].
> >>
> >> So, here is the plan:
> >> * We will put a mark 'Breaks' in every commit message indicating if the
> >>   CR is compatible with current master node. E.g. 'Breaks: centos-6'
> >>   means it can't be merged without breaking things, but 'Breaks:
> >>   nothing' means it OK to merge.
> >> * All the CRs should be reviewed, regardless of their 'breaks' label,
> >

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

[Vladimir Kozhukalov]

ETA:

experimental ISO w/o docker: tonight
spec: tomorrow night



Vladimir Kozhukalov

On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <aurlap...@mirantis.com>
wrote:

> @Vova,
> thanks for bringing this up.
> The new approach without docker containers on master node really has many
> advantages.
>
> @Igor,
> regarding your question, I would say that we have many dependencies from
> containers in CI/CD systems and test's codebase. The test alignment to the
> new implementation won't be easy. In such things we should move forward
> step by step.
> As you know the first step is a spec file, can you give us a link to it?
>
>
> Nastya.
>
> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh <ogelb...@mirantis.com>
> wrote:
>
>> With CentOS7 we will have python2.7 at Fuel Admin node as a default
>> version, I believe.
>>
>> --
>> Best regards,
>> Oleg Gelbukh,
>> Principal Engineer
>> Mirantis
>>
>> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
>> tnurlygaya...@mirantis.com> wrote:
>>
>>> Hi Andrey,
>>>
>>> As far as I remember from the last usage of fuel master node, there was
>>>> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
>>>> hard to launch some application on fuel node without docker (image with
>>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>>> and I can already use py27 from the box?
>>>
>>> We can install docker on master node anyway to run Rally / Tempest or
>>> other test suites and scripts from master node with Python 2.7 or something
>>> also.
>>>
>>> On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin <akuri...@mirantis.com>
>>> wrote:
>>>
>>>> Hi!
>>>> I'm not fuel developer, so opinion below is based on user-view.
>>>> As far as I remember from the last usage of fuel master node, there was
>>>> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
>>>> hard to launch some application on fuel node without docker (image with
>>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>>> and I can already use py27 from the box?
>>>>
>>>> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
>>>> vkozhuka...@mirantis.com> wrote:
>>>>
>>>>> Dear colleagues,
>>>>>
>>>>> As might remember, we introduced Docker containers on the master node
>>>>> a while ago when we implemented first version of Fuel upgrade feature. The
>>>>> motivation behind was to make it possible to rollback upgrade process if
>>>>> something goes wrong.
>>>>>
>>>>> Now we are at the point where we can not use our tarball based upgrade
>>>>> approach any more and those patches that deprecate upgrade tarball has 
>>>>> been
>>>>> already merged. Although it is a matter of a separate discussion, it seems
>>>>> that upgrade process rather should be based on kind of backup and restore
>>>>> procedure. We can backup Fuel data on an external media, then we can
>>>>> install new version of Fuel from scratch and then it is assumed backed up
>>>>> Fuel data can be applied over this new Fuel instance. The procedure itself
>>>>> is under active development, but it is clear that rollback in this case
>>>>> would be nothing more than just restoring from the previously backed up
>>>>> data.
>>>>>
>>>>> As for Docker containers, still there are potential advantages of
>>>>> using them on the Fuel master node, but our current implementation of the
>>>>> feature seems not mature enough to make us benefit from the
>>>>> containerization.
>>>>>
>>>>> At the same time there are some disadvantages like
>>>>>
>>>>>- it is tricky to get logs and other information (for example, rpm
>>>>>-qa) for a service like shotgun which is run inside one of containers.
>>>>>- it is specific UX when you first need to run dockerctl shell
>>>>>{container_name} and then you are able to debug something.
>>>>>- when building IBP image we mount directory from the host file
>>>>>system into mcollective container to make image build faster.
>>>>>- there are config files and some other files which should be
>>>>> 

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

[Vladimir Kozhukalov]

Colleagues,

I've started working on the change. Here are two patches (fuel-main [1] and
fuel-library [2]). They are not ready to review (still does not work and
under active development). Changes are not going to be huge. Here is a spec
[3]. Will keep the status up to date in this ML thread.


[1] https://review.openstack.org/#/c/248649
[2] https://review.openstack.org/#/c/248650
[3] https://review.openstack.org/#/c/248814


Vladimir Kozhukalov

On Mon, Nov 23, 2015 at 3:35 PM, Aleksandr Maretskiy <
amarets...@mirantis.com> wrote:

>
>
> On Mon, Nov 23, 2015 at 2:27 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
> wrote:
>
>> On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
>> > Hi all,
>> >
>> > as you know, Rally runs inside docker on Fuel master node, so docker
>> > removal (good improvement) is a problem for Rally users.
>> >
>> > To solve this, I'm planning to make native Rally installation on Fuel
>> > master node that is running on CentOS 7,
>> > and then make a step-by-step instruction how to make this installation.
>> >
>> > So I hope docker removal will not make issues for Rally users.
>>
>> I believe the most backwards compatible scenario is to keep the docker
>> installed while removing the fuel-* docker things back to the host OS.
>> So nothing would prevent user from pulling and running whichever docker
>> containers he wants to put on the Fuel master node. Makes sense?
>>
>>
> Sounds good
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Bogdan,

>> So, we could only deprecate the docker feature for the 8.0.

What do you mean exactly when saying 'deprecate docker feature'? I can not
even imagine how we can live with and without docker containers at the same
time. Deprecation is usually related to features which directly impact UX
(maybe I am wrong).

Guys,

When you estimate risks of the docker removal, please take into account not
only release deadlines but also the overall product quality. The thing is
that continuing using containers makes it much more complicated (and thus
less stable) to implement new upgrade flow (upgrade tarball can not be used
any more, we need to re-install the host system). Switching from Centos 6
to Centos 7 is also much more complicated with docker. Every single piece
of Fuel system is going to become simpler and easier to support.

Of course, I am not suggesting to jump overboard into cold water without a
life jacket. Transition plan, checklist, green tests, even spec etc. are
assumed without saying (after all, I was not born yesterday). Of course, we
won't merge changes until everything is green. What is the problem to try
to do this and postpone if not ready in time? And please do not confuse
these two cases: switching from plain deployment to containers is
complicated, but switching from docker to plain is much simpler.




Vladimir Kozhukalov

On Fri, Nov 20, 2015 at 6:47 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:

> On 20.11.2015 15:10, Timur Nurlygayanov wrote:
> > Hi team,
> >
> > I think it too late to make such significant changes for MOS 8.0 now,
> > but I'm ok with the idea to remove docker containers in the future
> > releases if our dev team want to do this.
> > Any way, before we will do this, we need to plan how we will perform
> > updates between different releases with and without docker containers,
> > how we will manage requirements and etc. In fact we have a lot of
> > questions and haven't answers, let's prepare the spec for this change,
> > review it, discuss it with developers, users and project management team
> > and if we haven't requirements to keep docker containers on master node
> > let's remove them for the future releases (not in MOS 8.0).
> >
> > Of course, we can fix BVT / SWARM tests and don't use docker images in
> > our test suite (it shouldn't be really hard) but we didn't plan these
> > changes and in fact these changes can affect our estimates for many
> tasks.
>
> I can only add that features just cannot be removed without a
> deprecation period of 1-2 releases.
> So, we could only deprecate the docker feature for the 8.0.
>
> >
> > Thank you!
> >
> >
> > On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov
> > <akostri...@mirantis.com <mailto:akostri...@mirantis.com>> wrote:
> >
> > Hello, Igor.
> >
> > >But I'd like to hear from QA how do we rely on container-based
> > infrastructure? Would it be hard to change our sys-tests in short
> > time?
> >
> > At first glance, system tests are using docker only to fetch logs
> > and run shell commands.
> > Also, docker is used to run Rally.
> >
> > If there is an action to remove docker containers with carefull
> > attention to bvt testing, it would take couple days to fix system
> tests.
> > But time may be highly affected by code freezes and active features
> > merging.
> >
> > QA team is going to have Monday (Nov 23) sync-up - and it is
> > possible to get more exact information from all QA-team.
> >
> > P.S.
> > +1 to remove docker.
> > -1 to remove docker without taking into account deadlines/other
> > features.
> >
> > On Thu, Nov 19, 2015 at 10:27 PM, Igor Kalnitsky
> > <ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>> wrote:
> >
> > Hey guys,
> >
> > Despite the fact I like containers (as deployment unit), we
> > don't use
> > them so. That means I +1 idea to drop containers, just because I
> > believe that would
> >
> > * simplify a lot of things
> > * helps get rid of huge amount of hacks
> > * increase master node deployment
> > * release us from annoying support of upgrades / rollbacks that
> > proved
> > to be non-working well
> >
> > But I'd like to hear from QA how do we rely on container-based
> > infrastructure? Would it be hard to change our sys-tests in short
> > time?
> >
> > Thanks,
> > Igor
> >
> >
> &

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

[Vladimir Kozhukalov]

Dear colleagues,

As might remember, we introduced Docker containers on the master node a
while ago when we implemented first version of Fuel upgrade feature. The
motivation behind was to make it possible to rollback upgrade process if
something goes wrong.

Now we are at the point where we can not use our tarball based upgrade
approach any more and those patches that deprecate upgrade tarball has been
already merged. Although it is a matter of a separate discussion, it seems
that upgrade process rather should be based on kind of backup and restore
procedure. We can backup Fuel data on an external media, then we can
install new version of Fuel from scratch and then it is assumed backed up
Fuel data can be applied over this new Fuel instance. The procedure itself
is under active development, but it is clear that rollback in this case
would be nothing more than just restoring from the previously backed up
data.

As for Docker containers, still there are potential advantages of using
them on the Fuel master node, but our current implementation of the feature
seems not mature enough to make us benefit from the containerization.

At the same time there are some disadvantages like

   - it is tricky to get logs and other information (for example, rpm -qa)
   for a service like shotgun which is run inside one of containers.
   - it is specific UX when you first need to run dockerctl shell
   {container_name} and then you are able to debug something.
   - when building IBP image we mount directory from the host file system
   into mcollective container to make image build faster.
   - there are config files and some other files which should be shared
   among containers which introduces unnecessary complexity to the whole
   system.
   - our current delivery approach assumes we wrap into rpm/deb packages
   every single piece of the Fuel system. Docker images are not an exception.
   And as far as they depend on other rpm packages we forced to build
   docker-images rpm package using kind of specific build flow. Besides this
   package is quite big (300M).
   - I'd like it to be possible to install Fuel not from ISO but from RPM
   repo on any rpm based distribution. But it is double work to support both
   Docker based and package based approach.

Probably some of you can give other examples. 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.

As far as there is nothing new here, we just need to use our old site.pp
(with minimal modifications), it looks like it is possible to implement
this during 8.0 release cycle. If there are no principal objections, please
give me a chance to do this ASAP (during 8.0), I know it is a huge risk for
the release, but still I think I can do this.




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

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

[Vladimir Kozhukalov]

Looks like most people thing that building backup/re-install approach is
more viable. So, we certainly need to invent completely new upgrade from
and thus my suggestion is disable building/testing upgrade tarball right
now, because anyway it makes no sense.


Vladimir Kozhukalov

On Fri, Nov 6, 2015 at 8:21 PM, Vladimir Kuklin <vkuk...@mirantis.com>
wrote:

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

[openstack-dev] [Fuel] Master node upgrade

[Vladimir Kozhukalov]

Dear colleagues,

At the moment I'm working on deprecating Fuel upgrade tarball. Currently,
it includes the following:

* RPM repository (upstream + mos)
* DEB repository (mos)
* openstack.yaml
* version.yaml
* upgrade script itself (+ virtualenv)

Apart from upgrading docker containers this upgrade script makes copies of
the RPM/DEB repositories and puts them on the master node naming these
repository directories depending on what is written in openstack.yaml and
version.yaml. My plan was something like:

1) deprecate version.yaml (move all fields from there to various places)
2) deliver openstack.yaml with fuel-openstack-metadata package
3) do not put new repos on the master node (instead we should use online
repos or use fuel-createmirror to make local mirrors)
4) deliver fuel-upgrade package (throw away upgrade virtualenv)

Then UX was supposed to be roughly like:

1) configure /etc/yum.repos.d/nailgun.repo (add new RPM MOS repo)
2) yum install fuel-upgrade
3) /usr/bin/fuel-upgrade (script was going to become lighter, because there
should have not be parts coping RPM/DEB repos)

However, it turned out that Fuel 8.0 is going to be run on Centos 7 and it
is not enough to just do things which we usually did during upgrades. Now
there are two ways to upgrade:
1) to use the official Centos upgrade script for upgrading from 6 to 7
2) to backup the master node, then reinstall it from scratch and then apply
backup

Upgrade team is trying to understand which way is more appropriate.
Regarding to my tarball related activities, I'd say that this package based
upgrade approach can be aligned with (1) (fuel-upgrade would use official
Centos upgrade script as a first step for upgrade), but it definitely can
not be aligned with (2), because it assumes reinstalling the master node
from scratch.

Right now, I'm finishing the work around deprecating version.yaml and my
further steps would be to modify fuel-upgrade script so it does not copy
RPM/DEB repos, but those steps make little sense taking into account Centos
7 feature.

Colleagues, let's make a decision about how we are going to upgrade the
master node ASAP. Probably my tarball related work should be reduced to
just throwing tarball away.


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

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

[Vladimir Kozhukalov]

Dear colleagues,

I'm glad to announce that network-checker is a separate project now. All
related patches have been merged. Thanks everyone for your efforts to make
this happen.

Vladimir Kozhukalov

On Thu, Oct 29, 2015 at 6:42 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> We still can not say that network-checker is a separate project now. I'm
> still working on related issues. Current status is
>
> Network-checker
>
>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506896
>- project-config patch https://review.openstack.org/235822 (DONE)
>- pypi (DONE)
>- run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
>- rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/12923 (DONE)
>- label jenkins slaves for verification (DONE)
>- directory freeze (DONE)
>- prepare upstream (DONE)
>- wait for project-config patch to be merged (DONE)
>- .gitreview https://review.openstack.org/#/c/238500/ (DONE)
>- .gitignore https://review.openstack.org/#/c/238519/ (ON REVIEW)
>- custom jobs parameters https://review.fuel-infra.org/13272 (DONE)
>- fix core group (DONE)
>- fuel-main
>   - fuel-main: use network-checker repository
>   https://review.openstack.org/238992 (ON REVIEW)
>   - fuel-menu: rename nailgun-net-check -> network-checker
>   https://review.openstack.org/#/c/240225 (ON REVIEW)
>   - network-checker: fix package spec
>   https://review.openstack.org/#/c/240191/ (ON REVIEW)
>- packaging-ci  https://review.fuel-infra.org/13181 (DONE)
>- deprecate network_checker directory
>https://review.openstack.org/23 (ON REVIEW) (once fuel-main patch
>is merged)
>- fix unit tests https://review.openstack.org/#/c/239425/ (DONE)
>- libpcap-dev package and fix tests (patches have been merged but not
>deployed yet)
>   - https://review.openstack.org/#/c/239421/ openstack-ci libpcap-dev
>   package (DONE)
>   - https://review.openstack.org/239463 openstack-ci libpcap-dev
>   package for puppet (DONE)
>   - https://review.fuel-infra.org/13173 fuel-ci libpcap-dev package
>   (DONE)
>- remove old nailgun-net-check package (TODO)
>
> Network-checker tests are still red because libpcap-dev package is not
> installed both on Openstack CI and on Fuel CI.
>
> If you can help to review those patches which are (ON REVIEW), please help.
>
>
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 6:45 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> As you might know I'm working on splitting multiproject fuel-web
>> repository into several sub-projects. network_checker is one of directories
>> that are to be moved to a separate git project.
>>
>> Checklist for this to happen is as follows:
>>
>>
>>- Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506896
>>- project-config patch https://review.openstack.org/235822 (ON REVIEW)
>>- pypi
>>https://pypi.python.org/pypi?%3Aaction=pkg_edit=Network-checker
>>(DONE)
>>- run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
>>- rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
>>- fuel-ci verification jobs https://review.fuel-infra.org/12923 (ON
>>REVIEW)
>>- label jenkins slaves for verification jobs (ci team)
>>- directory freeze (WE ARE HERE)
>>- prepare upstream (TODO)
>>- project-config (ON REVIEW)
>>- fuel-main patch (TODO)
>>- packaging-ci patch (TODO)
>>- deprecate network_checker directory (TODO)
>>
>>
>> Now we are at the point where we need to freeze fuel-web/network_checker
>> directory. So, I'd like to announce code freeze for this directory and all
>> patches that make changes in the directory and are currently on review will
>> need to be backported to the new git repository.
>>
>>
>>
>> Vladimir Kozhukalov
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Dear colleagues,

We still can not say that network-checker is a separate project now. I'm
still working on related issues. Current status is

Network-checker

   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506896
   - project-config patch https://review.openstack.org/235822 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12923 (DONE)
   - label jenkins slaves for verification (DONE)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - wait for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/#/c/238500/ (DONE)
   - .gitignore https://review.openstack.org/#/c/238519/ (ON REVIEW)
   - custom jobs parameters https://review.fuel-infra.org/13272 (DONE)
   - fix core group (DONE)
   - fuel-main
  - fuel-main: use network-checker repository
  https://review.openstack.org/238992 (ON REVIEW)
  - fuel-menu: rename nailgun-net-check -> network-checker
  https://review.openstack.org/#/c/240225 (ON REVIEW)
  - network-checker: fix package spec
  https://review.openstack.org/#/c/240191/ (ON REVIEW)
   - packaging-ci  https://review.fuel-infra.org/13181 (DONE)
   - deprecate network_checker directory https://review.openstack.org/23
   (ON REVIEW) (once fuel-main patch is merged)
   - fix unit tests https://review.openstack.org/#/c/239425/ (DONE)
   - libpcap-dev package and fix tests (patches have been merged but not
   deployed yet)
  - https://review.openstack.org/#/c/239421/ openstack-ci libpcap-dev
  package (DONE)
  - https://review.openstack.org/239463 openstack-ci libpcap-dev
  package for puppet (DONE)
  - https://review.fuel-infra.org/13173 fuel-ci libpcap-dev package
  (DONE)
   - remove old nailgun-net-check package (TODO)

Network-checker tests are still red because libpcap-dev package is not
installed both on Openstack CI and on Fuel CI.

If you can help to review those patches which are (ON REVIEW), please help.



Vladimir Kozhukalov

On Tue, Oct 20, 2015 at 6:45 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> As you might know I'm working on splitting multiproject fuel-web
> repository into several sub-projects. network_checker is one of directories
> that are to be moved to a separate git project.
>
> Checklist for this to happen is as follows:
>
>
>- Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506896
>- project-config patch https://review.openstack.org/235822 (ON REVIEW)
>- pypi
>https://pypi.python.org/pypi?%3Aaction=pkg_edit=Network-checker
>(DONE)
>- run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
>- rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/12923 (ON
>REVIEW)
>- label jenkins slaves for verification jobs (ci team)
>- directory freeze (WE ARE HERE)
>- prepare upstream (TODO)
>- project-config (ON REVIEW)
>- fuel-main patch (TODO)
>- packaging-ci patch (TODO)
>- deprecate network_checker directory (TODO)
>
>
> Now we are at the point where we need to freeze fuel-web/network_checker
> directory. So, I'd like to announce code freeze for this directory and all
> patches that make changes in the directory and are currently on review will
> need to be backported to the new git repository.
>
>
>
> Vladimir Kozhukalov
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Dear colleagues,

I am glad to announce that since now shotgun is a separate project.
fuel-web/shotgun directory has been deprecated. There is yet another patch
that has not been merged https://review.openstack.org/238525 (adds
.gitignore file to the new shotgun repo). Please review it.

Shotgun

   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506894
   - project-config patch https://review.openstack.org/235355 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/235368 (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235382/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12872 (DONE)
   - label jenkins slaves for verification (DONE)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - waiting for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/238476 (DONE)
   - .gitignore https://review.openstack.org/238525 (ON REVIEW)
   - custom jobs parameters https://review.fuel-infra.org/13209 (DONE)
   - fix core group (DONE)
   - fuel-main https://review.openstack.org/#/c/238953/ (DONE)
   - packaging-ci  https://review.fuel-infra.org/13181 (DONE)
   - MAINTAINERS https://review.openstack.org/239410 (DONE)
   - deprecate shotgun directory https://review.openstack.org/239407 (DONE)
   - fix verify-fuel-web-docs job (it installs shotgun for some reason)
   https://review.fuel-infra.org/#/c/13194/ (DONE)
   - remove old shotgun package (DONE)



Vladimir Kozhukalov

On Wed, Oct 21, 2015 at 2:46 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> As you might know I'm working on splitting multiproject fuel-web
> repository into several sub-projects. Shotgun is one of directories that
> are to be moved to a separate git project.
>
> Checklist for this to happen is as follows:
>
>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506894
>- project-config patch  https://review.openstack.org/#/c/235355 (ON
>REVIEW)
>- pypi project
>https://pypi.python.org/pypi?%3Aaction=pkg_edit=Shotgun (DONE)
>- run_tests.sh  https://review.openstack.org/235368 (DONE)
>- rpm/deb specs  https://review.openstack.org/#/c/235382 (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/#/c/12872/ (ON
>REVIEW)
>- label jenkins slaves for verification jobs (ci team)
>- directory freeze (WE ARE HERE)
>- prepare upstream (TODO)
>- waiting for project-config patch to be merged (ON REVIEW)
>- fuel-main patch (TODO)
>- packaging-ci patch (TODO)
>- deprecate fuel-web/shotgun directory (TODO)
>
> Now we are at the point where we need to freeze fuel-web/shotgun
> directory. So, I'd like to announce code freeze for this directory and all
> patches that make changes in the directory and are currently on review will
> need to be backported to the new git repository.
>
> Vladimir Kozhukalov
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Vladimir Kozhukalov]

Dear colleagues,

I am glad to announce that fuel-web/fuelmenu directory has been deprecated.
Since now fuel-menu is a separate project.

Fuel-menu

   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
   - label jenkins slaves for verification (DONE)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - waiting for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/#/c/238434/ (DONE)
   - .gitignore https://review.openstack.org/238528 (DONE)
   - custom jobs parameters https://review.fuel-infra.org/13088 (DONE)
   - fix core group (DONE)
   - fuel-main https://review.openstack.org/#/c/238459/ (DONE)
   - packaging-ci https://review.fuel-infra.org/13181 (DONE)
   - MAINTAINERS https://review.openstack.org/238976 (DONE)
   - deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
   (DONE)
   - remove old fuelmenu package (DONE???)




Vladimir Kozhukalov

On Fri, Oct 23, 2015 at 7:06 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> I'd like to update the status of the activity (moving fuelmenu to a
> separate repo).
>
>
>- Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
>- project-config patch https://review.openstack.org/#/c/235177 (DONE)
>- pypi (DONE)
>- run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>- rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>- fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
>- label jenkins slaves for verification (TODO CI-team)
>- directory freeze (DONE)
>- prepare upstream (DONE)
>- waiting for project-config patch to be merged (DONE)
>- .gitreview https://review.openstack.org/#/c/238434/ (DONE)
>- .gitignore https://review.openstack.org/238528 (ON REVIEW)
>- custom jobs parameters https://review.fuel-infra.org/13088 (ON
>REVIEW)
>- fix core group (DONE)
>- fuel-main https://review.openstack.org/#/c/238459/ (ON REVIEW)
>- packaging-ci (TODO)
>- MAINTAINERS https://review.openstack.org/238976 (ON REVIEW)
>- deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
>(ON REVIEW)
>
> There are still some patches on review that you can help to get merged.
>
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 7:05 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Igor,
>>
>> Thank you for your help. I'd say ETA is today/tomorrow and depends on how
>> quickly this project-config patch [1] will be reviewed and merged. I'll ask
>> openstack-infra guys to do this ASAP.
>>
>> [1] https://review.openstack.org/#/c/235177
>>
>> Vladimir Kozhukalov
>>
>> On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
>> wrote:
>>
>>> Hey Vladimir,
>>>
>>> That's awesome news. I blocked all fuelmenu patches [1] with a link to
>>> this thread. So don't worry, we won't merge them accidentally.
>>>
>>> BTW, could you provide any ETA when moving will be done?
>>>
>>> [1]
>>> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>>>
>>> Thanks,
>>> Igor
>>>
>>> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
>>> <vkozhuka...@mirantis.com> wrote:
>>> > Dear colleagues,
>>> >
>>> > As you might know I'm working on splitting multiproject fuel-web
>>> repository
>>> > into several sub-projects. Fuelmenu is one of directories that are to
>>> be
>>> > moved to a separate git project.
>>> >
>>> > Checklist for this to happen is as follows:
>>> >
>>> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
>>> > project-config patch https://review.openstack.org/#/c/235177 (ON
>>> REVIEW
>>> > WORKFLOW -1)
>>> > pypi project
>>> https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu
>>> > (DONE)
>>> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>>> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>>> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
>>> REVIEW)
>>> > label jenkins slave

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

[Vladimir Kozhukalov]

Dear colleagues,

I'd like to update the status of the activity (moving fuelmenu to a
separate repo).


   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (DONE)
   - pypi (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (DONE)
   - label jenkins slaves for verification (TODO CI-team)
   - directory freeze (DONE)
   - prepare upstream (DONE)
   - waiting for project-config patch to be merged (DONE)
   - .gitreview https://review.openstack.org/#/c/238434/ (DONE)
   - .gitignore https://review.openstack.org/238528 (ON REVIEW)
   - custom jobs parameters https://review.fuel-infra.org/13088 (ON REVIEW)
   - fix core group (DONE)
   - fuel-main https://review.openstack.org/#/c/238459/ (ON REVIEW)
   - packaging-ci (TODO)
   - MAINTAINERS https://review.openstack.org/238976 (ON REVIEW)
   - deprecate fuelmenu directory https://review.openstack.org/#/c/238972/
   (ON REVIEW)

There are still some patches on review that you can help to get merged.


Vladimir Kozhukalov

On Tue, Oct 20, 2015 at 7:05 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Igor,
>
> Thank you for your help. I'd say ETA is today/tomorrow and depends on how
> quickly this project-config patch [1] will be reviewed and merged. I'll ask
> openstack-infra guys to do this ASAP.
>
> [1] https://review.openstack.org/#/c/235177
>
> Vladimir Kozhukalov
>
> On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
> wrote:
>
>> Hey Vladimir,
>>
>> That's awesome news. I blocked all fuelmenu patches [1] with a link to
>> this thread. So don't worry, we won't merge them accidentally.
>>
>> BTW, could you provide any ETA when moving will be done?
>>
>> [1]
>> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>>
>> Thanks,
>> Igor
>>
>> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
>> <vkozhuka...@mirantis.com> wrote:
>> > Dear colleagues,
>> >
>> > As you might know I'm working on splitting multiproject fuel-web
>> repository
>> > into several sub-projects. Fuelmenu is one of directories that are to be
>> > moved to a separate git project.
>> >
>> > Checklist for this to happen is as follows:
>> >
>> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
>> > project-config patch https://review.openstack.org/#/c/235177 (ON REVIEW
>> > WORKFLOW -1)
>> > pypi project
>> https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu
>> > (DONE)
>> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
>> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
>> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
>> REVIEW)
>> > label jenkins slaves for verification jobs (ci team)
>> > directory freeze (WE ARE HERE)
>> > prepare upstream (TODO)
>> > project-config (ON REVIEW)
>> > fuel-main patch (TODO)
>> > packaging-ci patch (TODO)
>> > deprecate fuel-web/fuelmenu directory (TODO)
>> >
>> > Now we are at the point where we need to freeze fuel-web/fuelmenu
>> directory.
>> > So, I'd like to announce code freeze for this directory and all patches
>> that
>> > make changes in the directory and are currently on review will need to
>> be
>> > backported to the new git repository.
>> >
>> >
>> > Vladimir Kozhukalov
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing 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] shotgun code freeze

[Vladimir Kozhukalov]

Dear colleagues,

As you might know I'm working on splitting multiproject fuel-web repository
into several sub-projects. Shotgun is one of directories that are to be
moved to a separate git project.

Checklist for this to happen is as follows:

   - Launchpad bug https://bugs.launchpad.net/fuel/+bug/1506894
   - project-config patch  https://review.openstack.org/#/c/235355 (ON
   REVIEW)
   - pypi project
   https://pypi.python.org/pypi?%3Aaction=pkg_edit=Shotgun (DONE)
   - run_tests.sh  https://review.openstack.org/235368 (DONE)
   - rpm/deb specs  https://review.openstack.org/#/c/235382 (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/#/c/12872/ (ON
   REVIEW)
   - label jenkins slaves for verification jobs (ci team)
   - directory freeze (WE ARE HERE)
   - prepare upstream (TODO)
   - waiting for project-config patch to be merged (ON REVIEW)
   - fuel-main patch (TODO)
   - packaging-ci patch (TODO)
   - deprecate fuel-web/shotgun directory (TODO)

Now we are at the point where we need to freeze fuel-web/shotgun directory.
So, I'd like to announce code freeze for this directory and all patches
that make changes in the directory and are currently on review will need to
be backported to the new git repository.

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

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

[Vladimir Kozhukalov]

Igor,

Thank you for your help. I'd say ETA is today/tomorrow and depends on how
quickly this project-config patch [1] will be reviewed and merged. I'll ask
openstack-infra guys to do this ASAP.

[1] https://review.openstack.org/#/c/235177

Vladimir Kozhukalov

On Tue, Oct 20, 2015 at 6:39 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Hey Vladimir,
>
> That's awesome news. I blocked all fuelmenu patches [1] with a link to
> this thread. So don't worry, we won't merge them accidentally.
>
> BTW, could you provide any ETA when moving will be done?
>
> [1]
> https://review.openstack.org/#/q/project:openstack/fuel-web+file:%255Efuelmenu.*+status:open,n,z
>
> Thanks,
> Igor
>
> On Tue, Oct 20, 2015 at 5:58 PM, Vladimir Kozhukalov
> <vkozhuka...@mirantis.com> wrote:
> > Dear colleagues,
> >
> > As you might know I'm working on splitting multiproject fuel-web
> repository
> > into several sub-projects. Fuelmenu is one of directories that are to be
> > moved to a separate git project.
> >
> > Checklist for this to happen is as follows:
> >
> > Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
> > project-config patch https://review.openstack.org/#/c/235177 (ON REVIEW
> > WORKFLOW -1)
> > pypi project
> https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu
> > (DONE)
> > run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
> > rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
> > fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
> REVIEW)
> > label jenkins slaves for verification jobs (ci team)
> > directory freeze (WE ARE HERE)
> > prepare upstream (TODO)
> > project-config (ON REVIEW)
> > fuel-main patch (TODO)
> > packaging-ci patch (TODO)
> > deprecate fuel-web/fuelmenu directory (TODO)
> >
> > Now we are at the point where we need to freeze fuel-web/fuelmenu
> directory.
> > So, I'd like to announce code freeze for this directory and all patches
> that
> > make changes in the directory and are currently on review will need to be
> > backported to the new git repository.
> >
> >
> > Vladimir Kozhukalov
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] network_checker code freeze

[Vladimir Kozhukalov]

Dear colleagues,

As you might know I'm working on splitting multiproject fuel-web repository
into several sub-projects. network_checker is one of directories that are
to be moved to a separate git project.

Checklist for this to happen is as follows:


   - Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506896
   - project-config patch https://review.openstack.org/235822 (ON REVIEW)
   - pypi
   https://pypi.python.org/pypi?%3Aaction=pkg_edit=Network-checker
   (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235829/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235966/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12923 (ON
   REVIEW)
   - label jenkins slaves for verification jobs (ci team)
   - directory freeze (WE ARE HERE)
   - prepare upstream (TODO)
   - project-config (ON REVIEW)
   - fuel-main patch (TODO)
   - packaging-ci patch (TODO)
   - deprecate network_checker directory (TODO)


Now we are at the point where we need to freeze fuel-web/network_checker
directory. So, I'd like to announce code freeze for this directory and all
patches that make changes in the directory and are currently on review will
need to be backported to the new git repository.



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

[openstack-dev] [Fuel] fuelmenu code freeze

[Vladimir Kozhukalov]

Dear colleagues,

As you might know I'm working on splitting multiproject fuel-web repository
into several sub-projects. Fuelmenu is one of directories that are to be
moved to a separate git project.

Checklist for this to happen is as follows:

   - Launchpad bug: https://bugs.launchpad.net/fuel/+bug/1506885
   - project-config patch https://review.openstack.org/#/c/235177 (ON
   REVIEW WORKFLOW -1)
   - pypi project
   https://pypi.python.org/pypi?%3Aaction=pkg_edit=Fuel-menu (DONE)
   - run_tests.sh https://review.openstack.org/#/c/235243/ (DONE)
   - rpm/deb specs https://review.openstack.org/#/c/235273/ (DONE)
   - fuel-ci verification jobs https://review.fuel-infra.org/12865 (ON
   REVIEW)
   - label jenkins slaves for verification jobs (ci team)
   - directory freeze (WE ARE HERE)
   - prepare upstream (TODO)
   - project-config (ON REVIEW)
   - fuel-main patch (TODO)
   - packaging-ci patch (TODO)
   - deprecate fuel-web/fuelmenu directory (TODO)

Now we are at the point where we need to freeze fuel-web/fuelmenu
directory. So, I'd like to announce code freeze for this directory and all
patches that make changes in the directory and are currently on review will
need to be backported to the new git repository.


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

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

[Vladimir Kozhukalov]

> Vladimir's proposal was to use smth similar to MiniCD

Just to clarify. My proposal is to remove DEB MOS repo from the master node
by default and thus from the ISO. That is it.
My proposal does not assume having internet connection during installing
the master node. Fuel RPM packages together with their dependencies are
still there on ISO, thus the master node can be installed w/o internet
connection. Cloud/OpenStack can not be deployed out of the box anyway. It
is because we don't put Ubuntu upstream on ISO. Anyway a user is forced to
make Ubuntu upstream mirror available on the master node (cloning it
locally or via internet connection).

IMO, Fuel in this case is like a browser or bittorrent client. Packages are
available on Linux DVDs but it makes little sense to use them w/o internet
connection.


Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday <yorik@gmail.com> wrote:

> Hello, thread!
>
> First let me address some of the very good points Alex raised in his email.
>
> On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz <aschu...@mirantis.com>
> wrote:
>
>> Fair enough, I just wanted to raise the UX issues around these types of
>> things as they should go into the decision making process.
>>
>
> UX issues is what we definitely should address even for ourselves: number
> of things that need to happen to deploy Master with just one small change
> is enormous.
>
>
>> Let me explain why I think having local MOS mirror by default is bad:
>>> 1) I don't see any reason why we should treat MOS  repo other way than
>>> all other online repos. A user sees on the settings tab the list of repos
>>> one of which is local by default while others are online. It can make user
>>> a little bit confused, can't it? A user can be also confused by the fact,
>>> that some of the repos can be cloned locally by fuel-createmirror while
>>> others can't. That is not straightforward, NOT fuel-createmirror UX.
>>>
>>
>> I agree. The process should be the same and it should be just another
>> repo. It doesn't mean we can't include a version on an ISO as part of a
>> release.  Would it be better to provide the mirror on the ISO but not have
>> it enabled by default for a release so that we can gather user feedback on
>> this? This would include improved documentation and possibly allowing a
>> user to choose their preference so we can collect metrics?
>>
>
> I think instead of relying on average user of spherical Fuel we should let
> user decide what goes to ISO.
>
> 2) Having local MOS mirror by default makes things much more convoluted.
>>> We are forced to have several directories with predefined names and we are
>>> forced to manage these directories in nailgun, in upgrade script, etc. Why?
>>> 3) When putting MOS mirror on ISO, we make people think that ISO is
>>> equal to MOS, which is not true. It is possible to implement really
>>> flexible delivery scheme, but we need to think of these things as they are
>>> independent.
>>>
>>
>> I'm not sure what you mean by this. Including a point in time copy on an
>> ISO as a release is a common method of distributing software. Is this a
>> messaging thing that needs to be addressed? Perhaps I'm not familiar with
>> people referring to the ISO as being MOS.
>>
>
> It is so common that some people think it's very broken. But we can fix
> that.
>
> For large users it is easy to build custom ISO and put there what they
>>> need but first we need to have simple working scheme clear for everyone. I
>>> think dealing with all repos the same way is what is gonna makes things
>>> simpler.
>>>
>>
>> Who is going to build a custom ISO? How does one request that? What
>> resources are consumed by custom ISO creation process/request? Does this
>> scale?
>>
>
> How about user building ISO on one's workstation?
>
> This thread is not about internet connectivity, it is about aligning
>>> things.
>>>
>>
>> You are correct in that this thread is not explicitly about internet
>> connectivity, but they are related. Any changes to remove a local
>> repository and only provide an internet based solution makes internet
>> connectivity something that needs to be included in the discussion.  I just
>> want to make sure that we properly evaluate this decision based on end user
>> feedback not because we don't want to manage this from a developer
>> standpoint.
>>
>
> We can use Internet connectivity not only in target DC.
>
> Now what do I mean by all that? Let's make Fuel distribution that's easier
> to develop a

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

[Vladimir Kozhukalov]

Guys,

I really appreciate your opinions on whether Fuel should be all inclusive
or not. But the original topic of this thread is different. I personally
think that in 2015 it is not a big deal to make the master node able to
access any online host (even taking into account paranoid security
policies). It is just a matter of network engineering. But it is completely
out of the scope. What I am suggesting is to align the way how we treat
different repos, whether upstream or MOS. What I am working on right now is
I am trying to make Fuel build and delivery approach really flexible. That
means we need to have as little non-standard ways/hacks/approaches/options
as possible.

> Why can't we make this optional in the build system? It should be easy to
implement, is not it?

That is exactly what I am trying to do (make it optional). But I don't want
it to be yet another boolean variable for this particular thing (MOS repo).
We have working approach for dealing with repos. Repos can either online or
local mirrors. We have a tool for making local mirrors (fuel-createmirror).
Even if we put MOS on the ISO, a user still can not deploy OpenStack,
because he/she still needs upstream to be available. Anyway, the user is
still forced to do some additional actions. Again, we have plans to improve
the quality and UX of fuel-createmirror.

Yet another thing I don't want to be on the master node is a bunch of MOS
repos directories named like
/var/www/nailgun/2015.1-7.0
/var/www/nailgun/2014.4-6.1
with links like
/var/www/nailgun/ubuntu -> /var/www/nailgun/2015.1-7.0
What does this link mean? Even Fuel developers can be confused. It is scary
to imagine what users think of it :-) Why should Nailgun and upgrade script
manage that kind of storage in this exact kind of format? A long time ago
people invented RPM/DEB repositories, tools to manage them and structure
for versioning them. We have Perestoika for that and we have plans to put
all package/mirror related tools in one place (
github.com/stackforge/fuel-mirror) and make all these tools available out
of Fuel CI. So, users will be able to easily build their own packages,
clone necessary repos and manage them in the way which is standard in the
industry. However, it is out of the scope of the letter.

I also don't like the idea of putting MOS repo on the ISO by default
because it encourages people thing that ISO is the way of distributing MOS.
ISO should be nothing more than just a way of installing Fuel from scratch.
MOS should be distributed via MOS repos. Fuel is available as RPM package
in RPM MOS repo.







Vladimir Kozhukalov

On Thu, Sep 10, 2015 at 1:18 PM, Igor Kalnitsky <ikalnit...@mirantis.com>
wrote:

> Mike,
>
> > still not exactly true for some large enterprises. Due to all the
> security, etc.,
> > there are sometimes VPNs / proxies / firewalls with very low throughput.
>
> It's their problem, and their policies. We can't and shouldn't handle
> all possible cases. If some enterprise has "no Internet" policy, I bet
> it won't be a problem for their IT guys to create an intranet mirror
> for MOS packages. Moreover, I also bet they do have a mirror for
> Ubuntu or other Linux distributive. So it basically about approach how
> to consume our mirrors.
>
> On Thu, Sep 10, 2015 at 12:30 PM, Vladimir Kuklin <vkuk...@mirantis.com>
> wrote:
> > Folks
> >
> > I think, Mike is completely right here - we need an option to build
> > all-in-one ISO which can be tried-out/deployed unattendedly without
> internet
> > access. Let's let a user make a choice what he wants, not push him into
> > embarassing situation. We still have many parts of Fuel which make
> choices
> > for user that cannot be overriden. Let's not pretend that we know more
> than
> > user does about his environment.
> >
> > On Thu, Sep 10, 2015 at 10:33 AM, Oleg Gelbukh <ogelb...@mirantis.com>
> > wrote:
> >>
> >> The reason people want offline deployment feature is not because of poor
> >> connection, but rather the enterprise intranets where getting subnet
> with
> >> external access sometimes is a real pain in various body parts.
> >>
> >> --
> >> Best regards,
> >> Oleg Gelbukh
> >>
> >> On Thu, Sep 10, 2015 at 8:52 AM, Igor Kalnitsky <
> ikalnit...@mirantis.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> I agree with Vladimir - the idea of online repos is a right way to
> >>> move. In 2015 I believe we can ignore this "poor Internet connection"
> >>> reason, and simplify both Fuel and UX. Moreover, take a look at Linux
> >>> distributives - most of them fetch needed packages from the Internet
> >>> during installation, not fr