[openstack-dev] [Fuel] Mitaka SCF is coming. Here is bugs status for python and library

[Dmitry Pyzhov]

Guys, we have a soft code freeze it two days. Here is our status for bugs
with medium, low and wishlist priorities. 29 bugs are already moved

to the Newton release.

Oo 6sh of April we'll move to the Newton release:
98 bugs in python

and 25 in library

.
81 bugs marked as feature requests

in
python and 18 in library

.
12 bugs in 

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Dmitry Pyzhov]

Anastasia,

we are going to invest one more day in investigation of high priority bug,
we cannot reproduce it at the moment. I don't think that we should fix
medium bugs in feature that soon will be deprecated.

On Fri, Mar 25, 2016 at 3:54 PM, Anastasia Urlapova 
wrote:

> Dima,
> if we want to deprecate UI logs in 10.0, it doesn't mean that we shouldn't
> fix issues in 9.0.
>
> Thank you!
>
>
> Nastya.
>
> On Fri, Mar 25, 2016 at 3:31 PM, Dmitry Pyzhov 
> wrote:
>
>> As we are going to deprecate logs on UI I'm going to mark following bugs
>> as "won't fix". Any objections?
>> High priority bug:
>> https://bugs.launchpad.net/fuel/+bug/1553170
>> Medium priority:
>> https://bugs.launchpad.net/fuel/+bug/1554546
>> https://bugs.launchpad.net/fuel/+bug/1539508
>>
>> On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko 
>> wrote:
>>
>>> Folks, I’ve registered a blueprint [1] and created an etherpad document
>>> [2] where we can co-work on the spec before posting it to a formal review.
>>> Let’s cooperate to summarize what we need to do.
>>>
>>>
>>> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
>>> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun
>>>
>>> - romcheg
>>>
>>> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya 
>>> написав(ла):
>>> >
>>> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
>>> >> +1 to Vitaliy, it would be nice find somewhere a details for
>>> migration.
>>> >> And one more concern I should highlight - for some users logless UI
>>> may
>>> >> be challenging thing.
>>> >> The logs removing shouldn't affect the UX.
>>> >
>>> > Logs will still live at the master node's /var/log/remote
>>> >
>>> >>
>>> >>
>>> >> Nastya.
>>> >>
>>> >>
>>> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward >> >> <mailto:xar...@gmail.com>> wrote:
>>> >>
>>> >>I think we can address it by retaining deployment logs in
>>> >>nailgun/ui, this also removes the chicken and egg problem. after
>>> LMA
>>> >>is deployed it can be allowed to re-own 'logs' button on UI once
>>> >>it's deployed, including redirecting fuel logs there.
>>> >>
>>> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
>>> >>mailto:mscherba...@mirantis.com>>
>>> wrote:
>>> >>
>>> >>We can sort out details later. In a worst case, the warning
>>> will
>>> >>be there in Newton too, and feature will go away only in O*
>>> >>release. So let's proceed with the bug..
>>> >>
>>> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
>>> >>mailto:vkramsk...@mirantis.com>>
>>> wrote:
>>> >>
>>> >>We can add the warning, but I think before we do this we
>>> >>should have clear migration plan. According to this thread,
>>> >>some parts are still not clear.
>>> >>
>>> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
>>> >>mailto:mscherba...@mirantis.com
>>> >>:
>>> >>
>>> >>Deprecation warning for Fuel
>>> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
>>> >>
>>> >>
>>> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
>>> >>mailto:m...@romcheg.me>> wrote:
>>> >>
>>> >>Since there are a lot of supporters for this idea,
>>> >>what do you folks think about creating a BP spec
>>> >>where we can describe what we should do in order to
>>> >>remove logs from UI and Nailgun? I also propose to
>>> >>file a bug about adding a deprecation warning to
>>> >>Mitaka release of Fuel.
>>> >>
>>> >>
>>> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
>>> >>>>> >>><mailto:bdobre...@miran

Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun

[Dmitry Pyzhov]

As we are going to deprecate logs on UI I'm going to mark following bugs as
"won't fix". Any objections?
High priority bug:
https://bugs.launchpad.net/fuel/+bug/1553170
Medium priority:
https://bugs.launchpad.net/fuel/+bug/1554546
https://bugs.launchpad.net/fuel/+bug/1539508

On Mon, Mar 14, 2016 at 3:02 PM, Roman Prykhodchenko  wrote:

> Folks, I’ve registered a blueprint [1] and created an etherpad document
> [2] where we can co-work on the spec before posting it to a formal review.
> Let’s cooperate to summarize what we need to do.
>
>
> 1. https://blueprints.launchpad.net/fuel/+spec/remove-logs-from-nailgun
> 2. https://etherpad.openstack.org/p/remove-logs-from_Nailgun
>
> - romcheg
>
> > 14 бер. 2016 р. о 09:53 Bogdan Dobrelya 
> написав(ла):
> >
> > On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:
> >> +1 to Vitaliy, it would be nice find somewhere a details for migration.
> >> And one more concern I should highlight - for some users logless UI may
> >> be challenging thing.
> >> The logs removing shouldn't affect the UX.
> >
> > Logs will still live at the master node's /var/log/remote
> >
> >>
> >>
> >> Nastya.
> >>
> >>
> >> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward  >> > wrote:
> >>
> >>I think we can address it by retaining deployment logs in
> >>nailgun/ui, this also removes the chicken and egg problem. after LMA
> >>is deployed it can be allowed to re-own 'logs' button on UI once
> >>it's deployed, including redirecting fuel logs there.
> >>
> >>On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
> >>mailto:mscherba...@mirantis.com>> wrote:
> >>
> >>We can sort out details later. In a worst case, the warning will
> >>be there in Newton too, and feature will go away only in O*
> >>release. So let's proceed with the bug..
> >>
> >>On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
> >>mailto:vkramsk...@mirantis.com>>
> wrote:
> >>
> >>We can add the warning, but I think before we do this we
> >>should have clear migration plan. According to this thread,
> >>some parts are still not clear.
> >>
> >>2016-03-11 22:00 GMT+03:00 Mike Scherbakov
> >>mailto:mscherba...@mirantis.com
> >>:
> >>
> >>Deprecation warning for Fuel
> >>Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.
> >>
> >>
> >>On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
> >>mailto:m...@romcheg.me>> wrote:
> >>
> >>Since there are a lot of supporters for this idea,
> >>what do you folks think about creating a BP spec
> >>where we can describe what we should do in order to
> >>remove logs from UI and Nailgun? I also propose to
> >>file a bug about adding a deprecation warning to
> >>Mitaka release of Fuel.
> >>
> >>
> >>>11 бер. 2016 р. о 16:55 Bogdan Dobrelya
> >>> >>>> написав(ла):
> >>>
> >>>On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
> +1 to remove logs from Fuel UI in Fuel Newton.
> In Fuel Mitaka we'd need to put a deprecation
> warning somewhere.
> >>>
> >>>I agree, there is not much sense having non
> >>>flexible (no content
> >>>filters) logs view in UI. LMA plugins shall cover
> >>>this area as well.
> >>>
> 
> 
> On Fri, Mar 11, 2016, 04:57 Patrick Petit
> mailto:ppe...@mirantis.com>
> > wrote:
> 
> 
>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>    (ikalnit...@mirantis.com
>   ikalnit...@mirantis.com>)
> wrote:
> 
> >   Patrick,
> >
> >   Sorry, but I meant another question. I
> >thought that LMA plugin should
> >   be installed in some environment before we
> >can start use it. Is
> >   this a
> >   case? If so, it means we can't use for master
> >node until some
> >   environment is deployed.
> 
>    Right. This is the chicken and egg problem I
> mentioned earlier...
> 
>    But this is not a “problem” specific to Fuel.
> My take on this is is
>    that ops management tooling (logging,
> monitoring) should be
> 

[openstack-dev] [Fuel] Stop deployment can break production cluster. How we should avoid it?

[Dmitry Pyzhov]

Guys,

There is a tricky bug with our 'stop deployment' feature:
https://bugs.launchpad.net/fuel/+bug/1529691

It cannot be fixed easily because it is a design flaw. By design we cannot
leave a node in unpredictable state. So we move all nodes that are not in
ready state back to bootstrap.

But when user adding a node and deploying cluster system reruns puppet on
controllers. If user press 'stop' button controllers will be erased.
Cluster will be destroyed. Definitely this is not expected behaviour.

Taking into account that we are going to rewrite this feature in 9.0 and we
are close to HCF there is no value in major changes for this feature in
8.0. Let's do a simple workaround.

We can mark a cluster 'operational' after successful deployment. And we can
disable 'stop' button on this kind of clusters.

Any concerns or other proposals?
__
OpenStack Development Mailing 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] Please pay attention to bugs with 'swarm-blocker' tag

[Dmitry Pyzhov]

We’ve agreed with QA to get rid of ‘swarm-fail-driver’ tag and limit 
‘swarm-blocker’ tag usage. From now on ‘swarm-blocker’ tag is used only for 
bugs blocking at least 3 test cases of swarm. Please pay close attention to 
this kind of bugs. We need to fix them as a first priority in order to unblock 
further testing.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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 Roman Prykhodchenko to python-fuelclient cores

[Dmitry Pyzhov]

Thank you guys. As there are no objections for a week I'm adding Roman to
python-fuelclient-core group. Roman, congratulations! Use your power wisely
=)

On Wed, Dec 2, 2015 at 12:43 PM, Roman Vyalov  wrote:

> +1
>
> On Wed, Dec 2, 2015 at 12:35 PM, Aleksandr Didenko 
> wrote:
>
>> +1
>>
>> On Wed, Dec 2, 2015 at 9:13 AM, Julia Aranovich 
>> wrote:
>>
>>> +1
>>>
>>> On Tue, Dec 1, 2015 at 10:29 PM Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
>>>> +1
>>>>
>>>> --
>>>> Best regards,
>>>> Sergii Golovatiuk,
>>>> Skype #golserge
>>>> IRC #holser
>>>>
>>>> On Tue, Dec 1, 2015 at 6:15 PM, Aleksey Kasatkin <
>>>> akasat...@mirantis.com> wrote:
>>>>
>>>>> +1.
>>>>> No doubts. )
>>>>>
>>>>>
>>>>> Aleksey Kasatkin
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2015 at 5:49 PM, Dmitry Pyzhov 
>>>>> wrote:
>>>>>
>>>>>> Guys,
>>>>>>
>>>>>> I propose to promote Roman Prykhodchenko to python-fuelclient cores.
>>>>>> He is the main contributor and maintainer of this repo. And he did a 
>>>>>> great
>>>>>> job making changes toward OpenStack recommendations. Cores, please reply
>>>>>> with your +1/-1.
>>>>>>
>>>>>>
>>>>>> __
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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] Nominating Roman Prykhodchenko to python-fuelclient cores

[Dmitry Pyzhov]

Guys,

I propose to promote Roman Prykhodchenko to python-fuelclient cores. He is the 
main contributor and maintainer of this repo. And he did a great job making 
changes toward OpenStack recommendations. Cores, please reply with your +1/-1.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
OpenStack Development Mailing 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

[Dmitry Pyzhov]

Great job! We are much closer to removal of fuel-web repo.

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

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

[openstack-dev] [Fuel] Bugs status

[Dmitry Pyzhov]

Hi guys,

new report is based on 'area' tags. I'm sorry for hardly readable heap of
numbers. Here are values for current numbers of open bugs, number of bugs
opened since last Thursday and number of closed bug for the same period.

Bugs in python, library and UI areas. Format: Total open(UI open/Python
open/Library open) +Total income (UI/Python/Library) -Total
outcome(UI/Python/Library)

Defects:
- Critical/high: 58(5/33/20) +23(1/8/14) -27(2/6/19)
- Medium/low: 199(44/103/52) +14(1/4/9) -21(0/13/8)
Features tracked as bug reports:
- Critical/high: 38(1/31/6) +1(0/1/0) -3(1/1/1)
- Medium/low: 79(3/61/15) +2(0/1/1) -3(0/1/2)
Technical debt bugs:
- Critical/high: 14(0/9/5) +2(0/2/0) -3(0/2/1)
- Medium/low: 91(1/68/22) +4(0/2/2) -6(0/4/2)

Let me decrypt first row that is important. We have 58 high and critical
priority open bugs. 5 of them are in UI 33 are in python and 20 are in
library. In last 7 days we've got 23 new bugs and closed 27.

Little bit more about high and critical priority bugs. In library we fixed
as much bugs as we have in total. It means this number doesn't depend on
our fixing speed any more. The only way this number can be reduced is by
reducing of bugs income.

In python we have 33 high/critical bugs and 15 of them are related to
features being developed. We have several really tricky bugs but we are
close to the end of the queue. It doesn't looks like we can do anything to
significantly reduce number of bugs here. We getting new bugs and we fixing
them.

I hope that we'll be able to focus on 14 high priority tech-debt and 155
medium priority bugs soon. It highly depends on new findings.

Bugs in other teams. Format: open total(open high) +income total(income
high) -outcome total(outcome high).
- QA: 71(21) +24(13) -21(13)
- Docs: 156(35) +6(2) -2(0)
- Devops: 62(24) +10(5) -10(8)
- Build: 43(12) +11(9) -20(13)
- CI: 63(31) +10(7) -11(10)
- MOS: 45(15) +7(4) -3(1)
- Partners: 12(5) +0(0) -0(0)
- MOS Linux: 15(5) +0(0) -1(0)
- Plugins: 3(1) +1(1) -3(2)

Let me explain first row as an example. We have 71 bugs on QA, 21 of them
have high or critical priority. 24 new bugs were created in last 7 days, 13
of them are high/critical. 21 bugs were closed during same period. 13
closed bugs have high or critical priority.
__
OpenStack Development Mailing 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] Every bug in 8.0 milestone should be marked with area tag

[Dmitry Pyzhov]

Guys,

our assignee-based method of guessing bug area has failed. From now on
every bug should has one and only one area tag. You can find explicit list
of tags here: https://wiki.openstack.org/wiki/Fuel/Bug_tags#Area_tags

Here is full list of bugs without area tags
.
You can find this link on
https://wiki.openstack.org/wiki/Fuel/Bug_tags#Area_tags wiki page. Please
add area tags during bugs triage.
__
OpenStack Development Mailing 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] Bugs status

[Dmitry Pyzhov]

Here is our current stats. Overall situation looks ok. We have manageable
number of high priority bugs. Number of medium bugs is going down. It
doesn't look like we will fix all medium bugs by end of release but it
seems to be acceptable. High priority technical debt is under control.
Features backlog is huge and nobody expects that it will be closed by end
of release.

Again I’ll show it in format “total (UI / python / library)"

