16:01:12 <kozhukalov> #startmeeting Fuel
16:01:12 <openstack> Meeting started Thu Aug 20 16:01:12 2015 UTC and is due to finish in 60 minutes.  The chair is kozhukalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:16 <openstack> The meeting name has been set to 'fuel'
16:01:20 <mihgen> hi
16:01:22 <kozhukalov> #chair kozhukalov
16:01:23 <openstack> Current chairs: kozhukalov
16:01:27 <kozhukalov> hi all
16:01:27 <ashtokol_> hi
16:01:27 <angdraug> o/
16:01:28 <mwhahaha> o/
16:01:29 <agordeev> hi
16:01:31 <monester> hi
16:01:37 <sgolovatiuk> o/
16:01:42 <ikalnitsky> o/
16:01:48 <kozhukalov> #topic code review process in Fuel (mihgen)
16:01:53 <sbog> hi
16:02:05 <bogdando> o/
16:02:05 <mihgen> hi folks, I've writtent quite long email
16:02:07 <mihgen> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html
16:02:25 <mihgen> sorry for it being so long) just wanted to raise it here if you have any immediate questions
16:02:29 <amaksimov> hi
16:02:32 <evgenyl> hi
16:02:33 <mihgen> and bring it to your attention
16:02:42 <mihgen> also, there is a short version of this email in slides:
16:02:52 <mihgen> #link https://docs.google.com/presentation/d/1HMSovUxujOUwILPSjiuZHqAxo1TujQazA2yGHSsQC6U
16:02:54 <akislitsky> hi
16:03:15 <mihgen> I'd ecorurage everyone to block some time and spend 30min on it
16:03:28 <bogdando> Yes, I spent two hours y-day reading related links and that was quite interesting :)
16:03:53 <mihgen> :) good to know you've found it interesting
16:04:07 <mihgen> guys - I'll be waiting your feedback in the thread..
16:04:10 <kozhukalov> seem it is gonna take up to 4 hours of my time )
16:04:19 <bogdando> I think only peer-to-peer review mesh could work for community well
16:04:51 <bogdando> but yes, we better move discussion there, to the ML thread
16:05:05 <mihgen> bogdando: hmm ok - then we'd need to debate. yes, ML please then
16:05:19 <mihgen> kozhukalov: that's it, move on?
16:05:36 <kozhukalov> ok, i think we can move on, because it is not likely that anyone else except bogdando have managed to read it so far
16:05:51 <kozhukalov> #topic network-related bugs & patch for Ironic (akasatkin)
16:05:51 <mihgen> agenda link:
16:05:53 <mihgen> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:06:05 <akasatkin> hi
16:06:24 <akasatkin> we have 9 bugs on networking left:
16:06:45 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1484928 (on review) !
16:06:45 <openstack> Launchpad bug 1484928 in Fuel for OpenStack "Network templates for custom Node Groups don't work: group ID is used instead of name during template applying" [High,In progress] - Assigned to Artem Panchenko (apanchenko-8)
16:06:46 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1486543 (Roman Prykhodchenko) !
16:06:46 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1487021 (Aleksey Kasatkin) !
16:06:46 <openstack> Launchpad bug 1486543 in Fuel for OpenStack "[nailgun] Need to add VIPs in new format into API output" [High,Confirmed] - Assigned to Roman Prykhodchenko (romcheg)
16:06:47 <openstack> Launchpad bug 1487021 in Fuel for OpenStack "[VIPs] VIP allocation is restricted to controller node group now" [High,Confirmed] - Assigned to Aleksey Kasatkin (alekseyk-ru)
16:06:54 <akasatkin> these 3 are more important
16:07:10 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1484476 (on review)
16:07:10 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1484929 (on review)
16:07:11 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1487007 (Kseniya Tychkova)
16:07:11 <openstack> Launchpad bug 1484476 in Fuel for OpenStack "No cleanup for network groups when managed via new API" [High,In progress] - Assigned to Artem Roma (aroma-x)
16:07:13 <openstack> Launchpad bug 1484929 in Fuel for OpenStack "Weak validation for network group update and delete" [High,In progress] - Assigned to Elena Kosareva (ekosareva)
16:07:14 <openstack> Launchpad bug 1487007 in Fuel for OpenStack "[VIPs] VIP name and namespace should be normalized" [High,Confirmed] - Assigned to Kseniya Tychkova (ktychkova)
16:07:18 <akasatkin> these 3 are also important
16:07:41 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1482399 (Łukasz Oleś) feature
16:07:41 <openstack> Launchpad bug 1482399 in Fuel for OpenStack "Cannot change vip and vrouter_vip IPs when we are using nodegroups" [High,Confirmed] - Assigned to Łukasz Oleś (loles)
16:07:42 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1483307 (on review - Ironic)
16:07:42 <akasatkin> https://bugs.launchpad.net/fuel/+bug/1484008 (on review) like to be lower
16:07:42 <openstack> Launchpad bug 1483307 in Fuel for OpenStack "Non-default networks are not serialized when template is not loaded" [High,In progress] - Assigned to Andrey Shestakov (ashestakov)
16:07:44 <openstack> Launchpad bug 1484008 in Fuel for OpenStack "Address space intersection error after creating a node group" [High,In progress] - Assigned to Przemyslaw Kaminski (pkaminski)
16:07:51 <akasatkin> last 3 are under question
16:08:14 <akasatkin> 5 of them are with fixes on review already
16:08:23 <ashestakov> bug/1483307 - i think it is not only for ironic
16:08:40 <mihgen> #link https://review.openstack.org/#/c/211349/
16:08:52 <mihgen> ashestakov: this doesn't really look like a bug, ashestakov ^^
16:09:06 <mihgen> can't we achieve the same goal by using templated networking ?
16:09:06 <akasatkin> Custom networks is a thing that is supported with templates now.
16:09:06 <akasatkin> Without template being loaded, only default set of networks is serialized by Nailgun:
16:09:06 <akasatkin> 1) If some networks were added they will not be serialized.
16:09:06 <akasatkin> 2) If some networks were removed Nailgun will not serialize data properly.
16:09:06 <akasatkin> This patch deals with the first problem.
16:09:47 <ashestakov> mihgen: why? if i have possibility to create custom network group, why it not working as expected? (transformations are absent)
16:10:45 <mihgen> my opinion is that it is too disruptive change such late in the cycle, leading to increasing of a tech debt; while there is another solution can be used (templated networking) for the same purpose..
16:10:55 <akasatkin> yes , from one side it looks not consistent, from other side we support it with templates
16:10:55 <akasatkin> Both problems must be resolved in 8.0 where we want to have API and UI support for network roles and networks manipulation.
16:11:53 <mihgen> it's rather a gap in functionality, not a bug
16:12:18 <mihgen> ikalnitsky: evgenyl:  opinions on this patch? ^^
16:13:11 <ikalnitsky> mihgen, i'm sorry, i didn't look close
16:13:13 <ashestakov> why need functionality to create custom network groups?
16:13:14 <akasatkin> ...change was tested for regression with sys.tests on CI.
16:13:23 <mihgen> regarding the other two, both of them are about node groups.
16:13:25 <ikalnitsky> but it looks like most of the lines are tests, and it's not so complex
16:14:44 <mihgen> I'd consider those to move to next milestone as well
16:15:11 <mihgen> ashestakov: looks like it doesn't work then :(
16:15:12 <kozhukalov> should we make a decision right now?
16:15:32 <mihgen> but changing so many LOC late in the cycle -doesn't sounds as a good idea
16:15:36 <akasatkin> mihgen: https://bugs.launchpad.net/fuel/+bug/1482399 looks more like a feature for me and https://bugs.launchpad.net/fuel/+bug/1484008 seems to be lower priority
16:15:36 <openstack> Launchpad bug 1482399 in Fuel for OpenStack "Cannot change vip and vrouter_vip IPs when we are using nodegroups" [High,Confirmed] - Assigned to Łukasz Oleś (loles)
16:15:37 <openstack> Launchpad bug 1484008 in Fuel for OpenStack "Address space intersection error after creating a node group" [High,In progress] - Assigned to Przemyslaw Kaminski (pkaminski)
16:15:40 <kozhukalov> or maybe to move this discussion in CR
16:16:11 <mihgen> akasatkin: that's what I said about them - both node-groups related and should be pushed to next release in my opinion, too late too
16:16:28 <mihgen> we need to make hard decisions in order to converge by 3 Sep
16:16:28 <ashestakov> mihgen: there are not a lot of LOC, just one function has been de-intherited + tests
16:16:49 <mihgen> ashestakov: which means code duplication of so many lines..
16:17:47 <kozhukalov> guys, let's move on, not the best place for discussing quality of code
16:17:58 <mihgen> ikalnitsky: evgenyl please take a look at those patches
16:18:23 <mihgen> we would need to get a collaborative decision by cores on what we are getting in and what to push out
16:18:33 <ikalnitsky> i've added ironic patch to my review queue, will do it tomorrow morning
16:18:39 <mihgen> bearing in mind HCF & quality
16:18:40 <evgenyl> ok
16:18:51 <akasatkin> yes
16:18:54 <kozhukalov> #topic testing results for Keystone wsgi MPM worker layouts vs memcached dead_retry/haproxy rise vs deprecated eventlet (bogdando)
16:19:05 <ashestakov> but please, it is not ironic patch
16:19:20 <bogdando> We ran few keystone testing sessions with rally, results are here https://goo.gl/Hi25QG (no pretty view, sorry, only raw data and links to htmls).
16:19:21 <bogdando> The meeting minutes after the test sessions was logged here https://goo.gl/Hi25QG. Some missing test results data for the scale lab test cases arrived today.
16:19:21 <bogdando> I fixed https://review.openstack.org/#/c/212439 by test results.
16:19:21 <bogdando> The patch https://review.openstack.org/#/c/209589/ recieved -2 unless we got SME's (Boris Bobrov) recommendations for MPM layout (processes x threads):
16:19:24 <bogdando> "My feeling is that 6 processes 2 threads will work as good as 12 processes 2 threads when all nodes are up. But 6 processes 2 threads will definitely work better than 12 processes 2 threads when one node is down"
16:19:28 <bogdando> So Boris will analyze new data and provide feedback to the blocked patch.
16:19:30 <mihgen> ashestakov: I don't know why we call it "ironic" patch ))
16:19:54 <bogdando> nothing more to add
16:19:55 <ikalnitsky> :)
16:20:24 <bogdando> meeting minutes fixed link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:20:48 <sgolovatiuk> we should also make changes to haproxy to set rise 15 with 2 seconds interval or rise 30 with 2 seconfs interval
16:21:03 <kozhukalov> #link  https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:21:07 <bogdando> I udated the patch, sgolovatiuk
16:21:12 <sgolovatiuk> k
16:21:26 <angdraug> can someone sum up known issues with keystone wsgi?
16:21:27 <sgolovatiuk> generally, the results show good performance
16:21:32 <angdraug> is it just haproxy configuration?
16:21:36 <sgolovatiuk> all mysql related issues are fix
16:21:52 <sgolovatiuk> yes, it's just haproxy config
16:22:07 <bogdando> I know only issues related to the haproxy rise and keystone dead_retry conf
16:22:09 <sgolovatiuk> and all sporadic BVT failures are fixed also
16:22:20 <sgolovatiuk> that's it
16:22:25 <angdraug> did anyone collect all related bugs in one document?
16:22:33 <sgolovatiuk> no need to revert it back to eventlet
16:22:59 <angdraug> "here is everything we know about this topic" and "haproxy is the only issue I'm personally aware of" is not the same :)
16:23:04 <sgolovatiuk> angdraug: I think no
16:23:45 <angdraug> any volunteers to put together such summary?
16:23:49 <angdraug> or objections?
16:24:02 <alex_didenko> https://bugs.launchpad.net/fuel/+bug/1480153 - the only open bug for keystone/wsgi
16:24:02 <openstack> Launchpad bug 1480153 in Fuel for OpenStack "haproxy for keystone-admin takes a 240-300s" [Critical,In progress] - Assigned to Bogdan Dobrelya (bogdando)
16:24:07 <kozhukalov> does anyone want to have action to collect everything in one place?
16:24:24 <mihgen> yeah guys it would be extemely helpful to get it in openstack-dev email
16:24:51 <kozhukalov> bogdando, can you?
16:24:54 <bogdando> ok
16:25:19 <angdraug> a list of all recent bugs related to the topic, open or closed, would be a good start
16:25:25 <bogdando> I will send openstack-dev ML
16:25:30 <angdraug> thanks!
16:25:30 <mihgen> summary of everything related to the topic
16:25:30 <kozhukalov> #action bogdando writes ML thread to collect everything about keystone wsgi
16:25:43 <kozhukalov> moving on?
16:25:55 <mihgen> thanks bogdando
16:26:06 <kozhukalov> #topic life-cycle-management tag for bugs triage process (bogdando)
16:26:25 <bogdando> While was looking through bugs list, I marked some of them with life-cycle-management
16:26:39 <bogdando> This is a major feature Fuel missing atm
16:26:48 <mihgen> bogdando: yep
16:26:54 <bogdando> so we should be able to filter related bugs quickly
16:26:58 <mihgen> I think this is a good tag to have
16:27:05 <angdraug> +1
16:27:08 <evgenyl> What this tag can help with?
16:27:13 <bogdando> so please, then you think a bug is related to this topic, please use this tag
16:27:21 <evgenyl> Will such bugs have higher priority?
16:27:24 <bogdando> evgenyl, to filter
16:27:25 <angdraug> evgenyl: requirements management for life cycle management related features
16:28:08 <bogdando> once we have a blueprint in progress, we could collect them all and link there
16:28:12 <mihgen> I'd support additing it to official bugs list
16:28:13 * mihgen why I'm being disconnected all the time today..
16:28:18 <kozhukalov> what are the life cycle management features? example?
16:28:54 <bogdando> https://bugs.launchpad.net/fuel/+bugs?field.tag=life-cycle-management
16:29:07 <mihgen> kozhukalov: replace controller node
16:29:08 <mihgen> scale up, scale down
16:29:09 <mihgen> reconfigure glance backend
16:29:39 <bogdando> This one https://bugs.launchpad.net/fuel/+bug/1471172 is a feature, not a bug. So when we'll start to address that feature, we could address these bugs
16:29:39 <openstack> Launchpad bug 1471172 in Fuel for OpenStack "Orchestrator doesn't clean deleted node from the cloud upon node removal" [Medium,Confirmed] - Assigned to Fuel Library Team (fuel-library)
16:29:52 <angdraug> generally speaking, post-deployment operations on environments
16:30:10 <bogdando> cleanup/teardown activities as well
16:30:17 <mihgen> yep. So do we need any decision here?
16:30:21 <kozhukalov> ok, now i see, thanks for clarification
16:30:23 <mihgen> or action?
16:30:29 <bogdando> I think that was just an informational
16:30:52 <mihgen> angdraug: can we get infra team to add this to offical list of tags?
16:31:01 <angdraug> sure
16:31:02 <mihgen> it sounds like a good tag to have for me
16:31:33 <bogdando> note, patching and upgrades could fit this area also
16:31:37 <kozhukalov> action?
16:31:52 <mihgen> kozhukalov: yes please
16:32:19 <kozhukalov> #action infra team adds life-cycle-management bug tag to the official list of tags
16:32:19 <angdraug> done
16:32:28 <kozhukalov> ok, next topic is again about keystone, i think we've already discussed this
16:32:37 <angdraug> yes
16:32:51 <kozhukalov> #topic ironic-fuel-agent-driver (kozhukalov, lobur)
16:33:17 <kozhukalov> this new repo is for hosting ironic fuel agent driver
16:33:36 <kozhukalov> ironic guys do not want to have two different agents
16:34:00 <kozhukalov> so we can just have the driver out of ironic tree
16:34:04 <mihgen> what is it, ironic fuel agent driver, I can't really parse it -
16:34:10 <mihgen> driver which suppose to do what?
16:34:20 <kozhukalov> as far as i know everyone agreed with this approach
16:34:39 <kozhukalov> it is ironic deployment driver
16:34:54 <kozhukalov> which is to use fuel agent for deployment
16:35:28 <kozhukalov> for example ironic has so called IPA deployment driver as a part of its source code tree
16:35:42 <kozhukalov> IPA - ironic python agent
16:36:08 <mihgen> under deployment, do you mean roll out an image?
16:36:11 <kozhukalov> it does not support some features which fuel agent supports and some people need these features
16:36:25 <kozhukalov> mihgen, yes
16:36:53 <mihgen> so I'm just curious, we have an agent
16:36:57 <mihgen> ironic has one similar
16:36:58 <kozhukalov> it is when you install ironic, add a node, and send a request to deploy this node
16:37:04 <mihgen> this is going to be a third one?
16:37:25 <kozhukalov> IPA driver is similar but not the same
16:37:41 <kozhukalov> deployment flow and data are slightly different
16:38:18 <mihgen> I'm just wondering if we could do the work in one of the existing drivers, instead of creating new repo...
16:38:22 <kozhukalov> ironic has several deployment drivers, IPA is the default one
16:38:39 <kozhukalov> mihgen, no we can't
16:38:50 <mihgen> this will be very specific one?
16:39:08 <kozhukalov> it is just ironic model, if you need to do something specific, you need specific driver
16:39:17 <kozhukalov> drivers are pluggable
16:39:32 <angdraug> can we move on from why to what exactly this entails for Fuel?
16:39:40 <kozhukalov> any vendor can invent their own driver
16:40:22 <mihgen> ok, why then it's gonna have 'fuel' name in that repo?
16:40:23 <kozhukalov> it is not for fuel
16:40:27 <mihgen> if it's just ironic driver
16:40:36 <kozhukalov> it just uses fuel-agent
16:40:49 <kozhukalov> because fuel-agent
16:41:12 <mihgen> ok I see now.
16:41:21 <kozhukalov> ok, we can rename fuel-agent into something and then call this repo ironic-something-driver
16:41:55 <kozhukalov> moving on?
16:42:19 <kozhukalov> #topic FUTURE branch vs. early stable/X.Y (FF + 2 weeks)
16:42:43 <kozhukalov> last few days we have been discussing this topic in ml very intensively
16:43:00 <kozhukalov> i'd like to know what is our decision here
16:43:10 <kozhukalov> any opinions?
16:43:12 <mihgen> kozhukalov: in one of the private ones
16:43:23 <kozhukalov> maybe voting?
16:43:34 <mihgen> there is no decision, and for stackforge infra gerrit - we should have public one
16:44:04 <kozhukalov> mihgen, do you mean we should take one more discussion iteration in openstack-dev?
16:44:06 <mihgen> I don't think we should simply vote. we need to ensure everyone reads and understands all implications
16:44:28 <mihgen> we can provite summary email over there
16:45:12 <angdraug> yes, I think it's time to move this discussion to openstack-dv
16:45:20 <angdraug> openstack-dev
16:45:38 <kozhukalov> in my opinion, all approaches have pros and cons, future branch is not so scalable as early stable branch because it assumes having a person duty to rebase
16:45:54 <mihgen> guys but this is no less important then email about code review process
16:46:15 <kozhukalov> mihgen, sure :)
16:46:23 <mihgen> once we make a change, it will be hard to switch to something else
16:46:35 <mihgen> kozhukalov: that's my least concern about rebasing
16:46:40 <mattymo_> I feel like it's too invasive to have to do repetitive code reviews to two "current" branches
16:46:50 <mattymo_> but some people have good arguments
16:47:22 <mihgen> mattymo_: it's actually needs improvement
16:47:30 <kozhukalov> ok, let's have another iteration in openstack-dev
16:47:35 <angdraug> I'm still against opening stable early
16:47:37 <mihgen> linux stable branch is being maintened by not so many people as far as I know
16:47:45 <angdraug> it will multiply bugfixing overhead by at least 1.5
16:48:03 <kozhukalov> #action angdraug initiates ML thread about branching approach in openstack-dev
16:48:04 <mihgen> and mostly depends on one person, who makes decision whether this patch is ok for stable branch
16:48:36 <mihgen> angdraug: but slow down development of new features even more
16:48:57 <angdraug> lets take it to openstack-dev
16:49:00 <mihgen> instead of switching to the rapid development, with short iteration cycles, we would be sitting on bugs
16:49:06 <mihgen> ok
16:49:35 <kozhukalov> open discussion then?
16:49:49 <kozhukalov> #topic open discussion
16:50:22 <mihgen> alex_didenko: what's up with bugs?
16:50:36 <sbog> Mike, I hear you want to talk about bugs in SSL?
16:50:37 <mihgen> where are we good and where we are bad?
16:50:48 <mihgen> sbog: yes
16:51:05 <mihgen> I didn't see you in agenda unfortunately
16:51:10 <mihgen> but we still have some time
16:51:17 <sbog> We have one https://bugs.launchpad.net/fuel/+bug/1485995 that was raised from high to medium. Actually, it is right, I think
16:51:17 <openstack> Launchpad bug 1485995 in Fuel for OpenStack 8.0.x "Link to UI in /etc/issue should point to https" [Medium,Confirmed] - Assigned to Stanislaw Bogatkin (sbogatkin)
16:51:57 <mihgen> I think it can be considered UX bug of a high priority
16:52:05 <sbog> But it is affect user expirience also, yep
16:52:31 <mihgen> why are we so against of changing http: to https:// in welcome message?
16:52:41 <sbog> holser, adidenko what you think about it?
16:53:58 <mihgen> alex_didenko: why do we consider https://review.openstack.org/#/c/214153/2/iso/ks.template as a disruptive change? It's UX gap
16:54:47 <alex_didenko> we don't consider it as disruptive, but it's not a High bug according to our bugs triaging docs
16:55:56 <kozhukalov> are plane (non ssl) ports going to continue to serve? if so, it is not high, imo
16:56:00 <alex_didenko> personally I don't mind to merge it, my only concern was bug priority
16:56:26 <angdraug> I think this is high UX bug
16:56:28 <mihgen> I'd say it's UX high bug
16:56:29 <angdraug> #link https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Confirm_and_triage_bugs
16:56:34 <angdraug> High = Requires modification of config files, interfaces that users aren't expected to use (ie the API when it's _intended_ to work in the CLI / UI (exclusive of interfaces that are intended to only be available via API) or requires custom node yaml (again except when it should exclusively be available)
16:56:48 <kozhukalov> this patch changes only text, nothing dangerous
16:57:00 <angdraug> you need to know the port number and change it manually to get to https interface
16:57:17 <mihgen> angdraug: +1
16:57:17 <alex_didenko> maybe it's better to setup a redirect then?
16:57:26 <sbog> alex, we can't
16:57:39 <mihgen> alex_didenko: nope, redirect would be an invasive change
16:57:43 <angdraug> redirect would be disruptive
16:57:49 <mihgen> and we need backward compatibility
16:57:50 <mihgen> for one release
16:57:57 <sbog> it will break master node upgrade
16:58:02 <mihgen> so clients which don't expect it - can continue to work
16:58:13 <alex_didenko> ok, then pls post a comment why the bug is High, so it does not get lowered again
16:58:23 <sbog> Okay, I will do it
16:58:36 <kozhukalov> time
16:58:44 <kozhukalov> 2 minutes
16:59:27 <kozhukalov> any other questions, topics, statements, announcements?
16:59:35 <angdraug> no time )
16:59:47 <kozhukalov> thank you very much for attending, closing
16:59:55 <kozhukalov> #endmeeting