16:01:39 <xarses> #startmeeting fuel
16:01:39 <openstack> Meeting started Thu Nov 19 16:01:39 2015 UTC and is due to finish in 60 minutes.  The chair is xarses. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:39 <xarses> #chair xarses
16:01:39 <xarses> Todays Agenda:
16:01:39 <xarses> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:01:39 <xarses> Who's here?
16:01:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:43 <openstack> The meeting name has been set to 'fuel'
16:01:43 <maximov> hi
16:01:44 <openstack> Current chairs: xarses
16:01:44 <angdraug> o/
16:01:45 <mwhahaha> hi
16:01:48 <vsakharov> hi
16:01:52 <mihgen> hi
16:02:03 <fzhadaev> Hi
16:02:04 <ashtokolov> o/
16:02:05 <akislitsky_> hi
16:02:10 <kozhukalov_> hi
16:02:13 <monester> hi
16:02:14 <rmoe> hi
16:02:16 <asvechnikov_> hi
16:02:21 <igorbelikov> o/
16:02:24 <aroma> hi
16:02:31 <salmon_> hi
16:02:35 <akaszuba> hi
16:02:39 <ikalnitsky> o/
16:02:41 <xarses> There are no action items from last week, so we will just move directly into topics
16:02:50 <xarses> #topic Telco Team Status (vsakharov)
16:02:55 <vsakharov> Hello!
16:02:57 <yottatsa> hi
16:03:00 <vsakharov> Telco team is continue work on Ubuntu bootsrap feature.
16:03:00 <vsakharov> Here is the current status:
16:03:00 <vsakharov> 1) Implementation of UX improvements for Fuel Menu that were discussed on demo is in progress.
16:03:00 <vsakharov> 2) Work on CLI for managing bootstrap images in progress.
16:03:00 <vsakharov> 3) Work on modifying fuel-library in progress. Most basic functionality is done.
16:03:01 <vsakharov> 4) Bootstrap creation script enhancements: work in progress, 60% of all commits were merged.
16:03:03 <vsakharov> 5) Nailgun-agent enhancement was merged.
16:04:03 <xarses> vsakharov: any issues you see meeting SCF?
16:04:13 <mihgen> FF, not SCF
16:04:42 <vsakharov> No, I guess we can do it in time.
16:05:11 <xarses> thanks
16:05:13 <mattymo> hi all
16:05:17 <xarses> #topic Enhancements Team Status (ashtokolov)
16:05:40 <ashtokolov> Enhancements weekly status: Inbox - 63(was 63), In progress - 12(was 12), On review - 24(was 23)
16:05:46 <ashtokolov> QA - 10(was 15), Done - 31(was 24)
16:05:55 <ashtokolov> Fix committed+Fix released = 41 (was 39)
16:06:00 <ashtokolov> Also we are working on:
16:06:06 <ashtokolov> 1. Upload any valid IP as a VIP address
16:06:16 <ashtokolov> 2. Support for external dashboard plugin entries in Nailgun + astute improvements
16:06:33 <ashtokolov> Support for external dashboard plugin entries in Nailgun for Plugins with option to show them on the Equipment dashboard
16:06:59 <ashtokolov> That's all from my team
16:07:12 <angdraug> forgot the part about fixing all our gates :D
16:07:23 <ashtokolov> =)
16:07:42 <ashtokolov> 4. Fuel under BigTent
16:07:48 <xarses> ashtokolov: its fantastic that we are making progress here
16:08:10 <xarses> thanks
16:08:17 <ashtokolov> Thank you
16:08:18 <xarses> #topic UI Team status (vkramskikh)
16:08:22 <vkramskikh> Hi! We continue to work on user stories of Iteration #3. They are partially merged, so you already may have seen some changes, including the new network tab with Multirack support and the global page with all nodes managed by Fuel. Both features are still under development, so expect bugs and further changes.
16:08:22 <vkramskikh> Except these two features we're also working on supporting links to plugin dashboard and I also really like to reorganize settings on our new settings tab grouped by category to avoid having settings from one section in openstack.yaml assigned to different groups, but that would also require changes in puppet manifests, existing plugins, wizard config, etc so it might not make it to 8.0.
16:08:23 <vkramskikh> We're also working on moving settings with "networking" group to the network tab instead of the settings tab.
16:08:25 <vkramskikh> As for Separate deployment and provisioning in UI, we decided not to ship it to 8.0 due to backend issues and to return to this feature in the next release and plan backend changes properly. So if you're working on one of the bugs we've found for this feature, you should probably switch to something else.
16:08:31 <vkramskikh> That's all for today, thanks!
16:09:59 <xarses> vkramskikh: you expect that these might not make FF
16:10:02 <mihgen> reorginize settings - we will need to ensure backward compatibility
16:10:12 <bgaifullin> hi all
16:10:15 <xarses> is there anything that we can do here to help them land?
16:10:32 <vkramskikh> xarses: yes, though I have concerns about reorganizing the settings
16:10:45 <vkramskikh> I think no
16:11:09 <vkramskikh> mihgen: backward compatibility with what?
16:11:22 <warpc> hi
16:11:30 <mihgen> you said it wil affect plugins, puppet modules, etc.
16:11:47 <vkramskikh> plugins? they need to be changed then if they use restrictions, but this change is only needed for 8.0 plugins
16:11:52 <mihgen> if structure of data is going to change, then we'd need to ensure that old envs managed by Fuel can continue to work
16:12:12 <vkramskikh> for 7.0 envs settings structure would be the same, and the old plugins will continue to work
16:12:24 <mihgen> ok then
16:12:32 <vkramskikh> they will work - settings structure and manifests for 7.0 env will be the same as before
16:12:44 <mihgen> I believe xarses wanted to know if someone can help to get separate provis/deploy done
16:12:52 <vkramskikh> ah
16:13:12 <vkramskikh> I think we'd better focus on quality of other features and bugs instead
16:13:32 <vkramskikh> and plan everything properly for the next release
16:13:48 <mihgen> xarses: so it's too late..  and I bet we of need python engineers
16:13:59 <vkramskikh> yep
16:14:23 <xarses> thanks
16:14:36 <xarses> #topic external snapshots in fuel-devops https://etherpad.openstack.org/p/system-test-external-snapshots (akaszuba)
16:15:11 <akaszuba> hi all, i want to ask you for help with review
16:15:25 <akaszuba> more details you can find in link https://etherpad.openstack.org/p/system-test-external-snapshots
16:15:55 <angdraug> wow, nice writeup :)
16:16:11 <akaszuba> thx :)
16:16:18 <angdraug> QA folks, this one is for you
16:16:28 <xarses> akaszuba: what's blocking you? lack of reviewers?
16:16:43 <bookwar> this feature enables much better management of test environments, so devs who test things locally could benefit from it as well
16:16:55 <Tatyanka_Leontov> angdraug: will take care
16:16:58 <angdraug> thanks!
16:17:32 <angdraug> akaszuba: anything else? ready to move on?
16:17:37 <akaszuba> xarses: at this moment i got +1 but no +2, and i need also add some additional test
16:18:02 <akaszuba> angdraug: i this it is enough
16:18:10 <akaszuba> i just want to ask for help with review
16:18:23 <akaszuba> and sugestions/questions
16:18:24 <mihgen> can you share review request.. ?
16:18:40 <xarses> mihgen: its on the bottom of the etherpad
16:18:41 <bookwar> mihgen: it is in the etherpad link
16:18:43 <angdraug> mihgen: linked from the etherpad
16:18:44 <akaszuba> https://review.openstack.org/#/c/235566/
16:18:50 <xarses> #link https://etherpad.openstack.org/p/system-test-external-snapshots
16:19:04 <mihgen> I see, thanks
16:19:13 <xarses> #topic Bugfix status (akislitsky) https://etherpad.openstack.org/p/fuel-bugs-status
16:19:20 <akislitsky_> hi all, detailed bugs-status report located at https://etherpad.openstack.org/p/fuel-bugs-status
16:20:48 <xarses> akislitsky_: do any of these stats indicate any trends to you?
16:20:52 <mihgen> akislitsky_: we don't seem to show more outgoing than incoming. Is there a way to change it?
16:22:03 <akislitsky_> the most of remaining bugs are tricky and takes a lot of time. we can increase number of fixed bugs by closed medium and low
16:22:05 <mihgen> 17 income for python high piroirty is a lot and higher than before (around 10)..
16:22:41 <mihgen> number of medium bugs goes down actually, so I'm not in a worry here
16:22:45 <alex_didenko> just a note: we clearly have more python bugs than library/UI
16:22:59 <mihgen> I'm in a worry that by HCF we will still have around 40 high priority bugs
16:24:01 <akislitsky_> I think we would not be able to close all high bugs by the HCF
16:24:02 <mihgen> let's think offline where bugs are coming from, and how we can turn the trend
16:24:54 <mihgen> we'd need to justify then why so for every bug... require major rewrites or something else
16:24:56 <kozhukalov_> mihgen, QA on vacation
16:24:59 <xarses> mihgen: who's action is that then?
16:25:24 <mihgen> akislitsky_ or dpyzhov
16:25:53 <mihgen> we can't just wait before HCF date happens and we still have 40 bugs
16:26:06 <mihgen> 63 actually
16:26:14 <xarses> #action akislitsky_ will follow up on possible reasons for the high python bug trend
16:26:29 <akislitsky_> shure. let's find out the way to solve the situation
16:26:34 <xarses> moving?
16:27:08 <xarses> #topic Multirack status (alex_didenko)
16:27:22 <alex_didenko> ok
16:27:25 <alex_didenko> Right now we're working on the ability to share L2/L3 settings between different networks.
16:27:26 <alex_didenko> Like the possiblity to use the same VLAN id and/or the same CIDR/gateway for different networks.
16:27:26 <alex_didenko> We will start working on routing reconfiguration on addition of new node groups soon.
16:27:26 <alex_didenko> Besides that we're working on system tests, for example: deploy multi-rack env with controllers in non-default node group.
16:27:59 <alex_didenko> I guess that's it.
16:28:35 <xarses> alex_didenko: are there any issues with these landing before FF?
16:28:50 <alex_didenko> not with these, but with few others
16:29:18 <alex_didenko> the possibility to use non-public network as default gateway
16:29:47 <alex_didenko> and automatic update of dhcp ranges if we assign VIP from admin network
16:30:11 <alex_didenko> but the last one is 'nice to have' since you can work-around it by updating admin network range manually
16:31:01 <mihgen> is there a workaround for the non-public gw?
16:31:29 <xarses> mihgen: yes, you can hack the hiera data in globals
16:31:31 <alex_didenko> yes, but it's more complex, you need to update network_shema
16:31:47 <xarses> and its very ugly
16:32:13 <xarses> thanks
16:32:19 <alex_didenko> true, providing the ability to chose network in UI would be much better
16:32:26 <mihgen> we don't have much time left folks, and seeing number of bugs I'm more for hardening what's landed
16:32:40 <mihgen> as opposed to rush with gaps which could be work-arounded
16:32:46 <angdraug> mihgen: +1
16:33:02 <xarses> yep, +1
16:33:19 <angdraug> looks like consensus, lets move on
16:33:26 <xarses> #topic [openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node (kozhukalov)
16:33:38 <mihgen> akasatkin: don't miss that one about hardening ^^^ ;)
16:33:53 <kozhukalov_> it is just an announcement of the ML
16:34:17 <xarses> link?
16:34:21 <kozhukalov_> if you guys have any comments please read this ML and give your opinion
16:34:34 <kozhukalov_> it is not archived yet
16:34:40 <angdraug> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/079866.html
16:35:06 <maximov> short question - does it cover all implications ? f.e. will rollback feature work after it?
16:35:16 <maximov> kozhukalov_: ^
16:35:34 <xarses> also, how do we un-container a master node?
16:35:35 <angdraug> kozhukalov_ lost his network connection
16:35:47 <xarses> when it's upgraded
16:35:55 <akasatkin> mihgen: ok
16:36:00 <angdraug> in short, we'll have centos7 in fuel 8.0 on the fuel node
16:36:08 <mihgen> this one goes with a few more things together. get rid of upgrade tarball is one, and both rely on master node upgrade to centos7
16:36:28 <angdraug> this means that 7.0->8.0 upgrade has to involve OS reinstall anyway
16:36:29 <mihgen> we need to have a very good plan how to get all done by FF and not to break master
16:36:59 <xarses> I don't see how this will work this close to FF
16:37:06 <angdraug> afaik ogelbukh is working on a backup/restore based upgrade path for 8.0
16:37:11 <mihgen> and we need a plan to what to do if this doesn't go well
16:37:25 <angdraug> if it doesn't go well we don't merge it
16:37:52 <mihgen> backup/restore in theory can wait
16:37:55 <angdraug> folks, you realize you'll have to repeat all your questions after kozhukalov_ gets back online?
16:38:18 <angdraug> I don't have all the answers :)
16:38:20 <mihgen> angdraug: no, he will just read logs afterwards and reply in ML ;)
16:38:46 <mattymo> don't forget this interacts strongly with the work being done by isuzdal and dteselkin
16:38:53 <xarses> to the ML!
16:39:01 <mattymo> they should be aware because they're still preparing 8.0 with docker and containers
16:39:03 <angdraug> xarses: +1
16:39:11 <angdraug> mattymo: they're aware since yesterday
16:39:34 <xarses> moving on then it had the intended effect
16:39:34 <mihgen> time ?
16:39:39 <xarses> #topic Deprecation of GRE network segmentation type in 8.0 (aroma)
16:40:00 <xarses> aroma:
16:40:07 <aroma> I've recently stumbled upon this bug  https://bugs.launchpad.net/fuel/7.0.x/+bug/1478924
16:40:07 <openstack> Launchpad bug 7 in Launchpad itself "Need help for novice translators" [High,Fix released] - Assigned to Данило Шеган (danilo)
16:40:22 <aroma> Tried to find some additional info; there are several internal mailing threads dedicated to the topic but with no particular conclusion
16:40:36 <aroma> so I decided to rise the question here
16:40:52 <aroma> AFAIK it is already done on Library side (though don't know particular details) and on UI, but Nailgun API left unchanged and such environment may be created using CLI
16:41:00 <xarses> bug 1478924
16:41:00 <openstack> bug 1478924 in Fuel for OpenStack "Nailgun API should validate Neutron segmentation type" [Medium,Incomplete] https://launchpad.net/bugs/1478924 - Assigned to Fuel Python Team (fuel-python)
16:41:15 <aroma> I understand there might be concerns about compatibility with old clusters but at least could we forbid creation of new ones with the option?
16:41:52 <ikalnitsky> alex_didenko: could you confirm that library doesn't support gre?
16:42:10 <ikalnitsky> if that's true, we have to forbid create new clusters using gre
16:42:10 <xarses> I'm not sure why we are removing support in the DB
16:42:24 <xarses> we should just remove the option in the UI
16:42:30 <mihgen> and another questions - do operators prefer GRE over vxlan in some cases?
16:42:32 <alex_didenko> ikalnitsky: no I can't, it should support gre still
16:42:35 <ikalnitsky> xarses: UI and APU are different things
16:42:36 <xarses> if someone wants to do it, we neet do not block it
16:42:44 <xarses> ikalnitsky: exactly
16:43:10 <xarses> unless its impossible to use the setting anymore
16:43:10 <mihgen> it could be just in experimental feature group
16:43:19 <xenolog> I propose move GRE to experimental and do not test such cases
16:43:20 <angdraug> mihgen: if your network kit doesn't support vxlan you wouldn't have much choice
16:43:23 <xarses> it shouldn't be blocked
16:43:28 <ogelbukh> because someone can use it via cli and fail?
16:43:45 <mwhahaha> i thought when we switched over to vxlan we were still going to support gre but only via the cli/api
16:44:02 <mwhahaha> i'm not aware of the removal of gre and i would argue that we shouldn't remove a feature like that
16:44:13 <ogelbukh> +1 I don't recall such decision
16:44:52 <mwhahaha> people have asked for how to use gre, we didn't document the switch very well
16:45:03 <ogelbukh> not to mention the upgrade path
16:45:18 <xarses> how have we broken gre support already?
16:45:40 <xarses> also, its supposed to work for upgrades
16:45:51 <xarses> and random people that are attached to GRE
16:46:29 <mihgen> again - if there are a number of people asking for it, we should consider doing it under experimental feature group at least
16:46:46 <mihgen> even if we don't have capacity to verify that it will work with all other features
16:46:51 <angdraug> aroma: ^ ?
16:46:51 <xarses> why experimental?
16:46:53 <mwhahaha> considering it was a main feature for several releases i'm not sure it should be experimental
16:46:58 <xarses> just remove it from the UI
16:47:00 <angdraug> mwhahaha: +1
16:47:01 <mihgen> such as upgrades. It just has to be clearly articulated
16:47:07 <xarses> mwagner: +1
16:47:11 <xarses> oops
16:47:14 <xarses> mwhahaha: +1
16:47:39 <xenolog> GRE already not selectable by UI
16:47:46 <mwhahaha> my vote would be don't deprecate, fix it and document it. cli only
16:47:56 <xarses> mwhahaha: +1
16:48:03 <xenolog> yep, GRE already CLI-only
16:48:26 <mwhahaha> and keep at least 1 basic test for it
16:48:29 <mihgen> and to make sure that I understand a reason - because there are a number of people who need it, and can't use vxlan for different reasons?
16:49:20 <mwhahaha> my reasoning would be we supported it for multiple releases and I have seen multiple people have asked how to use gre instead of vxlan
16:49:57 <mwhahaha> whatever their reasons, it doesn't matter. customers are asking for it and we had it (and choose to switch the default), so we should keep the option
16:50:03 <xarses> mihgen: +1 upgrades
16:50:23 <mihgen> sounds fair.
16:50:47 <xarses> we need to move on
16:50:58 <xarses> aroma: We should discuss this further on the ML
16:51:01 <mihgen> ogelbukh: we'd need to find a way to upgrade it. if not possible now - we need to document it
16:51:09 <mihgen> and show warning when user chooses gre
16:51:32 <mihgen> aroma: thanks for bringing this up here.
16:51:34 <ogelbukh> mihgen: agree
16:51:41 <xarses> #topic Mixed team status (zynzel)
16:51:47 <zynzel> We are currently working on bugfixing/review and PROD-2012 (allow to change configuration after deployment - https://review.openstack.org/#/c/239897/21/specs/8.0/openstack-config-change.rst). PROD-2012 items:
16:51:51 <zynzel> * Spec merged
16:51:53 <zynzel> * Keystone part merged
16:51:56 <zynzel> * Nova and neutron part in review
16:51:59 <zynzel> * API and CLI under heavy development.
16:52:10 <aglarendil> cool!
16:52:16 <xarses> #action aroma to raise removing / blocking clusters with neutron GRE type in ML
16:52:36 <mihgen> I assume it's https://blueprints.launchpad.net/fuel/+spec/openstack-config-change
16:52:43 <zynzel> yep, correct
16:52:55 <xarses> zynzel: no one knows what PROD-2012 is, please use the BP link
16:53:20 <mihgen> zynzel: when do you folks plan to land remaining pieces.. ?
16:53:21 <zynzel> sure, sorry. This is BP pasted by mihgen
16:53:37 <zynzel> hard to tell, nova and neutron is ready
16:53:41 <zynzel> API mostly too
16:53:44 <mihgen> do you have everything on review already or you expect a few more patches?
16:53:57 <zynzel> dev guys are working on serializer for synchronizing hiera
16:54:29 <zynzel> review was pushed today, so probably we will end with 1 or 2 patchsets
16:54:32 <mihgen> do you sync with someone from core reviewers on periodical basis?
16:54:58 <zynzel> we are talking with vova kuklin+sergii golovatiuk
16:55:13 <zynzel> i know that python guys are in sync with some core reviewers
16:55:36 <akasatkin> Im in sync with Alex Saprykin
16:55:49 <mihgen> thanks guys, cool
16:55:59 <xarses> #topic progress on auto-adding reviewers based on MAINTAINERS file: https://bugs.launchpad.net/fuel/+bug/1497655 (mihgen)
16:56:01 <openstack> Launchpad bug 1497655 in Fuel for OpenStack "Add reviewers automatically based on MAINTAINERS data" [High,Confirmed] - Assigned to Alexander Charykov (acharykov)
16:56:12 <mihgen> just wanted to hear an update here
16:56:25 <mihgen> I thought script is ready, are we stuck with running it?
16:56:49 <monester> mihgen: no update for this week, script is ready need to decide how it should work
16:57:12 <mihgen> what do you mean by that?
16:57:40 <mihgen> let's take it offline, we need to solve it
16:57:42 <monester> I need to contact infra and ask about possibility to run it as a git trigger
16:58:13 <angdraug> monester: I thought you already asked?
16:58:31 <monester> angdraug: not yet
16:59:08 <mihgen> 1min..
16:59:20 <mihgen> let's take this offline. there is one more topic..
16:59:28 <monester> mihgen: ok
16:59:31 <xarses> #topic fixing custom iso builds for stable/7.0 https://bugs.launchpad.net/fuel/+bug/1509313 (angdraug)
16:59:32 <openstack> Launchpad bug 1509313 in Fuel for OpenStack 7.0.x " [fuel-ci] custom_iso for 7.0 builds with incorrect symlink to puppet modules" [High,Confirmed] - Assigned to Matthew Mosesohn (raytrac3r)
16:59:57 <angdraug> the stable/7.0 review for above bug is blocked by maintenance team
17:00:17 <angdraug> I'd like confirm whether custom iso for stable branches is something we want to keep
17:00:37 <angdraug> please comment on the bug if you have an opinion
17:00:43 <tmcpeak> o/
17:00:44 <mihgen> I've heard that people need it
17:00:45 <angdraug> time
17:00:46 <hyakuhei> *ahem*
17:00:48 <xarses> time
17:01:02 <tkelsey> o/
17:01:02 <xarses> #endmeeting