Critical and high bugs: 43 (5/15/23). Last week it was 52 (6/28/18)
Medium, low and wishlist bugs: 181 (43/102/36). Last week it was 196
(41/112/43)
Features tracked as bug reports: 143. 111 are marked with ‘feature’ tag and
32 covered by blueprints. Last week it was 147 in total, 115 with 'feature'
tag and 32 covered by blueprints.
Technical debt bugs: 105 (2/82/21). Last week it was 106 (2/80/24) in
total. We’ve marked some of tech-debt bugs as High because we think them
pretty important. There are 11 (0/8/3). Last week we had 10 (0/6/4)

This is going to be the last report based on 'assignee' field. Next week
I'm going to split bugs into areas according to our 'area' tags described
here: https://wiki.openstack.org/wiki/Fuel/Bug_tags#Area_tags
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Dmitry Pyzhov]

Vitaly,

because first goal is to make clear separation for bugs ownership.
'area-python' means 'this bug is tracked in python team statistics and it's
python leads job to push it forward'. You can use any other tags you want
to track ui-related bugs. Just don't use 'area-' prefix for that.

I've created a wiki page for tags explanation. Feel free to add tags that
are in use in your teams: https://wiki.openstack.org/wiki/Fuel/Bug_tags

On Fri, Oct 23, 2015 at 12:44 PM, Vitaly Kramskikh 
wrote:

> Dmitry,
>
> 2015-10-22 21:42 GMT+07:00 Dmitry Pyzhov :
>
>> Guys,
>>
>> 1) Bugs status
>>
>> Here is our current stats. Again I’ll show it in format “total (UI /
>> python / library)"
>>
>> Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
>> Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
>> (47/104/42)
>> Features tracked as bug reports: 143. Last week we had 136. 111 are
>> marked with ‘feature’ tag and 32 covered by blueprints. Last week it was
>> 143 in total, 105 with 'feature' tag and 31 covered by blueprints.
>> Technical debt bugs: 106 (2/80/24). Last week it was 101 (1/77/23) in
>> total. Kinda huge and growing number. We’ve marked some of tech-debt bugs
>> as High because we think them pretty important. There are 10 (0/6/4). Last
>> week we had 9 (0/6/3)
>>
>> Not so inspiring numbers this week. We work hard both on fixing and
>> reporting new bugs. It is about 15 new high priority defects reported every
>> week. This is why second topic of my e-mail is important.
>>
>> 2) Area tags
>> I'm analysing what's going on with our bugs and Launchpad is awful tool
>> for bugs management. I've added new 'area' tags to all bugs in 8.0
>> milestone. You probably know it from Launchpad e-mail reports (:smile:).
>> I've tried to be as accurate as possible. We need these tags in order to
>> measure our bugs status precisely. I hope we will add these tags to our
>> triage process next week. Now you can try to use these tags and give some
>> feedback if the idea is useful or not. Later we'll work on making following
>> filters reliable.
>>
>> Python bugs: all
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-python>
>> /open
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-python>
>> (area-python tag)
>> Library bugs: all
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-library>
>> /open
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-library>
>> (area-library tag)
>> UI bugs: all
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=OPINION&field.status%3Alist=INVALID&field.status%3Alist=WONTFIX&field.status%3Alist=EXPIRED&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.milestone%3Alist=72594&field.tag=area-ui>
>> /open
>> <https://bugs.launchpad.net/fuel/+bugs?field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&a

[openstack-dev] [Fuel] Bugs status for ui, python and library. And 'area-*' tags.

[Dmitry Pyzhov]

Guys,

1) Bugs status

Here is our current stats. Again I’ll show it in format “total (UI / python
/ library)"

Critical and high bugs: 52 (6/28/18). Last week it was 46 (1/23/22)
Medium, low and wishlist bugs: 196 (41/112/43). Last week it was 193
(47/104/42)
Features tracked as bug reports: 143. Last week we had 136. 111 are marked
with ‘feature’ tag and 32 covered by blueprints. Last week it was 143 in
total, 105 with 'feature' tag and 31 covered by blueprints.
Technical debt bugs: 106 (2/80/24). Last week it was 101 (1/77/23) in
total. Kinda huge and growing number. We’ve marked some of tech-debt bugs
as High because we think them pretty important. There are 10 (0/6/4). Last
week we had 9 (0/6/3)

Not so inspiring numbers this week. We work hard both on fixing and
reporting new bugs. It is about 15 new high priority defects reported every
week. This is why second topic of my e-mail is important.

2) Area tags
I'm analysing what's going on with our bugs and Launchpad is awful tool for
bugs management. I've added new 'area' tags to all bugs in 8.0 milestone.
You probably know it from Launchpad e-mail reports (:smile:). I've tried to
be as accurate as possible. We need these tags in order to measure our bugs
status precisely. I hope we will add these tags to our triage process next
week. Now you can try to use these tags and give some feedback if the idea
is useful or not. Later we'll work on making following filters reliable.

Python bugs: all

/open

(area-python tag)
Library bugs: all

/open

(area-library tag)
UI bugs: all

/open

(area-ui tag)
Octane bugs: all

/open

(area-octane tag)

Devops bugs: all

[openstack-dev] [Fuel] Changes in bugs workflow on Launchpad

[Dmitry Pyzhov]

Guys,

I propose several changes in bugs workflow on Launchpad.
1) Let's stop using component based team groups as assignees for bugs
2) Let's create separate Launchpad projects for qa, docs and infra teams

It will affect everyone who tracks any list of bugs. So I want to be sure
that everyone can ask question or raise concern.

Why do we need this? We are growing community. In 7.0 release we addressed
2153 bugs. This number is almost unmanageable. We have a lot of tags (99
official and 219 other tags), a lot of Launchpad groups. We have several
big teams with their own workflows. We have 1482 bugs in our current
release. In order to understand if a bug in really a bug or some kind of
support request one have to analyse its tags, assignee and teams of
assignee. And there is a chance that the analysis will produce wrong result.

I'm trying to make our bug management as clear as possible and produce as
little extra everyday mouse clicking as possible. Here is list of required
changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy

Feel free to ask questions.
__
OpenStack Development Mailing 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] backporting before merging to master

[Dmitry Pyzhov]

I'm not sure if core reviewers should be so harsh. But the guideline seems
to be very useful. Guys, please don't create backports too early.

On Fri, Oct 2, 2015 at 2:00 PM, Matthew Mosesohn 
wrote:

> Hi Fuelers,
>
> I would like to address a concern I have with backporting policy. I'm sure
> all of you know that we should always land patches to master before it
> reaches stable/X.X branch. What you are not aware of probably is that many
> people are making cherry picks well in advance of gathering reviews and
> getting the patch landed in master. Some argue that it "saves time waiting
> on CI", but in reality it's quite the opposite. Adding a cherry pick before
> merging master causes the following workflow to take place:
> 1 - Propose to master and to stable/7.0
> 2 - CI runs on 2 patches
> 3 - Reviewer A comments on master patch
> 4 - owner adjusts both patches and runs CI
> 5 - Reviewer B comments on stable patch
> 6 - owner adjusts both patches and runs CI
> (repeat 3-6 in varying degrees until enough patches are gathered)
> 7 - rebase stable/7.0 patch again... wait for CI again
>
> This doubles the burden on CI and complicates the overall review process
> where we are accepting feedback for the initial solution on two (nearly)
> identical patches. What's worse is it's possible that the two solutions
> merged won't be identical and introduce potential regressions.
>
> I propose we avoid raising any stable/X.X patches before a patch is
> _merged_ into master to avoid this scenario. Additionally, if a core sees
> that this is happening, he or she should mark it -2 and discourage
> submission of new patchsets.
>
> I welcome your thoughts and feedback.
>
> Best Regards,
> Matthew Mosesohn
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Bugfixing status. 12 weeks before SCF.

[Dmitry Pyzhov]

Guys,

I was not able to participate in our weekly IRC meeting. So I'd like to
share our bug status for 8.0 release with offline e-mail.

We have 494 Fuel bugs on Launchpad. This number can be splitted into
several piles.

1) Critical and High priority bugs. We have 48 of them now. 2 in UI, 31 in
python, 15 in library. Here is our focus and we are working on reducing the
numbers.
2) Medium/Low/Wishlist priority bugs. We have 241 bug. 72 in UI, 119 in
python, 50 in library.
3) Features reported as bugs and bugs that can be fixed only by
implementing new blueprints. We have 133 of them. 3 in UI, 106 in python
and 24 in library. These bugs are marked with 'feature', 'covered-by-bp'
and 'need-bp' tags. Numbers look scary but only 40 of them have high and
critical priority.
4) Technical debt. Things that we should do better from developer's point
of view. 72 bugs in total. 60 in python, 12 in library. They are marked
with 'tech-debt' tag.

My personal opinion is that we can ignore our medium-priority technical
debt bugs for now. We should fix them but there is nothing that cannot be
postponed here. We will continue fixing them in background. The only
exception here should be bugs related to alignment with global
requirements, tox and oslo-related changes. We definitely should fix this
stuff.

You can see that we have big demand for python developers. Here is my early
estimation. With current pace we can fix all existing library bugs in 8.0.
Also we can fix all existing high priority bugs in python. It includes
technical debt and maybe feature-bugs. It looks like we are able to fix
about half of medium priority python bugs. I don't have any estimations for
medium priority feature-bugs in python. And I'd prefer to be pessimistic
here. Also we will fix very small number of medium priority technical debt
bugs.

There is a good chance that number of incoming bugs will became smaller
over time and we will fix most of existing medium priority python bugs.
__
OpenStack Development Mailing 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] Remove MOS DEB repo from master node

[Dmitry Pyzhov]

Guys,

looks like you’ve started to talk about different things. As I see, original 
proposal was: stop treat MOS DEB repo as a special case and use the same flow 
for all repos. Your use case does not contradict it.

Moreover, it requires standard flow for all repos. ‘Put everything on the ISO’ 
use case should be implemented as a new feature. It is a matter of running 
fuel-createmirror script during ISO build and usage of it during master node 
deployment. It definitely should use mirror as a single object. And this object 
should be compatible with result of the fuel-createmirror script usage.

> On 10 Sep 2015, at 18:18, Vladimir Kuklin  wrote:
> 
> Folks
> 
> I guess I need to get you on-site to deploy something at our user's 
> datacenter. I do want to be able to download an ISO which contains all 
> packages. This may not be the primary artifact of our software suite, but we 
> need to have this opportunity to build full ISO with ALL components. Please, 
> do not narrow down our feature set just by thinking that users do not need 
> something because we are reluctant to implement this. Just believe me - users 
> need this opportunity in a lot of deployment cases. It is not hard to 
> implement it. We do not need to set this as a default option, but we need to 
> have it. That is my point.
> 
> On Thu, Sep 10, 2015 at 5:40 PM, Vladimir Kozhukalov 
> mailto:vkozhuka...@mirantis.com>> wrote:
> Vladimir,
> 
> * We don't have full ISO anyway
> * We don't require to create mirror. When you launch your browser, do you 
> mean to have mirror of the Internet locally? Probably, no. The same is here. 
> Internet connection is the common requirement nowadays, but if you don't have 
> one, you definitely need to have a kind of local copy.
> 
> Vladimir Kozhukalov
> 
> On Thu, Sep 10, 2015 at 4:17 PM, Vladimir Kuklin  > wrote:
> Igor
> 
> Having poor access to the internet is a regular use case which we must 
> support. This is not a crazy requirement. Not having full ISO makes cloud 
> setup harder to complete. Even more, not having hard requirement to create a 
> mirror will detract newcomers. I can say that if I were a user and saw a 
> requirement to create mirror I would not try the product with comparison to 
> the case when I can get a full ISO with all the stuff I need.
> 
> On Thu, Sep 10, 2015 at 4:06 PM, Vladimir Kozhukalov 
> mailto:vkozhuka...@mirantis.com>> wrote:
> 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 th

Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes

[Dmitry Pyzhov]

Andrey, you have highlighted important case. I hope you agree that this
case is not a blocker for the proposal. From the developer's point of view
packages are awful and we should use raw git repos on every node. It could
make developer's life way easier. But from architecture perspective it
would be a disaster.

Rsync is just another legacy part of our architecture. We had puppet master
before. We have rsync now. Let's see what we should use in future and how
we can make it convenient for developers.

On Wed, Sep 9, 2015 at 2:47 PM, Andrey Danin  wrote:

> I disagree from the development point of view. Now I just change manifests
> on Fuel node and redeploy cluster to apply that changes. With your proposal
> I'll need to build a new package and add it to a repo every time I change
> something.
>
> On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <
> vkozhuka...@mirantis.com> wrote:
>
>> Dear colleagues,
>>
>> Currently, we install fuel-libraryX.Y package(s) on the master node and
>> then right before starting actual deployment we rsync [1] puppet modules
>> (one of installed versions) from the master node to slave nodes. Such a
>> flow makes things much more complicated than they could be if we installed
>> puppet modules on slave nodes as rpm/deb packages. Deployment itself is
>> parameterized by repo urls (upstream + mos) and this pre-deployment task
>> could be nothing more than just installing fuel-library package from mos
>> repo defined for a cluster. We would not have several versions of
>> fuel-library on the master node, we would not need that complicated upgrade
>> stuff like we currently have for puppet modules.
>>
>> Please give your opinions on this.
>>
>>
>> [1]
>> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218
>>
>> 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
>>
>>
>
>
> --
> Andrey Danin
> ada...@mirantis.com
> skype: gcon.monolake
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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] Install fuel-libraryX.Y as a package on slave nodes

[Dmitry Pyzhov]

Vladimir,

thanks for bringing this up. It greatly correlates with the idea of
modularity. Everything related to an openstack release should be put in one
place and should be managed as a solid bundle on the master node. Package
repository is the first solution that comes to the mind and it looks pretty
good. Puppet modules, openstack.yaml and maybe even serialisers should be
stored in packages in the openstack release repository. And eventually
every other piece of our software should get rid of release-specific logic.

On Tue, Sep 8, 2015 at 11:41 PM, Vladimir Kozhukalov <
vkozhuka...@mirantis.com> wrote:

> Dear colleagues,
>
> Currently, we install fuel-libraryX.Y package(s) on the master node and
> then right before starting actual deployment we rsync [1] puppet modules
> (one of installed versions) from the master node to slave nodes. Such a
> flow makes things much more complicated than they could be if we installed
> puppet modules on slave nodes as rpm/deb packages. Deployment itself is
> parameterized by repo urls (upstream + mos) and this pre-deployment task
> could be nothing more than just installing fuel-library package from mos
> repo defined for a cluster. We would not have several versions of
> fuel-library on the master node, we would not need that complicated upgrade
> stuff like we currently have for puppet modules.
>
> Please give your opinions on this.
>
>
> [1]
> https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L205-L218
>
> Vladimir Kozhukalov
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Evgeniy Konstantinov for fuel-docs core

[Dmitry Pyzhov]

+1

On Thu, Sep 3, 2015 at 10:14 PM, Sergey Vasilenko 
wrote:

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

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

[Dmitry Pyzhov]

If there will be no objections Vladimir will became core reviewer for
fuel-main from Monday, 27th

On Fri, Jul 24, 2015 at 4:10 PM, Vladimir Sharshov 
wrote:

> +1
>
> On Fri, Jul 24, 2015 at 2:58 PM, Andrey Danin  wrote:
>
>> +1
>>
>> On Fri, Jul 24, 2015 at 2:00 AM, Vitaly Kramskikh <
>> vkramsk...@mirantis.com> wrote:
>>
>>> +1
>>>
>>> 2015-07-24 1:56 GMT+03:00 Sergey Vasilenko :
>>>
 +1


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


>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>> Andrey Danin
>> ada...@mirantis.com
>> skype: gcon.monolake
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] Nominating Vladimir Kozhukalov to core reviewers of fuel-main

[Dmitry Pyzhov]

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

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

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

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

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

[Dmitry Pyzhov]

Vladimir,

We do break developer's workflow in stable branches if we force them to use
our local mirrors. Yes, we can hardcode mirror url in tox.ini or something
like that. But it looks like a hack for me.

Packaging systems were created in order to add ability to set up
predictable environment with exact versions of every piece. So if we want
to have a predictable environment for stable branches we have one
production ready option. We should have a package for every moving part.
None of our stable/* jobs on jenkins should use anything except locally
cached packages. I think this is the only way to do it right.

Tests for master jobs are an open question. I think we can continue using
pypi here for now. Because it works.

On Mon, Jul 13, 2015 at 11:56 AM, Vladimir Kuklin 
wrote:

> Dima
>
> You have a very valid point, but the is a problem here - by doing it this
> way we are breaking developers' workflow which is based on using such
> repositories as pypi, rubygem, etc.
> If you convince developers (and I guess not only Fuel ones as we are
> moving towards community engagement) to switch their workflow - I have no
> objections.
>
> Bartek
>
> Actually, what we are doing is that we are freezing almost all the
> packages (except for upstream linux maintenance updates that should not
> change ABIs) thus having this drift at least constrained somehow. And this
> is how you control your upper bounds - you just do not push anything new
> into it.
>
>
> Let me provide an example why your suggestion does not work.
>
> Imagine, we have Debian Sid repository configured for our installations
> (or use some other 3rd party not strictly controlled mirror). It will work
> fine until you push new oslo package which is conflicting with your stuff
> like keystone, for example. And what is more important - you have already
> released this keystone and you CANNOT control requirements of it, you were
> not able to set them when you were working on the release because there is
> actually no time machine. This means that you need either to disable this
> 3rd party repo or to freeze in some state or you will have the same problem
> as with eggs.
>
>
> On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski <
> bpiotrow...@mirantis.com> wrote:
>
>> Freezing every moving part is complete overkill and puts a heavy burden
>> on devops
>> team as well as infra itself. The fix couldn't be more simple: just put
>> upper
>> bounds in requirements.
>>
>> > 1) if there is a new conflicting version, you need to set this
>> upper-bound, thus you need to modify bits which get released
>> It should be done as part of hard code freeze.
>>
>> > 2) you are actually testing your code by linking it with libraries
>> which are different from those that users are really using when running
>> your code
>> Packages dependencies should reflect these set in requirements.
>>
>> > 3) even if you specify an upper bound (or even fix the version) for
>> this particular library, you may still fetch its newer dependency
>> implicitly (by traversing indirect dependencies) with which you will be
>> linking your libraries and which will actually be different from the code
>> that you (and your users) use
>> This can be actually said about anything, including base system Fuel is
>> running. We simply do not support such setups.
>>
>> > 4) you may also break production installation if you fix some library
>> version as it may not exist in the code bundle which gets delivered to your
>> users as a set of package
>> See 2.
>>
>> BP
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Julia Aranovich for fuel-web core

[Dmitry Pyzhov]

+1

On Tue, May 5, 2015 at 1:06 PM, Evgeniy L  wrote:

> +1
>
> On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski <
> skalinow...@mirantis.com> wrote:
>
>> +1
>>
>> 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski :
>>
>>> +1, indeed Julia's reviews are very thorough.
>>>
>>> P.
>>>
>>> On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
>>> > Hi,
>>> >
>>> > I'd like to nominate Julia Aranovich
>>> >  for fuel-web
>>> >  core team. Julia's reviews
>>> are
>>> > always thorough and have decent quality. She is one of the top
>>> > contributors and reviewers in fuel-web repo (mostly for JS/UI stuff).
>>> >
>>> > Please vote by replying with +1/-1.
>>> >
>>> > --
>>> > Vitaly Kramskikh,
>>> > Fuel UI Tech Lead,
>>> > Mirantis, Inc.
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing 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] Several nominations for fuel project cores

[Dmitry Pyzhov]

Dmitry, Vladimir, Alexander,

welcome to the core reviewers family =)

Use your power wisely and accept code only if it reviewed by people from
several locations.

On Fri, Apr 17, 2015 at 2:54 PM, Dmitry Pyzhov  wrote:

> Thanks for your responses. I'm sorry for combined request. I thought it is
> better to have less e-mails if possible. Ok, next time I will send separate
> request per nomination. If some of you think that I should restart voting -
> speak up, I will restart it. Otherwise guys will get +2 permissions on
> Monday.
>
> On Wed, Apr 15, 2015 at 5:10 PM, Evgeniy L  wrote:
>
>> 1/ +1
>> 2/ +1
>> 3/ +1
>>
>> On Tue, Apr 14, 2015 at 2:45 PM, Aleksey Kasatkin > > wrote:
>>
>>> 1/ +1
>>> 2/ +1
>>> 3/ +1
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Tue, Apr 14, 2015 at 12:26 PM, Tatyana Leontovich <
>>> tleontov...@mirantis.com> wrote:
>>>
>>>>
>>>> 3/ +1
>>>>
>>>> On Tue, Apr 14, 2015 at 11:49 AM, Sergii Golovatiuk <
>>>> sgolovat...@mirantis.com> wrote:
>>>>
>>>>> +1 for separating.
>>>>>
>>>>> Let's follow the formal well established process.
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Sergii Golovatiuk,
>>>>> Skype #golserge
>>>>> IRC #holser
>>>>>
>>>>> On Tue, Apr 14, 2015 at 10:32 AM, Igor Kalnitsky <
>>>>> ikalnit...@mirantis.com> wrote:
>>>>>
>>>>>> Dmitry,
>>>>>>
>>>>>> 1/ +1
>>>>>>
>>>>>> 2/ +1
>>>>>>
>>>>>> 3/ +1
>>>>>>
>>>>>> P.S: Dmitry, please send one mail per nomination next time. It's much
>>>>>> easier to vote for each candidate in separate threads. =)
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov 
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > 1) I want to nominate Vladimir Sharshov to fuel-astute core. We
>>>>>> hardly need
>>>>>> > more core reviewers here. At the moment Vladimir is one of the main
>>>>>> > contributors and reviewers in astute.
>>>>>> >
>>>>>> > 2) I want to nominate Alexander Kislitsky to fuel-stats core. He is
>>>>>> the lead
>>>>>> > of this feature and one of the main authors in this repo.
>>>>>> >
>>>>>> > 3) I want to nominate Dmitry Shulyak to fuel-web and fuel-ostf
>>>>>> cores. He is
>>>>>> > one of the main contributors and reviewers in both repos.
>>>>>> >
>>>>>> > Core reviewers, please reply with +1/-1 for each nomination.
>>>>>> >
>>>>>> >
>>>>>> __
>>>>>> > OpenStack Development Mailing List (not for usage questions)
>>>>>> > Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>> >
>>>>>>
>>>>>>
>>>>>> __
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
__
OpenStack Development Mailing 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] Several nominations for fuel project cores

[Dmitry Pyzhov]

Thanks for your responses. I'm sorry for combined request. I thought it is
better to have less e-mails if possible. Ok, next time I will send separate
request per nomination. If some of you think that I should restart voting -
speak up, I will restart it. Otherwise guys will get +2 permissions on
Monday.

On Wed, Apr 15, 2015 at 5:10 PM, Evgeniy L  wrote:

> 1/ +1
> 2/ +1
> 3/ +1
>
> On Tue, Apr 14, 2015 at 2:45 PM, Aleksey Kasatkin 
> wrote:
>
>> 1/ +1
>> 2/ +1
>> 3/ +1
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Tue, Apr 14, 2015 at 12:26 PM, Tatyana Leontovich <
>> tleontov...@mirantis.com> wrote:
>>
>>>
>>> 3/ +1
>>>
>>> On Tue, Apr 14, 2015 at 11:49 AM, Sergii Golovatiuk <
>>> sgolovat...@mirantis.com> wrote:
>>>
>>>> +1 for separating.
>>>>
>>>> Let's follow the formal well established process.
>>>>
>>>> --
>>>> Best regards,
>>>> Sergii Golovatiuk,
>>>> Skype #golserge
>>>> IRC #holser
>>>>
>>>> On Tue, Apr 14, 2015 at 10:32 AM, Igor Kalnitsky <
>>>> ikalnit...@mirantis.com> wrote:
>>>>
>>>>> Dmitry,
>>>>>
>>>>> 1/ +1
>>>>>
>>>>> 2/ +1
>>>>>
>>>>> 3/ +1
>>>>>
>>>>> P.S: Dmitry, please send one mail per nomination next time. It's much
>>>>> easier to vote for each candidate in separate threads. =)
>>>>>
>>>>> Thanks,
>>>>> Igor
>>>>>
>>>>> On Mon, Apr 13, 2015 at 4:24 PM, Dmitry Pyzhov 
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > 1) I want to nominate Vladimir Sharshov to fuel-astute core. We
>>>>> hardly need
>>>>> > more core reviewers here. At the moment Vladimir is one of the main
>>>>> > contributors and reviewers in astute.
>>>>> >
>>>>> > 2) I want to nominate Alexander Kislitsky to fuel-stats core. He is
>>>>> the lead
>>>>> > of this feature and one of the main authors in this repo.
>>>>> >
>>>>> > 3) I want to nominate Dmitry Shulyak to fuel-web and fuel-ostf
>>>>> cores. He is
>>>>> > one of the main contributors and reviewers in both repos.
>>>>> >
>>>>> > Core reviewers, please reply with +1/-1 for each nomination.
>>>>> >
>>>>> >
>>>>> __
>>>>> > OpenStack Development Mailing List (not for usage questions)
>>>>> > Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Dmitry Pyzhov]

FYI. We are going to disable Multi-node mode on UI even in experimental
mode. And we will remove related code from nailgun in 7.0.
https://bugs.launchpad.net/fuel/+bug/1428054

On Fri, Jan 30, 2015 at 1:39 PM, Aleksandr Didenko 
wrote:

> What do you guys think about switching CentOS CI job [1] to HA with single
> controller (1 controller + 1 or 2 computes)? Just to verify that our
> replacement of Simple mode works fine.
>
> [1]
> https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
>
> On Fri, Jan 30, 2015 at 10:54 AM, Mike Scherbakov <
> mscherba...@mirantis.com> wrote:
>
>> Thanks Igor for the quick turn over, excellent!
>>
>> On Fri, Jan 30, 2015 at 1:19 AM, Igor Belikov 
>> wrote:
>>
>>> Folks,
>>>
>>> Changes in CI jobs have been made, for master branch of fuel-library we
>>> are running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN .
>>> Job naming schema has also been changed, so now it includes actual
>>> testgroup. Current links for master branch CI jobs are [1] and [2], all
>>> other jobs can be found here[3] or will show up in your gerrit reviews.
>>> ISO and environments have been updated to the latest ones.
>>>
>>> [1]
>>> https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/
>>> [2]
>>> https://fuel-jenkins.mirantis.com/job/master.fuel-library.ubuntu.ha_neutron_vlan/
>>> [3]https://fuel-jenkins.mirantis.com
>>> --
>>> Igor Belikov
>>> Fuel DevOps
>>> ibeli...@mirantis.com
>>>
>>>
>>>
>>>
>>>
>>> On 29 Jan 2015, at 13:42, Aleksandr Didenko 
>>> wrote:
>>>
>>> Mike,
>>>
>>> > Any objections / additional suggestions?
>>>
>>> no objections from me, and it's already covered by LP 1415116 bug [1]
>>>
>>> [1] https://bugs.launchpad.net/fuel/+bug/1415116
>>>
>>> On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
 Folks,
 one of the things we should not forget about - is out Fuel CI gating
 jobs/tests. [1], [2].

 One of them is actually runs simple mode. Unfortunately, I don't see
 details about tests ran for [1], [2], but I'm pretty sure it's same set as
 [3], [4].

 I suggest to change tests. First of all, we need to get rid of simple
 runs (since we are deprecating it), and second - I'd like us to run Ubuntu
 HA + Neutron VLAN for one of the tests.

 Any objections / additional suggestions?

 [1]
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_centos/
 [2]
 https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/
 [3]
 https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_centos/
 [4]
 https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_ubuntu/

 On Wed, Jan 28, 2015 at 2:28 PM, Sergey Vasilenko <
 svasile...@mirantis.com> wrote:

> +1 to replace simple to HA with one controller
>
> /sv
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


 --
 Mike Scherbakov
 #mihgen



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


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

[openstack-dev] [Fuel] Upgrade tarball retirement path

[Dmitry Pyzhov]

Guys,

TL;DR: There will be upgrade tarball in 6.1. But it will not require any
data from 6.0.x branch. And there will be no upgrade tarball starting from
7.0.

Looks like we don't need upgrade tarball any more. It is a big relief for
our build team. Because GNU make is not intended to be used for this kind
of things. So:

1) We should remove upgrade tarball and create a script for upgrade
instead. This script will get new packages from upstream repos and do all
the stuff.
2) We are not ready to remove upgrade tarball in 6.1. We are too close to
the release and it will be too risky to deal with all the last minute bugs
after such big change.
3) We will get rid of diff repos in 6.1. It is useless for Ubuntu. Because
we've updated from 12.04 to 14.04 and there are a lot of changes in
packages. So diff repos saves about 300Mb and produces a lot of extra work
for build and upgrade procedures in 6.1. We will deprecate it.
4) 6.0.1 release will not be available by the HCF for 6.1. And our old
version of patching is deprecated. So we don't need to ship any 6.0.x data
with our upgrade tarball for 6.1.

Any questions, comments, objections?
__
OpenStack Development Mailing 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] Several nominations for fuel project cores

[Dmitry Pyzhov]

Hi,

1) I want to nominate Vladimir Sharshov to fuel-astute core. We hardly need
more core reviewers here. At the moment Vladimir is one of the main
contributors and reviewers in astute.

2) I want to nominate Alexander Kislitsky to fuel-stats core. He is the
lead of this feature and one of the main authors in this repo.

3) I want to nominate Dmitry Shulyak to fuel-web and fuel-ostf cores. He is
one of the main contributors and reviewers in both repos.

Core reviewers, please reply with +1/-1 for each nomination.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Nominate Sebastian Kalinowski for fuel-web/python-fuelclient core

[Dmitry Pyzhov]

+1

On Mon, Apr 13, 2015 at 2:07 PM, Evgeniy L  wrote:

> +1
>
> On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko 
> wrote:
>
>> +1. Sebastian does great job in reviews!
>>
>> > 10 квіт. 2015 о 12:05 Igor Kalnitsky 
>> написав(ла):
>> >
>> > Hi Fuelers,
>> >
>> > I'd like to nominate Sebastian Kalinowski for the both fuel-web-core
>> > [1] and python-fuelclient-core [2] teams. Sebastian's doing a really
>> > good review with detailed feedback and he's a regular participant in
>> > IRC. I believe that having him among the cores we will increase our
>> > overall performance.
>> >
>> > Fuel Cores, please reply back with +1/-1.
>> >
>> > Thanks,
>> > Igor
>> >
>> > [1]:
>> http://stackalytics.com/?project_type=stackforge&module=fuel-web&release=kilo
>> > [2]:
>> http://stackalytics.com/?project_type=stackforge&module=python-fuelclient&release=kilo
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Bug tagging practice

[Dmitry Pyzhov]

Clarification: numbers include only open bugs on 6.1. We have about 15
module-volumes bugs on 7.0, many bugs on the 'next' milestone and some
number of bugs in progress.

On Fri, Mar 27, 2015 at 9:40 PM, Dmitry Pyzhov  wrote:

> Guys,
>
> I've tried to sort more than 200 bugs on my team. I've tried several
> approaches to this issue and here the solution.
>
> First of all, assigning bugs to teams is great. Totally. Awesome. Let's
> keep using it.
>
> Second. I have my own one-more-launchpad-parser:
> https://github.com/dmi-try/launchpad-report
> I have no time to add multithreading to it. So it takes more than 5 hours
> do it job. But it 100% suitable for me and works just great. It takes every
> single fuel and mos bug, checks every single task for this bug, analyses it
> and gives me a CSV report. It notices every single missed triage and fix
> action on every single milestone. So I do even know that we have some
> unfinished backports on 4.x branches. It shows every tag, every bug
> creation date and bug update date (in dev version). I'm looking forward to
> see this functions in our web tool. Because it is bad to have several tools
> for one task.
>
> Third. Our 'nailgun' and 'ui' tags are useless. Almost each bug can be
> applied to some component or to some feature. So I've introduced a lot of
> feature-* and module-* tags for my team and we will evaluate them. You can
> find all new tags later in this email.
>
> Fourth. We do have low-hanging-fruit
> <https://bugs.launchpad.net/fuel/+bugs?field.tag=low-hanging-fruit> tag
> and it is great. I've also added tech-debt
> <https://bugs.launchpad.net/fuel/+bugs?field.tag=tech-debt> tag in order
> to group bugs that are not related to the user experience or functionality.
> And I've added feature
> <https://bugs.launchpad.net/fuel/+bugs?field.tag=feature> tag for
> complicated request that required to be properly designed. Some of them not
> even close to be real bugs. But almost every request talks about users
> pain. So it is rude to close them. That's why we have:
>
> Sixth. 'next <https://launchpad.net/fuel/+milestone/next>' milestone.
> Bugs in this milestone cannot be fixed with our bugfixing process. We do
> need proper prioritization for them in our backlog.
>
> Our feature and module tags with amount of bugs per each tag.
>
>  feature-advanced-networking 2
>  feature-bonding 3
>  feature-client 1
>  feature-deadlocks 1
>  feature-demo-site 2
>  feature-hardware-change 5
>  feature-image-based 13
>  feature-logging 4
>  feature-mongo 2
>  feature-multi-l2 3
>  feature-native-provisioning 6
>  feature-plugins 5
>  feature-progress-bar 2
>  feature-redeployment 4
>  feature-remote-repos 2
>  feature-reset-env 5
>  feature-security 3
>  feature-simple-mode 1
>  feature-stats 9
>  feature-stop-deployment 3
>  feature-upgrade 8
>  feature-validation 9
>  module-amqp 1
>  module-build 2
>  module-client 13
>  module-fuelmenu 1
>  module-master-node-installation 2
>  module-nailgun 1
>  module-nailgun-agent 1
>  module-netcheck 11
>  module-networks 8
>  module-ostf 19
>  module-serialization 4
>  module-shotgun 16
>  module-tasks 13
>  module-volumes 8
>
> I'm going to add this tags in our triaging process. And assign owner for
> each tag.
>
__
OpenStack Development Mailing 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] Bug tagging practice

[Dmitry Pyzhov]

Guys,

I've tried to sort more than 200 bugs on my team. I've tried several
approaches to this issue and here the solution.

First of all, assigning bugs to teams is great. Totally. Awesome. Let's
keep using it.

Second. I have my own one-more-launchpad-parser:
https://github.com/dmi-try/launchpad-report
I have no time to add multithreading to it. So it takes more than 5 hours
do it job. But it 100% suitable for me and works just great. It takes every
single fuel and mos bug, checks every single task for this bug, analyses it
and gives me a CSV report. It notices every single missed triage and fix
action on every single milestone. So I do even know that we have some
unfinished backports on 4.x branches. It shows every tag, every bug
creation date and bug update date (in dev version). I'm looking forward to
see this functions in our web tool. Because it is bad to have several tools
for one task.

Third. Our 'nailgun' and 'ui' tags are useless. Almost each bug can be
applied to some component or to some feature. So I've introduced a lot of
feature-* and module-* tags for my team and we will evaluate them. You can
find all new tags later in this email.

Fourth. We do have low-hanging-fruit
 tag and
it is great. I've also added tech-debt
 tag in order to
group bugs that are not related to the user experience or functionality.
And I've added feature
 tag for
complicated request that required to be properly designed. Some of them not
even close to be real bugs. But almost every request talks about users
pain. So it is rude to close them. That's why we have:

Sixth. 'next ' milestone. Bugs
in this milestone cannot be fixed with our bugfixing process. We do need
proper prioritization for them in our backlog.

Our feature and module tags with amount of bugs per each tag.

 feature-advanced-networking 2
 feature-bonding 3
 feature-client 1
 feature-deadlocks 1
 feature-demo-site 2
 feature-hardware-change 5
 feature-image-based 13
 feature-logging 4
 feature-mongo 2
 feature-multi-l2 3
 feature-native-provisioning 6
 feature-plugins 5
 feature-progress-bar 2
 feature-redeployment 4
 feature-remote-repos 2
 feature-reset-env 5
 feature-security 3
 feature-simple-mode 1
 feature-stats 9
 feature-stop-deployment 3
 feature-upgrade 8
 feature-validation 9
 module-amqp 1
 module-build 2
 module-client 13
 module-fuelmenu 1
 module-master-node-installation 2
 module-nailgun 1
 module-nailgun-agent 1
 module-netcheck 11
 module-networks 8
 module-ostf 19
 module-serialization 4
 module-shotgun 16
 module-tasks 13
 module-volumes 8

I'm going to add this tags in our triaging process. And assign owner for
each tag.
__
OpenStack Development Mailing 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] Change diagnostic snapshot compression algoritm

[Dmitry Pyzhov]

Actually, we have some improvements with snapshots size and we are going to
rethink our snapshots in upcoming releases. Miroslav, could you clarify the
importance of this change in 6.1?

On Thu, Jan 29, 2015 at 2:30 PM, Tomasz Napierala 
wrote:

> Guys,
>
> We have requests for this improvement. It will help with huge
> environments, we are talking about >5GiB of logs.
> Is it on the agenda?
>
> Regards,
>
>
> > On 22 Dec 2014, at 07:28, Bartlomiej Piotrowski <
> bpiotrow...@mirantis.com> wrote:
> >
> > FYI, xz with multithreading support (5.2 release) has been marked as
> stable yesterday.
> >
> > Regards,
> > Bartłomiej Piotrowski
> >
> > On Mon, Nov 24, 2014 at 12:32 PM, Bartłomiej Piotrowski <
> bpiotrow...@mirantis.com> wrote:
> > On 24 Nov 2014, at 12:25, Matthew Mosesohn 
> wrote:
> > > I did this exercise over many iterations during Docker container
> > > packing and found that as long as the data is under 1gb, it's going to
> > > compress really well with xz. Over 1gb and lrzip looks more attractive
> > > (but only on high memory systems). In reality, we're looking at log
> > > footprints from OpenStack environments on the order of 500mb to 2gb.
> > >
> > > xz is very slow on single-core systems with 1.5gb of memory, but it's
> > > quite a bit faster if you run it on a more powerful system. I've found
> > > level 4 compression to be the best compromise that works well enough
> > > that it's still far better than gzip. If increasing compression time
> > > by 3-5x is too much for you guys, why not just go to bzip? You'll
> > > still improve compression but be able to cut back on time.
> > >
> > > Best Regards,
> > > Matthew Mosesohn
> >
> > Alpha release of xz supports multithreading via -T (or —threads)
> parameter.
> > We could also use pbzip2 instead of regular bzip to cut some time on
> multi-core
> > systems.
> >
> > Regards,
> > Bartłomiej Piotrowski
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Tomasz 'Zen' Napierala
> Sr. OpenStack Engineer
> tnapier...@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] Image based provisioning

[Dmitry Pyzhov]

Guys,

we are about to enable image based provisioning in our master by default.
I'm trying to figure out requirement for this change. As far as I know, it
was not tested on scale lab. Is it true? Have we ever run full system tests
cycle with this option?

Do we have any other pre-requirements?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Logs format on UI (High/6.0)

[Dmitry Pyzhov]

Guys, thank you for your feedback. As a quick and dirty solution we
continue to hide extra information from UI. It will not break existing user
experience.

Roman, there were attempts to get rid of our current web logs page and use
Logstash. As usual, it's all about time and resources. It is our backlog,
but it is not in our current roadmap.

On Mon, Dec 15, 2014 at 6:11 PM, Roman Prykhodchenko  wrote:
>
> Hi folks!
>
> In most productions environments I’ve seen bare logs as they are shown now
> in Fuel web UI were pretty useless. If someone has an infrastructure that
> consists of more that 5 servers and 5 services running on them they are
> most likely to use logstash, loggly or any other log management system.
> There are options for forwarding these logs to a remote log server and
> that’s what is likely to be used IRL.
>
> Therefore for production environments formatting logs in Fuel web UI or
> even showing them is a cool but pretty useless feature. In addition to
> being useless in production environments it also creates additional load to
> the user interface.
>
> However, I can see that developers actually use it for debugging or
> troubleshooting, so my proposal is to introduce an option for disabling
> this feature completely.
>
>
> - romcheg
>
> > On 15 Dec 2014, at 12:40, Tomasz Napierala 
> wrote:
> >
> > Also +1 here.
> > In huge envs we already have problems with parsing performance. In long
> long term we need to think about other log management solution
> >
> >
> >> On 12 Dec 2014, at 23:17, Igor Kalnitsky 
> wrote:
> >>
> >> +1 to stop parsing logs on UI and show them "as is". I think it's more
> >> than enough for all users.
> >>
> >> On Fri, Dec 12, 2014 at 8:35 PM, Dmitry Pyzhov 
> wrote:
> >>> We have a high priority bug in 6.0:
> >>> https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.
> >>>
> >>> Our openstack services use to send logs in strange format with extra
> copy of
> >>> timestamp and loglevel:
> >>> ==> ./neutron-metadata-agent.log <==
> >>> 2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349
> INFO
> >>> neutron.common.config [-] Logging enabled!
> >>>
> >>> And we have a workaround for this. We hide extra timestamp and use
> second
> >>> loglevel.
> >>>
> >>> In Juno some of services have updated oslo.logging and now send logs in
> >>> simple format:
> >>> ==> ./nova-api.log <==
> >>> 2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from
> >>> /etc/nova/api-paste.ini
> >>>
> >>> In order to keep backward compatibility and deal with both formats we
> have a
> >>> dirty workaround for our workaround:
> >>> https://review.openstack.org/#/c/141450/
> >>>
> >>> As I see, our best choice here is to throw away all workarounds and
> show
> >>> logs on UI as is. If service sends duplicated data - we should show
> >>> duplicated data.
> >>>
> >>> Long term fix here is to update oslo.logging in all packages. We can
> do it
> >>> in 6.1.
> >>>
> >>> ___
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > --
> > Tomasz 'Zen' Napierala
> > Sr. OpenStack Engineer
> > tnapier...@mirantis.com
> >
> >
> >
> >
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Logs format on UI (High/6.0)

[Dmitry Pyzhov]

We have a high priority bug in 6.0:
https://bugs.launchpad.net/fuel/+bug/1401852. Here is the story.

Our openstack services use to send logs in strange format with extra copy
of timestamp and loglevel:
==> ./neutron-metadata-agent.log <==
2014-12-12T11:00:30.098105+00:00 info: 2014-12-12 11:00:30.003 14349 INFO
neutron.common.config [-] Logging enabled!

And we have a workaround for this. We hide extra timestamp and use second
loglevel.

In Juno some of services have updated oslo.logging and now send logs in
simple format:
==> ./nova-api.log <==
2014-12-12T10:57:15.437488+00:00 debug: Loading app ec2 from
/etc/nova/api-paste.ini

In order to keep backward compatibility and deal with both formats we have
a dirty workaround for our workaround:
https://review.openstack.org/#/c/141450/

As I see, our best choice here is to throw away all workarounds and show
logs on UI as is. If service sends duplicated data - we should show
duplicated data.

Long term fix here is to update oslo.logging in all packages. We can do it
in 6.1.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Feature delivery rules and automated tests

[Dmitry Pyzhov]

Guys,

we've done a good job in 6.0. Most of the features were merged before
feature freeze. Our QA were involved in testing even earlier. It was much
better than before.

We had a discussion with Anastasia. There were several bug reports for
features yesterday, far beyond HCF. So we still have a long way to be
perfect. We should add one rule: we need to have automated tests before HCF.

Actually, we should have results of these tests just after FF. It is quite
challengeable because we have a short development cycle. So my proposal is
to require full deployment and run of automated tests for each feature
before soft code freeze. And it needs to be tracked in checklists and on
feature syncups.

Your opinion?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

[Dmitry Pyzhov]

I've moved the bug to 6.1. And I'm going to add it to our roadmap as a
separate item.

On Wed, Nov 26, 2014 at 1:31 PM, Mike Scherbakov 
wrote:

> Can we put it as a work item for diagnostic snapshot improvements, so we
> won't forget about this in 6.1?
>
>
> On Tuesday, November 25, 2014, Dmitry Pyzhov  wrote:
>
>> Thank you all for your feedback. Request postponed to the next release.
>> We will compare available solutions.
>>
>> On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin 
>> wrote:
>>
>>> guys, there is already pxz utility in ubuntu repos. let's test it
>>>
>>> On Mon, Nov 24, 2014 at 2:32 PM, Bartłomiej Piotrowski <
>>> bpiotrow...@mirantis.com> wrote:
>>>
>>>> On 24 Nov 2014, at 12:25, Matthew Mosesohn 
>>>> wrote:
>>>> > I did this exercise over many iterations during Docker container
>>>> > packing and found that as long as the data is under 1gb, it's going to
>>>> > compress really well with xz. Over 1gb and lrzip looks more attractive
>>>> > (but only on high memory systems). In reality, we're looking at log
>>>> > footprints from OpenStack environments on the order of 500mb to 2gb.
>>>> >
>>>> > xz is very slow on single-core systems with 1.5gb of memory, but it's
>>>> > quite a bit faster if you run it on a more powerful system. I've found
>>>> > level 4 compression to be the best compromise that works well enough
>>>> > that it's still far better than gzip. If increasing compression time
>>>> > by 3-5x is too much for you guys, why not just go to bzip? You'll
>>>> > still improve compression but be able to cut back on time.
>>>> >
>>>> > Best Regards,
>>>> > Matthew Mosesohn
>>>>
>>>> Alpha release of xz supports multithreading via -T (or —threads)
>>>> parameter.
>>>> We could also use pbzip2 instead of regular bzip to cut some time on
>>>> multi-core
>>>> systems.
>>>>
>>>> Regards,
>>>> Bartłomiej Piotrowski
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 45bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com <http://www.mirantis.ru/>
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
> --
> Mike Scherbakov
> #mihgen
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] rpm packages versions

[Dmitry Pyzhov]

Just FYI. We have updated versions of nailgun-related packages in 6.0:
https://review.openstack.org/#/c/137886/
https://review.openstack.org/#/c/137887/
https://review.openstack.org/#/c/137888/
https://review.openstack.org/#/c/137889/

We need it in order to support packages updates both in current version and
in stable releases.

I've updated our HCF template, so we will not forget to update it in next
releases.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

[Dmitry Pyzhov]

Thank you all for your feedback. Request postponed to the next release. We
will compare available solutions.

On Mon, Nov 24, 2014 at 2:36 PM, Vladimir Kuklin 
wrote:

> guys, there is already pxz utility in ubuntu repos. let's test it
>
> On Mon, Nov 24, 2014 at 2:32 PM, Bartłomiej Piotrowski <
> bpiotrow...@mirantis.com> wrote:
>
>> On 24 Nov 2014, at 12:25, Matthew Mosesohn 
>> wrote:
>> > I did this exercise over many iterations during Docker container
>> > packing and found that as long as the data is under 1gb, it's going to
>> > compress really well with xz. Over 1gb and lrzip looks more attractive
>> > (but only on high memory systems). In reality, we're looking at log
>> > footprints from OpenStack environments on the order of 500mb to 2gb.
>> >
>> > xz is very slow on single-core systems with 1.5gb of memory, but it's
>> > quite a bit faster if you run it on a more powerful system. I've found
>> > level 4 compression to be the best compromise that works well enough
>> > that it's still far better than gzip. If increasing compression time
>> > by 3-5x is too much for you guys, why not just go to bzip? You'll
>> > still improve compression but be able to cut back on time.
>> >
>> > Best Regards,
>> > Matthew Mosesohn
>>
>> Alpha release of xz supports multithreading via -T (or —threads)
>> parameter.
>> We could also use pbzip2 instead of regular bzip to cut some time on
>> multi-core
>> systems.
>>
>> Regards,
>> Bartłomiej Piotrowski
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

[Dmitry Pyzhov]

We have a request  for change
compression from gz to xz. This simple change halfs our snapshots. Does
anyone has any objections? Otherwise we will include this change in 6.0
release.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Fuel-dev] Detailed Fuel release version definition

[Dmitry Pyzhov]

I'm agree with Dmitry. We can change version text. Use '2014.2-6.0-pre' in
openstack.yaml and '6.0-pre' in PRODUCT_VERSION. Yep, we need to test it
first. Also think about sorting on ui and other places where we can compare
versions.

On Mon, Oct 20, 2014 at 2:36 PM, Aleksandra Fedorova  wrote:

> Hi, everyone,
>
> NOTE: I am moving this discussion into openstack-dev@ as we plan to
> deprecate fuel-...@lists.launchpad.net mailing list.
>
> Regarding the problem discussed:
>
> could you please add a bit more details about this versioning and how
> should it fit into our build process.
>
> Let's say we have 6.0 iso image. We build it now based on the
> PRODUCT_VERSION parameter from config.mk. How should we create the
> Technical Preview or GA iso images?
>
> Should we build them from scratch in a separate tasks with different set
> of predefined variables or should we choose one of the iso images we have
> and label it as Technical Preview and imprint this tag into iso somehow?
>
>
> On Mon, Oct 20, 2014 at 1:00 PM, Aleksey Kasatkin 
> wrote:
>
>> But we need to distinguish what Fuel was used to deploy this env. Aren't
>> we? E.g. install 5.1.1 env with Fuel 6.0 beta.
>> I'd propose to have both then (in version.yaml and in releases).
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Mon, Oct 20, 2014 at 11:55 AM, Alexander Kislitsky <
>> akislit...@mirantis.com> wrote:
>>
>>> Adding tag into the version will be the best solution - because we have
>>> it already implemented :-)
>>>
>>> On Mon, Oct 20, 2014 at 12:44 PM, Dmitriy Shulyak >> > wrote:
>>>
 Maybe we dont need any separate entity to store this difference?
 What if we can introduce tag of release into release version itself, so
 it will look like:
 2014.2.1-6.0-beta or 2014.2.1-6.0.beta
 and change name of the release accordingly - Ubuntu 6.0 Technical
 Preview (beta)

 Is this an option?

 On Mon, Oct 20, 2014 at 11:28 AM, Aleksey Kasatkin <
 akasat...@mirantis.com> wrote:

> AFAIC, it is more like "release_stage" or just "stage" (see
> http://en.wikipedia.org/wiki/Software_release_life_cycle).
>
> Meaning of "release_name" is may be more like "Icehouse", "Juno" in
> OpenStack.
> I'm agree to store it in verslion.yaml.
>
>
> Aleksey Kasatkin
>
>
> On Mon, Oct 20, 2014 at 11:19 AM, Mike Scherbakov <
> mscherba...@mirantis.com> wrote:
>
>> Any progress on this?
>> I support this idea in general. Alex - may be you can prepare POC for
>> this and then we will present it to the crowd?
>>
>> Thanks,
>>
>> On Wed, Oct 15, 2014 at 11:46 AM, Alexander Kislitsky <
>> akislit...@mirantis.com> wrote:
>>
>>> Hi, all!
>>>
>>> For Fuel release 6.0 we are going to have two versions: Technical
>>> Preview and GA.
>>> We need to consider these differences, for example in the statistics
>>> reports. So we need to store information about 'name of Fuel release'. I
>>> propose store this detailed information in the VERSION section of the
>>> verslion.yaml file with release info, placed in /etc/fuel/releases/. The
>>> field name can be 'release_name'.
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to : fuel-...@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to : fuel-...@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to : fuel-...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>

>>>
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to : fuel-...@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Aleksandra Fedorova
> bookwar
>
> --
> You received this message because you are subscribed to the Google Groups
> "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fuel-core-team+unsubscr...@mirantis.com.
> For more options, visit https://groups.google.com/a/mirantis.com/d/optout.
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Documentation Process changed

[Dmitry Pyzhov]

We definitely need to assign these bugs to the fuel-docs team. And there is
a good point from Alexandra Fedorova that commit message needs to have
enough information for tech writer. And reviewers should not merge fixes
that do not apply this rule. Otherwise we will end up with new bottlenecks.

One bottleneck is bug triage with bunch of badly formatted bug reports
every day. And another bottleneck is bugs on fuel-docs team. They will have
to drive each bug, find a developer, get the information, find a place for
it and so on. Let's try to make their life easier.

And another point. I don't like bug tags. You can not see them from the
milestone page. You can not filter out documentation bugs even from
advanced search page. We could try to add [doc] prefix for bug subjects
automatically. It will help a little bit.

On Thu, Oct 9, 2014 at 12:27 AM, Sergii Golovatiuk  wrote:

> Hi,
>
> Dima, that's really good approach.
>
> Mike, technical writer may ask developer and assign bug to him/her if bug
> impacts developer documentation only.
>
> Best Regards,
> Sergii Golovatiuk
>
> On 08 Oct 2014, at 21:08, Mike Scherbakov 
> wrote:
>
> Thanks Dmitry,
> let's try to go this way and correct process if needed when we get first
> results.
>
> > Where is your 80% dev vs user docs figure coming from?
> it's no more than my guess. We will see real number over time.
>
> On Wed, Oct 8, 2014 at 10:31 PM, Dmitry Borodaenko <
> dborodae...@mirantis.com> wrote:
>
>> At the moment OpenStack infrastructure doesn't allow to customize the
>> bugs it creates, we should propose a patch at some point to implement
>> that. When we do, I think we should assign such bugs automatically to
>> fuel-docs team.
>>
>> I don't think we should separate user and dev docs bugs, we're working
>> in the opposite direction towards merging dev docs into fuel-docs:
>> https://review.openstack.org/124551
>>
>> Where is your 80% dev vs user docs figure coming from?
>>
>> I think that whether it's dev or user documentation, a technical
>> writer should drive the process, collect information from the commit
>> author, and add it to the right documentation areas. It's commit
>> author's responsibility to provide an informative commit message in
>> the first place, to answer technical writer's questions, and to review
>> docs commits that address the DocImpact bug.
>>
>> On Oct 8, 2014 10:59 AM, "Mike Scherbakov" 
>> wrote:
>> >
>> > Very good improvement in our documentation process.
>> >
>> > Is there a way to configure it, so bugs would be created with tag
>> "docs" automatically? It would simplify triaging process I believe.
>> > From the other hand, as far as I understand, up to 80% of commits with
>> "DocImpact" will impact development documentation (or it's intended to be
>> affecting only user documentation?). It would be hard for tech writers, who
>> are mostly specialized in Fuel user docs, to work on low-level details of
>> how, let's say, l23network [1] works.
>> > Do we want to separate docs bugs somehow, user/dev?
>> >
>> > In other words, what would be the flow, who becomes responsible for
>> fixing bugs created automatically by Infra?
>> >
>> > [1]
>> https://github.com/stackforge/fuel-library/tree/master/deployment/puppet/l23network
>> >
>> > On Wed, Oct 8, 2014 at 5:34 PM, Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Fuel Summit '2014 we discussed our Documentation process. According
>> to follow up we aligned it to OpenStack 'DocImpact' process. The new
>> process has been tested on background by me and Bogdan Dobrelya. Today, I
>> have updated Fuel Documentation Process so we are making it official.
>> >>
>> >> Why?
>> >> Developer perspective:
>> >> It gives more flexibility for the developers to participate in
>> Documentation Process. Every time when the Reviewer sees that patch
>> requires Documentation update, it may ask the Commiter to update 'Commit
>> Message' with DocImpact message. Once patch passes the review Openstack
>> Infra will trigger a new bug in Launchpad that should be assigned to Fuel
>> Documentation team.
>> >>
>> >> From Fuel Documentation Team perspective:
>> >> When Fuel Documentation Team sees this bug they know who was the
>> commiter and reviewers and whom they should add for documentation review.
>> >>
>> >> Community:
>> >> Community member may ask the developer to put 'DocImpact' message when
>> it's required.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>  ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.or

Re: [openstack-dev] [Fuel] Goals for 5.1.1 & 6.0

[Dmitry Pyzhov]

Feature blockers:
Versioning 
for REST API
, UI,
serialization


Ongoing activities:
Nailgun plugins


Stability and Reliability:
Docs for serialization data
Docs for REST API data

Nailgun unit tests restructure
Image based provisioning

Granular deployment

Artifact-based build system
Power management
Fencing 

Features:
Advanced networking
 (blocked
by Multi L2 support)

Some of this items will not fit 6.0, I guess. But we should work on them
now.



On Thu, Aug 28, 2014 at 4:26 PM, Mike Scherbakov 
wrote:

> Hi Fuelers,
> while we are busy with last bugs which block us from releasing 5.1, we
> need to start thinking about upcoming releases. Some of you already started
> POC, some - specs, and I see discussions in ML and IRC.
>
> From overall strategy perspective, focus for 6.0 is:
>
>- OpenStack Juno release
>- Certificate 100-node deployment. In terms of OpenStack, if not
>possible for Juno, let's do for Icehouse
>- Send anonymous stats about deployment (deployment modes, features
>used, etc.)
>- Stability and Reliability
>
> Let's take a little break and think, in a first order, about features,
> sustaining items and bugs which block us from releasing whether 5.1.1 or
> 6.0.
> We have to start creating blueprints (and moving them to 6.0 milestone)
> and make sure there are critical bugs assigned to appropriate milestone, if
> there are any.
>
> Examples which come to my mind immediately:
>
>- Use service token to auth in Keystone for upgrades (affects 5.1.1),
>instead of plain admin login / pass. Otherwise it affects security, and
>user should keep password in plain text
>- Decrease upgrade tarball size
>
> Please come up with blueprints and LP bugs links, and short explanation
> why it's a blocker for upcoming releases.
>
> Thanks,
> --
> Mike Scherbakov
> #mihgen
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Pre-5.1 and master builds ISO are available for download

[Dmitry Pyzhov]

Dmitry,

I totally agree that we should support nightly builds in upgrades. I've
created a blueprint for this:
https://blueprints.launchpad.net/fuel/+spec/upgrade-nightly


On Tue, Sep 2, 2014 at 3:24 AM, Dmitry Borodaenko 
wrote:

> We should not confuse beta and rc builds, normally betas predate RCs and
> serve a different purpose. In that sense, the nightlies we currently
> publish are closest to what beta builds should be.
>
> As discussed earlier in the thread, we already have full versioning and
> provenance information in each build, so there is not a lot of value in
> inventing a parallel versioning scheme just for the time period when our
> builds are feature complete but not yet stable enough to declare an RC. The
> only benefit is to explicitly indicate the beta status of these builds, and
> we can achieve that without messing with versions. For example, by
> generating a summary table of all community builds that have passed the
> tests (using same build numbers we already have).
>
> Not supporting upgrades from/to intermediate builds is a limitation that
> we should not discard as inevitable, overcoming it should be in our
> backlog. Image based provisioning should make it much easier to support.
>
> My 2c,
> -Dmitry
> I would not use "beta" word anywhere at all. These are nightly builds,
> pre-5.1. So it will become 5.1 eventually, but for the moment - it is just
> master branch. We've not even reached HCF.
>
> After we reach HCF, we will start calling builds as Release Candidates
> (RC1, RC2, etc.)  - and QA team runs acceptance testing against them. This
> can be considered as another name instead of "beta-1", etc.
>
> Anyone can go to :8000/api/version to get sha commits of
> git repos a particular build was created of. Yes, these are development
> builds, and there will be no upgrade path provided from development build
> to 5.1 release or any other release. We might want to think about it
> though, if we could do it in theory, but I confirm what Evgeny says - we do
> not support it now.
>
>
>
> On Wed, Aug 27, 2014 at 1:11 PM, Evgeniy L  wrote:
>
>> Hi guys, I have to say something about beta releases.
>>
>> As far as I know our beta release has the same version
>> 5.1 as our final release.
>>
>> I think this versions should be different, because in case
>> of some problem it will be much easier to identify what
>> version we are trying to debug.
>>
>> Also from the irc channel I've heard that somebody wanted
>> to upgrade his system to stable version, right now it's impossible
>> because upgrade system uses this version for names of
>> containers/images/temporary directories and we have
>> validation which prevents the user to run upgrade to the
>> same version.
>>
>> In upgrade script we use python module [1] to compare versions
>> for validation.
>> Let me give an example how development versions can look like
>>
>> 5.1a1 # alpha
>> 5.1b1 # beta 1
>> 5.1b1 # beta 2
>> 5.1b1 # beta 3
>> 5.1# final release
>>
>> [1]
>> http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html
>>
>> Thanks,
>>
>>
>> On Tue, Aug 26, 2014 at 11:15 AM, Mike Scherbakov <
>> mscherba...@mirantis.com> wrote:
>>
>>> Igor,
>>> thanks a lot for improving UX over it - this table allows me to see
>>> which ISO passed verification tests.
>>>
>>>
>>> On Mon, Aug 25, 2014 at 7:54 PM, Vladimir Kuklin 
>>> wrote:
>>>
 I would also like to add that you can use our library called devops
 along with system tests we use for QA and CI. These tests use libvirt and
 kvm so that you can easily fire up an environment with specific
 configuration (Centos/Ubuntu Nova/Neutron Ceph/Swift and so on). All the
 documentation how to use this library is here:
 http://docs.mirantis.com/fuel-dev/devops.html. If you find any bugs or
 gaps in documentation, please feel free to file bugs to
 https://launchpad.net/fuel.


 On Mon, Aug 25, 2014 at 6:39 PM, Igor Shishkin 
 wrote:

> Hi all,
> along with building your own ISO following instructions [1], you can
> always download nightly build [2] and run it, by using virtualbox scripts
> [3], for example.
>
> For your conveniency, you can see a build status table on CI [4].
> First tab now refers to pre-5.1 builds, and second - to master builds.
> BVT columns stands for Build Verification Test, which is essentially
> full HA deploy deployment test.
>
> Currently pre-5.1 and master builds are actually built from same
> master branch. As soon as we call for Hard Code Freeze, pre-5.1 builds 
> will
> be reconfigured to use stable/5.1 branch.
>
> Thanks,
>
> [1]
> http://docs.mirantis.com/fuel-dev/develop/env.html#building-the-fuel-iso
> [2] https://wiki.openstack.org/wiki/Fuel#Nightly_builds
> [3] https://github.com/stackforge/fuel-main/tree/master/virtualbox
> [4] https://fuel-jenkins.mirantis.com/view/ISO/
> --

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

[Dmitry Pyzhov]

I've updated the spec: https://review.openstack.org/#/c/116874/

Major change in this spec: get rid of unpacked upgrade tarball. Use only
lrzipped archives. It will save disk space and network traffic, it will
make upgrade process longer, it will make our upgrade tests longer as well,
it will make things simpler.

Code is already merged, docs are on review, we need to update our system
tests and jenkins jobs. It will be done after merge of the spec.


On Tue, Aug 26, 2014 at 6:07 PM, Aleksandra Fedorova  wrote:

> As an update, please check and review commit [1] to fuel-specs with
> detailed feature description.
>
> According to this feature, we are going to switch our CI system to
> lrzipped tarballs.
>
> [1] https://review.openstack.org/#/c/116874/
>
>
>
> On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov 
> wrote:
>
>> Fuelers,
>>
>> Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
>> 2Gb with lrzip tool (ticket
>> <https://bugs.launchpad.net/fuel/+bug/1356813>, change in build system
>> <https://review.openstack.org/#/c/114201/>, change in docs
>> <https://review.openstack.org/#/c/115331/>), but it will dramatically
>> increase unpacking time. I've run unpack on my virtualbox environment and
>> got this result:
>> [root@fuel var]# lrzuntar fuel-5.1-upgrade.tar.lrz
>> Decompressing...
>> 100%7637.48 /   7637.48 MB
>> Average DeCompression Speed:  8.014MB/s
>> [OK] - 8008478720 bytes
>> Total time: 00:15:52.93
>>
>> My suggestion is to reject this change, release 5.1 with big tarball and
>> find another solution in next release. Any objections?
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Aleksandra Fedorova
> bookwar
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Maintenance mode for patching

[Dmitry Pyzhov]

All,

I'm not sure if it deserves to be mentioned in our documentation, this
seems to be a common practice. If an administrator wants to patch his
environment, he should be prepared for a temporary downtime of OpenStack
services. And he should plan to perform patching in advance: choose a time
with minimal load and warn users about possible interruptions of service
availability.

Our current implementation of patching does not protect from downtime
during the patching procedure. HA deployments seems to be more or less
stable. But it looks like it is possible to schedule an action on a compute
node and get an error because of service restart. Deployments with one
controller... well, you won’t be able to use your cluster until the
patching is finished. There is no way to get rid of downtime here.

As I understand, we can get rid of possible issues with computes in HA. But
it will require migration of instances and stopping of nova-compute service
before patching. And it will make the overall patching procedure much
longer. Do we want to investigate this process?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Issues with hardcoded versions of requirements in specs of packages

[Dmitry Pyzhov]

It is not enough, you need to review requirements in the code of nailgun,
ostf and astute.

I'll be happy to have our requirements files and specs as close to
global-requirements as possible. It will ruin our current solid structure,
where we have same versions of dependencies on production, on development
and test environments. And from time to time we will face issues with
updates from pypi. Development and test environments will be affected. We
somewhat protected from it by maintainers of global-requirement file. And
changes in production environments are protected by OSCI team.

So, if we want to build iso with custom packages, we have to add
flexibility to our dependencies lists. Any objections?


On Mon, Aug 25, 2014 at 8:28 PM, Timur Nurlygayanov <
tnurlygaya...@mirantis.com> wrote:

> Commit with fast fix was submitted:
> https://review.openstack.org/#/c/116667/
> Need review :)
>
> I will try to build image with this commit and will send my comments with
> my results.
>
>
> On Mon, Aug 25, 2014 at 7:55 PM, Timur Nurlygayanov <
> tnurlygaya...@mirantis.com> wrote:
>
>> When I started the build of ISO from master branch, I can see the
>> following errors:
>> https://bugs.launchpad.net/fuel/+bug/1361279
>>
>> I want to submit the patch set and remove all hardcoded requirements and
>> change all '==' to '>=', but I want to discuss how we can organize specs to
>> avoid problems with dependencies before this.
>>
>> Thank you.
>>
>>
>> On Mon, Aug 25, 2014 at 6:21 PM, Timur Nurlygayanov <
>> tnurlygaya...@mirantis.com> wrote:
>>
>>> Hi team,
>>>
>>> Today I started to build Fuel ISO from the master branch and with
>>> packages with code from the master branches, and have found strange errors:
>>>
>>> http://jenkins-product.srt.mirantis.net:8080/view/custom_iso/job/custom_master_iso/77/console
>>>
>>> Looks like we have hardcoded versions of all required packages in specs:
>>>
>>> https://github.com/stackforge/fuel-main/blob/master/packages/rpm/specs/nailgun.spec#L17-L44
>>>
>>> and this is the root of problems. In the result we can't build ISO from
>>> master branch, because we have another versions of requirements for code
>>> from master branches.
>>> Looks like it is common issue for several components.
>>>
>>> Could we discuss how we can organize specs to avoid problems with
>>> dependencies?
>>>
>>>
>>> Thank you!
>>>
>>>
>>> --
>>>
>>> Timur,
>>> QA Engineer
>>> OpenStack Projects
>>> Mirantis Inc
>>>
>>> [image: http://www.openstacksv.com/] 
>>>
>>
>>
>>
>> --
>>
>> Timur,
>>  QA Engineer
>> OpenStack Projects
>> Mirantis Inc
>>
>> [image: http://www.openstacksv.com/] 
>>
>
>
>
> --
>
> Timur,
> QA Engineer
> OpenStack Projects
> Mirantis Inc
>
> [image: http://www.openstacksv.com/] 
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

[Dmitry Pyzhov]

I see no other quick solutions in 5.1. We can find the difference in
packages between 5.0 and 5.0.2, put only updated packages in tarball and
get missed packages from existing repos on master node.


On Thu, Aug 21, 2014 at 5:55 PM, Mike Scherbakov 
wrote:

> What are other possible solutions to this issue?
>
>
> On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov 
> wrote:
>
>> Fuelers,
>>
>> Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
>> 2Gb with lrzip tool (ticket
>> <https://bugs.launchpad.net/fuel/+bug/1356813>, change in build system
>> <https://review.openstack.org/#/c/114201/>, change in docs
>> <https://review.openstack.org/#/c/115331/>), but it will dramatically
>> increase unpacking time. I've run unpack on my virtualbox environment and
>> got this result:
>> [root@fuel var]# lrzuntar fuel-5.1-upgrade.tar.lrz
>> Decompressing...
>> 100%7637.48 /   7637.48 MB
>> Average DeCompression Speed:  8.014MB/s
>> [OK] - 8008478720 bytes
>> Total time: 00:15:52.93
>>
>> My suggestion is to reject this change, release 5.1 with big tarball and
>> find another solution in next release. Any objections?
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Use lrzip for upgrade tarball - reject?

[Dmitry Pyzhov]

Fuelers,

Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by
2Gb with lrzip tool (ticket
, change
in build system , change in docs
), but it will dramatically
increase unpacking time. I've run unpack on my virtualbox environment and
got this result:
[root@fuel var]# lrzuntar fuel-5.1-upgrade.tar.lrz
Decompressing...
100%7637.48 /   7637.48 MB
Average DeCompression Speed:  8.014MB/s
[OK] - 8008478720 bytes
Total time: 00:15:52.93

My suggestion is to reject this change, release 5.1 with big tarball and
find another solution in next release. Any objections?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] 6.0 blueprints cleanup

[Dmitry Pyzhov]

We've moved all blueprints from 6.0 to 'next' milestone. It has been done
in order to better view of stuff that we really want to implement in 6.0.

Feature freeze for 6.0 release is planned to 18th of September. If you are
going to merge your blueprint before that date, you can move it to 6.0
milestone and 6.0.x series. But blueprint must have fixed scope and must be
assigned to person who will lead this activity.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

[Dmitry Pyzhov]

Sure. We can check if release is installed on any cluster and refuse to
remove it.


On Thu, Jul 3, 2014 at 6:05 PM, Aleksandr Didenko 
wrote:

> Hi,
>
> > I think we should allow user to delete unneeded releases.
>
> In this case user won't be able to add new nodes to the existing
> environments of the same version. So we should check and warn user about
> it, or simply not allow to delete releases if there are live envs with the
> same version.
>
>
>
> On Thu, Jul 3, 2014 at 3:45 PM, Dmitry Pyzhov 
> wrote:
>
>> So, our releases will have following versions of releases on UI:
>> 5.0) "2014.1"
>> 5.0.1) "2014.1.1-5.0.1"
>> 5.1) "2014.1.1-5.1"
>>
>> And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1,
>> he will have three releases for each OS. I think we should allow user to
>> delete unneeded releases. It also will add free space on his masternode.
>>
>>
>> On Wed, Jul 2, 2014 at 1:34 PM, Igor Kalnitsky 
>> wrote:
>>
>>> Hello,
>>>
>>> > Could you please clarify what exactly you mean by  "our patches" /
>>> > "our first patch"?
>>>
>>> I mean which version should we use in 5.0.1, for example? As far as I
>>> understand @DmitryB, it have to be "2014.1-5.0.1". Am I right?
>>>
>>> Thanks,
>>> Igor
>>>
>>>
>>>
>>> On Tue, Jul 1, 2014 at 8:47 PM, Aleksandr Didenko >> > wrote:
>>>
>>>> Hi,
>>>>
>>>> my 2 cents:
>>>>
>>>> 1) Fuel version (+1 to Dmitry)
>>>> 2) Could you please clarify what exactly you mean by "our patches" /
>>>> "our first patch"?
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Jul 1, 2014 at 8:04 PM, Dmitry Borodaenko <
>>>> dborodae...@mirantis.com> wrote:
>>>>
>>>>> 1) Puppet manifests are part of Fuel so the version of Fuel should be
>>>>> used. It is possible to have more than one version of Fuel per
>>>>> OpenStack version, but not the other way around: if we upgrade
>>>>> OpenStack version we also increase version of Fuel.
>>>>>
>>>>> 2) Should be a combination of both: it should indicate which OpenStack
>>>>> version it is based on (2014.1.1), and version of Fuel it's included
>>>>> in (5.0.1), e.g. 2014.1.1-5.0.1. Between Fuel versions, we can have
>>>>> additional bugfix patches added to shipped OpenStack components.
>>>>>
>>>>> my 2c,
>>>>> -DmitryB
>>>>>
>>>>>
>>>>> On Tue, Jul 1, 2014 at 9:50 AM, Igor Kalnitsky <
>>>>> ikalnit...@mirantis.com> wrote:
>>>>> > Hi fuelers,
>>>>> >
>>>>> > I'm working on Patching for OpenStack and I have the following
>>>>> questions:
>>>>> >
>>>>> > 1/ We need to save new puppets and repos under some versioned folder:
>>>>> >
>>>>> > /etc/puppet/{version}/ or /var/www/nailgun/{version}/centos.
>>>>> >
>>>>> > So the question is which version to use? Fuel or OpenStack?
>>>>> >
>>>>> > 2/ Which version we have to use for our patchs? We have an OpenStack
>>>>> 2014.1.
>>>>> > Should we use 2014.1.1 for our first patch? Or we have to use another
>>>>> > format?
>>>>> >
>>>>> > I need a quick reply since these questions have to be solved for
>>>>> 5.0.1 too.
>>>>> >
>>>>> > Thanks,
>>>>> > Igor
>>>>> >
>>>>> >
>>>>> > ___
>>>>> > OpenStack-dev mailing list
>>>>> > OpenStack-dev@lists.openstack.org
>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Borodaenko
>>>>>
>>>>> ___
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev@lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Blueprints process

[Dmitry Pyzhov]

Do not cheat. If we need to add functionality after feature freeze, then
let add functionality after feature freeze. No reason for additional
obfuscation. It will make our workflow for blueprints harder, but it will
help us. We will see what we are really going to do and plan our work
better.

Also we can create a beta iso with all features in 'beta available' status.
It will help to make sure that small improvements are not break anything
and can be merged without any fear.


On Tue, Jul 1, 2014 at 3:00 PM, Vladimir Kuklin 
wrote:

> I have some objections. We are trying to follow a strict development
> workflow with feature freeze stage. In this case we will have to miss small
> enhancements that can emerge after FF date and can bring essential benefits
> along with small risks of breaking anything (e.g. changing some config
> options for galera or other stuff). We maintained such small changes as
> bugs because of this FF rule. As our project is growing, these last minute
> calls for small changes are going to be more and more probable. My
> suggestion is that we somehow modify our workflow allowing these small
> features to get through FF stage or we are risking to have an endless queue
> of enhancements that users will never see in the release.
>
>
> On Thu, Jun 26, 2014 at 8:07 PM, Matthew Mosesohn 
> wrote:
>
>> +1
>>
>> Keeping features separate as blueprints (even tiny ones with no spec)
>> really will let us focus on the volume of real bugs.
>>
>> On Tue, Jun 24, 2014 at 5:14 PM, Dmitry Pyzhov 
>> wrote:
>> > Guys,
>> >
>> > We have a beautiful contribution guide:
>> > https://wiki.openstack.org/wiki/Fuel/How_to_contribute
>> >
>> > However, I would like to address several issues in our blueprints/bugs
>> > processes. Let's discuss and vote on my proposals.
>> >
>> > 1) First of all, the bug counter is an excellent metric for quality. So
>> > let's use it only for bugs and track all feature requirement as
>> blueprints.
>> > Here is what it means:
>> >
>> > 1a) If a bug report does not describe a user’s pain, a blueprint should
>> be
>> > created and bug should be closed as invalid
>> > 1b) If a bug report does relate to a user’s pain, a blueprint should be
>> > created and linked to the bug
>> > 1c) We have an excellent reporting tool, but it needs more metrics:
>> count of
>> > critical/high bugs, count of bugs assigned to each team. It will require
>> > support of team members lists, but it seems that we really need it.
>> >
>> >
>> > 2) We have a huge amount of blueprints and it is hard to work with this
>> > list. A good blueprint needs a fixed scope, spec review and acceptance
>> > criteria. It is obvious for me that we can not work on blueprints that
>> do
>> > not meet these requirements. Therefore:
>> >
>> > 2a) Let's copy the nova future series and create a fake milestone
>> 'next' as
>> > nova does. All unclear blueprints should be moved there. We will pick
>> > blueprints from there, add spec and other info and target them to a
>> > milestone when we are really ready to work on a particular blueprint.
>> Our
>> > release page will look much more close to reality and much more
>> readable in
>> > this case.
>> > 2b) Each blueprint in a milestone should contain information about
>> feature
>> > lead, design reviewers, developers, qa, acceptance criteria. Spec is
>> > optional for trivial blueprints. If a spec is created, the designated
>> > reviewer(s) should put (+1) right into the blueprint description.
>> > 2c) Every blueprint spec should be updated before feature freeze with
>> the
>> > latest actual information. Actually, I'm not sure if we care about spec
>> > after feature development, but it seems to be logical to have correct
>> > information in specs.
>> > 2d) We should avoid creating interconnected blueprints wherever
>> possible. Of
>> > course we can have several blueprints for one big feature if it can be
>> split
>> > into several shippable blocks for several releases or for several
>> teams. In
>> > most cases, small parts should be tracked as work items of a single
>> > blueprint.
>> >
>> >
>> > 3) Every review request without a bug or blueprint link should be
>> checked
>> > carefully.
>> >
>> > 3a) It should contain a complete description of what is being done and
>> why
>> > 3b) It should not requi

Re: [openstack-dev] [Fuel] Few hot questions related to patching for openstack

[Dmitry Pyzhov]

So, our releases will have following versions of releases on UI:
5.0) "2014.1"
5.0.1) "2014.1.1-5.0.1"
5.1) "2014.1.1-5.1"

And if someone install 5.0, upgrade it to 5.0.1 and then upgrade to 5.1, he
will have three releases for each OS. I think we should allow user to
delete unneeded releases. It also will add free space on his masternode.


On Wed, Jul 2, 2014 at 1:34 PM, Igor Kalnitsky 
wrote:

> Hello,
>
> > Could you please clarify what exactly you mean by  "our patches" /
> > "our first patch"?
>
> I mean which version should we use in 5.0.1, for example? As far as I
> understand @DmitryB, it have to be "2014.1-5.0.1". Am I right?
>
> Thanks,
> Igor
>
>
>
> On Tue, Jul 1, 2014 at 8:47 PM, Aleksandr Didenko 
> wrote:
>
>> Hi,
>>
>> my 2 cents:
>>
>> 1) Fuel version (+1 to Dmitry)
>> 2) Could you please clarify what exactly you mean by "our patches" / "our
>> first patch"?
>>
>>
>>
>>
>> On Tue, Jul 1, 2014 at 8:04 PM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> 1) Puppet manifests are part of Fuel so the version of Fuel should be
>>> used. It is possible to have more than one version of Fuel per
>>> OpenStack version, but not the other way around: if we upgrade
>>> OpenStack version we also increase version of Fuel.
>>>
>>> 2) Should be a combination of both: it should indicate which OpenStack
>>> version it is based on (2014.1.1), and version of Fuel it's included
>>> in (5.0.1), e.g. 2014.1.1-5.0.1. Between Fuel versions, we can have
>>> additional bugfix patches added to shipped OpenStack components.
>>>
>>> my 2c,
>>> -DmitryB
>>>
>>>
>>> On Tue, Jul 1, 2014 at 9:50 AM, Igor Kalnitsky 
>>> wrote:
>>> > Hi fuelers,
>>> >
>>> > I'm working on Patching for OpenStack and I have the following
>>> questions:
>>> >
>>> > 1/ We need to save new puppets and repos under some versioned folder:
>>> >
>>> > /etc/puppet/{version}/ or /var/www/nailgun/{version}/centos.
>>> >
>>> > So the question is which version to use? Fuel or OpenStack?
>>> >
>>> > 2/ Which version we have to use for our patchs? We have an OpenStack
>>> 2014.1.
>>> > Should we use 2014.1.1 for our first patch? Or we have to use another
>>> > format?
>>> >
>>> > I need a quick reply since these questions have to be solved for 5.0.1
>>> too.
>>> >
>>> > Thanks,
>>> > Igor
>>> >
>>> >
>>> > ___
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>>
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Bug sqashing

[Dmitry Pyzhov]

We are really close to 5.0.1 release and 5.1 feature freeze. So I skip bug
squash day this week.

And I suggest additional action for next squash: let's review all existing
bugs and link them to blueprints if fix requires new functionality. And
close every bug report if it is not related to any issue and appears to be
pure feature request.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Triaging bugs: milestones vs release series

[Dmitry Pyzhov]

+1


On Tue, Jul 1, 2014 at 2:33 AM, Dmitry Borodaenko 
wrote:

> When you create a bug against a project (in our case, fuel) in
> Launchpad, it is always initially targeted at the default release
> series (currently, 5.1.x). On the bug summary, that isn't explicitly
> stated and shows as being targeted to the project in general (Fuel for
> OpenStack). As you add more release series to a bug, these will be
> listed under release series name (e.g. 5.0.x).
>
> Unfortunately, Launchpad doesn't limit the list of milestones you can
> target to the targeted release series, so it will happily allow you to
> target a bug at 4.1.x release series and set milestone in that series
> to 5.1.
>
> A less obvious inconsistency is when a bug is found in a stable
> release series like 5.0.x: it seems natural to target it to milestone
> like 5.0.1 and be done with it. The problem with that approach is that
> there's no way to reflect whether this bug is relevant for current
> release series (5.1.x) and if it is, to track status of the fix
> separately in current and stable release series.
>
> Therefore, when triaging new bugs in stable versions of Fuel or
> Mirantis OpenStack, please set the milestone to the next release in
> the current release focus (5.1.x), and target to the series it was
> found in separately. If there are more recent stable release series,
> target those as well.
>
> Example: a bug is found in 4.1.1. Set primary milestone to 5.1 (as
> long as current release focus is 5.1.x and 5.1 is the next milestone
> in that series), target 2 more release series: 4.1.x and 5.0.x, set
> milestones for those to 4.1.2 and 5.0.1 respectively.
>
> If there is reason to believe that the bug does not apply to some of
> the targeted release series, explain that in the commit and mark the
> bug Invalid for that release series. If the bug is present in a series
> but cannot be addressed there (e.g. priority is not high enough to do
> a backport), mark it Won't Fix for that series.
>
> If there are no objections to this approach, I'll put it in Fuel wiki.
>
> Thanks,
> -DmitryB
>
> --
> Dmitry Borodaenko
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Changes in iso build because of feature groups

[Dmitry Pyzhov]

Guys,

We are going to merge feature groups
, it will cause
small changes in iso build parameters.

MIRANTIS parameter is deprecated, please use FEATURE_GROUPS=mirantis
instead.

Another available feature group is 'experimental'. Without it some untested
options (zabbix at the moment) will not be shown on UI. You can manually
modify settings.yaml and restart nailgun to enable them.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Blueprints process

[Dmitry Pyzhov]

Guys,

We have a beautiful contribution guide:
https://wiki.openstack.org/wiki/Fuel/How_to_contribute

However, I would like to address several issues in our blueprints/bugs
processes. Let's discuss and vote on my proposals.

1) First of all, the bug counter is an excellent metric for quality. So
let's use it only for bugs and track all feature requirement as blueprints.
Here is what it means:

1a) If a bug report does not describe a user’s pain, a blueprint should be
created and bug should be closed as invalid
1b) If a bug report does relate to a user’s pain, a blueprint should be
created and linked to the bug
1c) We have an excellent reporting tool
, but it needs more
metrics: count of critical/high bugs, count of bugs assigned to each team.
It will require support of team members lists, but it seems that we really
need it.


2) We have a huge amount of blueprints and it is hard to work with this
list. A good blueprint needs a fixed scope, spec review and acceptance
criteria. It is obvious for me that we can not work on blueprints that do
not meet these requirements. Therefore:

2a) Let's copy the nova future series 
and create a fake milestone 'next' as nova does
. All unclear blueprints should
be moved there. We will pick blueprints from there, add spec and other info
and target them to a milestone when we are really ready to work on a
particular blueprint. Our release page
 will look much more close to
reality and much more readable in this case.
2b) Each blueprint in a milestone should contain information about feature
lead, design reviewers, developers, qa, acceptance criteria. Spec is
optional for trivial blueprints. If a spec is created, the designated
reviewer(s) should put (+1) right into the blueprint description.
2c) Every blueprint spec should be updated before feature freeze with the
latest actual information. Actually, I'm not sure if we care about spec
after feature development, but it seems to be logical to have correct
information in specs.
2d) We should avoid creating interconnected blueprints wherever possible.
Of course we can have several blueprints for one big feature if it can be
split into several shippable blocks for several releases or for several
teams. In most cases, small parts should be tracked as work items of a
single blueprint.


3) Every review request without a bug or blueprint link should be checked
carefully.

3a) It should contain a complete description of what is being done and why
3b) It should not require backports to stable branches (backports are
bugfixes only)
3c) It should not require changes to documentation or be mentioned in
release notes
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Bug squashing day on Tu, 24th of June

[Dmitry Pyzhov]

Fuelers,

Ok, today is bug squash day. No activities except bugs triage
/fix/review/merge.

Current count:
17 new bugs

25 incomplete bugs

92 critical/high bugs in 5.1 in confirmed/triaged state

238 medium/low/undefined bugs in 5.1 in confirmed/triaged state

67 bugs in progress in 5.1


27 customer-found bugs in total


Let the mortal kombat begin!



On Sat, Jun 21, 2014 at 2:58 AM, Dmitry Borodaenko  wrote:

> No, we should have every day as review day. If there's code waiting to
> be reviewed that addresses a bug or a feature, there's simply no good
> reason to write new code for a different bug or feature with the same
> priority until the code that's already out there is reviewed.
>
> On Fri, Jun 20, 2014 at 11:16 AM, Andrew Woodward 
> wrote:
> > Should we also have the 25th as review day so we can squish those down
> too?
> >
> > On Fri, Jun 20, 2014 at 6:30 AM, Mike Scherbakov
> >  wrote:
> >> Fuelers,
> >> we need to group and enforce bug squashing activities on Tuesday, as
> >> discussed on IRC meeting this Thursday [1]. Feel free to do bug triaging
> >> first on Monday if needed.
> >> We have lots of bugs, and to meet quality criteria for the release we
> really
> >> need this.
> >>
> >> Every dedicated Fuel developer should stop all other activities and
> dedicate
> >> this day to bugs only. Follow instructions from last bug 

[openstack-dev] [Fuel] RIP linux as a boot option for PXE nodes

[Dmitry Pyzhov]

Vladimir has a proposal to add rescue livecd image as a boot option for PXE
nodes. I think it is a great idea. If anyone has other opinions, please
reply.

Miroslav, could you be a reviewer for this blueprint?
Anastasia, could you propose someone for QA?

https://blueprints.launchpad.net/fuel/+spec/rip-linux-pxe-options
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Review blueprint specs on gerrit

[Dmitry Pyzhov]

Guys,

from now on we should keep all our 5.1 blueprint specs in one place: fuel-specs
repo . We do it same way as nova,
so you can use their
instructionas a
guideline.

Once again. All specifications for 5.1 blueprints need to be moved to
stackforge. Here is example link:
https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst.

Jenkins builds every request and adds link to html docs to the comments.
For example: https://review.openstack.org/#/c/96145/.

I propose to send feedback for this workflow into this mailing thread.

Also, take a look on review
guidelines.
It contains some useful information, you know.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] How to install openstack into containers using FUEL?

[Dmitry Pyzhov]

Nobody tried to use docker for slave nodes, I guess.

Actually, you will face several issues. First, you need to install basic
system into docker, install packages and run our postinstall script from
our kickstart 
file.
After that you will need to make sure that nailgun agent sends information
to master node. It will allow you to see node on ui and add it to cluster.
Then you can either manually modify our database and set 'provisioned' flag
for node, or use 'fuel' console client to run deployment without
provisioning.

After that you'll need to solve issues with storages, if any. Almost every
storage expects particular filesystem to be present.

Also our master node use docker for services management in 5.0 release.

If you going to implement it, please share results. It will be very helpful.

On Mon, May 5, 2014 at 2:09 PM, Konstantin Danilov wrote:

> Hi all,
>
> At the moment I'm using FUEL with vagrant. This combination allows only
> emulation mode
> (qemu), which provides too low vm performance. I want install openstack
> into containers
> (Docker, as example) using FUEL, as this would allows me to use full speed
> virtualization with kvm, but seems like FUEL support only nodes, which
> booted using PXE boot using FUEL image. This is impossible in case of
> containers. Is there any way to install FUEL services and make all
> necessary settings to already running node? Or any other way to add node to
> FUEL without PXE boot?
>
> Thanks
>
> --
> Kostiantyn Danilov aka koder.ua
> Principal software engineer, Mirantis
>
> skype:koder.ua
> http://koder-ua.blogspot.com/
> http://mirantis.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "fuel-core-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fuel-core-team+unsubscr...@mirantis.com.
> For more options, visit https://groups.google.com/a/mirantis.com/d/optout.
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Migration to packages, step 2/2

[Dmitry Pyzhov]

Mirrors cleanup is done. No more gems, no more source files for third-party
tools. Only centos and ubuntu packages.

Next and the last action item - create astute package during iso build.

On Mon, Apr 21, 2014 at 2:10 PM, Dmitry Pyzhov  wrote:

> How does it impact development process? If I change code of, let's say,
>> shotgun, and then run "make iso", will I get an ISO with my code of
>> shotgun? What about other packages, sources of which I did not touch (let's
>> say nailgun) ?
>
> Everything is packaged, with two exceptions: *astute* and third-party
> packages for nailgun-agent. We are working on it.
>
> How far we became from implementing simple command to build an OpenStack
>> package from source?
>
> Not even a bit closer. Design for OpenStack packages is in progress.
>
> What is the time difference, is ISO build became faster? Can you provide
>> numbers?
>
> A little bit faster. I did not perform precise measurements and we still
> need remove gem mirror. It will be something like decreasing from 22
> minutes to 17 minutes.
>
> We still have puppet modules not packaged, right? Do we have plans for
>> packaging it too?
>
> Yes, puppet is not packaged. It is in our post-5.0 plans.
>
> On Sat, Apr 19, 2014 at 12:55 AM, Mike Scherbakov <
> mscherba...@mirantis.com> wrote:
>
>> That's cool actually.
>> I have a few specific questions:
>>
>>1. How does it impact development process? If I change code of, let's
>>say, shotgun, and then run "make iso", will I get an ISO with my code of
>>shotgun? What about other packages, sources of which I did not touch 
>> (let's
>>say nailgun) ?
>>2. How far we became from implementing simple command to build an
>>OpenStack package from source?
>>3. What is the time difference, is ISO build became faster? Can you
>>provide numbers?
>>4. We still have puppet modules not packaged, right? Do we have plans
>>for packaging it too?
>>
>> I assume we will document the usage of this somewhere in dev docs too.
>>
>> Thanks,
>>
>>
>> On Fri, Apr 18, 2014 at 6:06 PM, Dmitry Pyzhov wrote:
>>
>>> Guys,
>>>
>>> I've removed ability to use eggs packages on master node:
>>> https://review.openstack.org/#/c/88012/
>>>
>>> Next step is to remove gems mirror:
>>> https://review.openstack.org/#/c/88278/
>>> It will be merged when osci team fix rubygem-yajl-ruby package.
>>> Hopefully on Monday.
>>>
>>> From that moment all our code will be installed everywhere from
>>> packages. And there will be option to build packages during iso build or
>>> use pre-built packages from our mirrors.
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Migrate to Postrgresql 9

[Dmitry Pyzhov]

I've created a ticket: https://bugs.launchpad.net/fuel/+bug/1311030


On Tue, Apr 22, 2014 at 10:54 AM, Mike Scherbakov
wrote:

> Ideally such things should land at the beginning of new release cycle, and
> definitely not after feature freeze. Let's make an exception, if it is very
> well tested by many on dev envs.
> If we make an exception, I suggest to switch it quickly - in order to have
> more time before release for testing, with the possibility to revert it
> back at any moment.
>
> Thanks,
>
>
> On Tue, Apr 22, 2014 at 1:53 AM, Vladimir Kuklin wrote:
>
>> +MAX_ULONG :-)
>>
>>
>> On Tue, Apr 22, 2014 at 1:28 AM, Dmitry Borodaenko <
>> dborodae...@mirantis.com> wrote:
>>
>>> +++
>>>
>>> We already use PostgreSQL 9 on some of our dev boxes, and Nailgun
>>> works fine in fake mode and unit tests, so the risk of upgrading it
>>> now is minimal. I agree with Dmitry P. that it will cost us more to
>>> postpone it and make that upgrade a part of Fuel upgrade.
>>>
>>> -DmitryB
>>>
>>> On Mon, Apr 21, 2014 at 1:58 PM, Jay Pipes  wrote:
>>> > On Tue, 2014-04-22 at 00:55 +0400, Dmitry Pyzhov wrote:
>>> >> We use postgresql 8 on master node right now. At some point we will
>>> >> have to migrate to 9th version. And database migration can became
>>> >> painful part of master node upgrade at that point.
>>> >>
>>> >> At the moment part of our developers use psql9 in their environments
>>> >> and see no issues. Should we enforce upgrade before 5.0 release?
>>> >
>>> > ++
>>> >
>>> > -jay
>>> >
>>> >
>>> >
>>> > ___
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev@lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> --
>>> Dmitry Borodaenko
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 45bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com <http://www.mirantis.ru/>
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Migrate to Postrgresql 9

[Dmitry Pyzhov]

We use postgresql 8 on master node right now. At some point we will have to
migrate to 9th version. And database migration can became painful part of
master node upgrade at that point.

At the moment part of our developers use psql9 in their environments and
see no issues. Should we enforce upgrade before 5.0 release?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Migration to packages, step 1/2

[Dmitry Pyzhov]

>
> How does it impact development process? If I change code of, let's say,
> shotgun, and then run "make iso", will I get an ISO with my code of
> shotgun? What about other packages, sources of which I did not touch (let's
> say nailgun) ?

Everything is packaged, with two exceptions: *astute* and third-party
packages for nailgun-agent. We are working on it.

How far we became from implementing simple command to build an OpenStack
> package from source?

Not even a bit closer. Design for OpenStack packages is in progress.

What is the time difference, is ISO build became faster? Can you provide
> numbers?

A little bit faster. I did not perform precise measurements and we still
need remove gem mirror. It will be something like decreasing from 22
minutes to 17 minutes.

We still have puppet modules not packaged, right? Do we have plans for
> packaging it too?

Yes, puppet is not packaged. It is in our post-5.0 plans.

On Sat, Apr 19, 2014 at 12:55 AM, Mike Scherbakov
wrote:

> That's cool actually.
> I have a few specific questions:
>
>1. How does it impact development process? If I change code of, let's
>say, shotgun, and then run "make iso", will I get an ISO with my code of
>shotgun? What about other packages, sources of which I did not touch (let's
>say nailgun) ?
>2. How far we became from implementing simple command to build an
>OpenStack package from source?
>3. What is the time difference, is ISO build became faster? Can you
>provide numbers?
>4. We still have puppet modules not packaged, right? Do we have plans
>for packaging it too?
>
> I assume we will document the usage of this somewhere in dev docs too.
>
> Thanks,
>
>
> On Fri, Apr 18, 2014 at 6:06 PM, Dmitry Pyzhov wrote:
>
>> Guys,
>>
>> I've removed ability to use eggs packages on master node:
>> https://review.openstack.org/#/c/88012/
>>
>> Next step is to remove gems mirror:
>> https://review.openstack.org/#/c/88278/
>> It will be merged when osci team fix rubygem-yajl-ruby package. Hopefully
>> on Monday.
>>
>> From that moment all our code will be installed everywhere from packages.
>> And there will be option to build packages during iso build or use
>> pre-built packages from our mirrors.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Migration to packages, step 1/2

[Dmitry Pyzhov]

Guys,

I've removed ability to use eggs packages on master node:
https://review.openstack.org/#/c/88012/

Next step is to remove gems mirror: https://review.openstack.org/#/c/88278/
It will be merged when osci team fix rubygem-yajl-ruby package. Hopefully
on Monday.

>From that moment all our code will be installed everywhere from packages.
And there will be option to build packages during iso build or use
pre-built packages from our mirrors.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Code merge policy

[Dmitry Pyzhov]

So every developer should manually mark every such review as WIP? And
remove this flag only when everyone agreed to merge? This will require
additional actions in 50% of fuel-web and 100% of fuel-main reviews.
Developers make mistakes too.

Let's just be more accurate.


On Tue, Apr 15, 2014 at 6:41 PM, Mike Scherbakov
wrote:

> Humans make mistakes... all the time. Let's think how we can automate this
> to have appropriate Jenkins check. In this particular case, we could do the
> following:
> a) make it "work in progress" if we still unsure on some deps
> b) can we have smoke test which would check that master node builds, and
> simplest deploy passes? This needs to be run only if there are changes
> discovered in ISO build script (including mirror changes), and puppet
> manifests which deploy master node
>
>
>
> On Tue, Apr 15, 2014 at 3:49 PM, Dmitry Pyzhov wrote:
>
>> Guys,
>>
>> We have big and complicated structure of the project. And part of our
>> patchsets require additional actions before merge. Sometimes we need
>> approve from testers, sometimes we need merge requests in several repos at
>> the same time, sometimes we need updates of rpm repositories before merge.
>>
>> We have informal rule: invite all the required persons to the review. And
>> core reviewer does not merge code if part of +1's are missed. Sad, but this
>> rule is not obvious.
>>
>> This informal rule became even more strict when we need update of rpm/deb
>> repositories, because OSCI changes should be accomplished right before
>> merge. For such reviews we ask OSCI team to do changes, checks and merge.
>>
>> https://review.openstack.org/#/c/86001/ This particular request requires
>> check of our 4.1.1 rpm/deb repositories status. Thats why Roman Vyalov is
>> added as reviewer.
>>
>> I don't like over-bureaucracy. My suggestion is simple: take into account
>> reviewers status and do not merge if unsure.
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Mike Scherbakov
> #mihgen
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Fuel] Code merge policy

[Dmitry Pyzhov]

Guys,

We have big and complicated structure of the project. And part of our
patchsets require additional actions before merge. Sometimes we need
approve from testers, sometimes we need merge requests in several repos at
the same time, sometimes we need updates of rpm repositories before merge.

We have informal rule: invite all the required persons to the review. And
core reviewer does not merge code if part of +1's are missed. Sad, but this
rule is not obvious.

This informal rule became even more strict when we need update of rpm/deb
repositories, because OSCI changes should be accomplished right before
merge. For such reviews we ask OSCI team to do changes, checks and merge.

https://review.openstack.org/#/c/86001/ This particular request requires
check of our 4.1.1 rpm/deb repositories status. Thats why Roman Vyalov is
added as reviewer.

I don't like over-bureaucracy. My suggestion is simple: take into account
reviewers status and do not merge if unsure.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Problem with kombu version.

[Dmitry Pyzhov]

We are going to move to kombu==2.5.14 today. Right now we have 2.1.8.

2.5.14 meets global-requirements.txt, and 3.0 does not. Because >=3.0 is
much more strict requirement then >=2.4.8. We can try to migrate to kombu
3.0, but looks like we have no resources for this in 5.0. It needs to be
fully tested before update.


On Wed, Apr 9, 2014 at 3:38 PM, Matthew Mosesohn wrote:

> Dmitry, I don't think you should drop kombu.five so soon.
> We haven't heard directly from Fuel python team, such as Dmitry
> Pyzhov, what reason we have to lock kombu at version 2.5.14.
> I wrote to him earlier today out of band, so hopefully he will get
> back to this message soon.
>
> On Wed, Apr 9, 2014 at 3:27 PM, Dmitry Teselkin 
> wrote:
> > Hi again,
> >
> > So there is a reply from the Dmitry Burmistrov which for some reason was
> > missed in this thread:
> >> Nailgun requires exact version of kombu ( == 2.5.14 ).
> >> This is the only reason why we can't update it.
> >> I think you should talk to Dmitry P. about this version conflict.
> >> I want to take this opportunity to remind everyone that we should
> >> adhere to the global-requirements.txt in order to avoid such
> >> conflicts.
> >
> > Hopefully our developers decided to get rid of kombu.five usage what
> looks
> > an easy task.
> >
> > Thanks, everyone.
> >
> >
> >
> > On Mon, Apr 7, 2014 at 8:33 PM, Dmitry Teselkin 
> > wrote:
> >>
> >> Hello,
> >>
> >> I'm working on Murano integration into FUEL-5.0, and have faced the
> >> following problem: our current implementation depends on 'kombu.five'
> >> module, but this module (actually a single file) is available only
> starting
> >> at kombu 3.0. So this means that murano-api component depends on kombu
> >> >=3.0. This meets the OpenStack global requirements list, where kombu
> >> >=2.4.8 is declared. Unfortunately, this also means that "system-wide"
> >> version upgrade is required.
> >>
> >> So the question is - what is the right way to solve the promblem? I see
> >> the following options:
> >> 1. change kombu version requirement to >=3.0 for entire FUEL
> installation
> >> - it doesn't break global requirements constraint but some other FUEL
> >> components could be affected.
> >> 2. replace calls to functions from 'python.kombu' and use existing
> version
> >> - I'm not sure if it's possible, I'm awaiting answer from our
> developers.
> >>
> >> Which is the most suitable variant, or are there any other solutions for
> >> the problem?
> >>
> >>
> >> --
> >> Thanks,
> >> Dmitry Teselkin
> >> Deployment Engineer
> >> Mirantis
> >> http://www.mirantis.com
> >
> >
> >
> >
> > --
> > Thanks,
> > Dmitry Teselkin
> > Deployment Engineer
> > Mirantis
> > http://www.mirantis.com
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev