16:00:59 <xarses> #startmeeting fuel
16:01:00 <xarses> #chair xarses
16:01:00 <xarses> Todays Agenda:
16:01:00 <xarses> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:01:00 <xarses> Who's here?
16:01:01 <dpyzhov> hi
16:01:01 <openstack> Meeting started Thu Oct 15 16:00:59 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:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:03 <maximov> hi
16:01:05 <openstack> The meeting name has been set to 'fuel'
16:01:07 <openstack> Current chairs: xarses
16:01:08 <ashtokolov> hi
16:01:10 <angdraug> o/
16:01:11 <sbog_> Hi guys
16:01:14 <evgenyl> hi
16:01:17 <bgaifullin> hi
16:01:19 <aglarendil> hi
16:01:21 <yottatsa> hi!
16:01:23 <xenolog13> \~/
16:01:26 <prmtl> hey
16:01:32 <warpc> hi
16:01:33 <vkramskikh> hi
16:01:34 <mihgen> hi
16:01:37 <mwhahaha> hi
16:01:45 <xarses> #topic Action Items from last meeting
16:01:55 <akasatkin> hi
16:01:58 <xarses> kozhukalov will update ML with plan to separate each sub-project in fuel-web (notes on this https://etherpad.openstack.org/p/fuel-move-repos)
16:02:25 <rmoe> hi
16:02:59 <xarses> kozhukalov: added notes regarding this on the etherpad above
16:03:02 <xarses> angdraug will update fuel-specs reviews to assign SME's to review https://etherpad.openstack.org/p/fuel-blueprints-8.0
16:03:29 <angdraug> I've reviewed and categorized stuck specs:
16:03:29 <angdraug> #link https://etherpad.openstack.org/p/fuel-blueprints-8.0
16:03:29 <angdraug> didn't have time to prod reviewers and committers yet
16:03:29 <angdraug> please check the etherpad and let me know if you disagree with the categorization
16:03:47 <xarses> angdraug: so another action for next week?
16:03:53 <angdraug> yes please
16:03:56 <xarses> k
16:04:00 <xarses> maximov will look over stale review queue and ensure that cores are assigned to them
16:04:15 <maximov> ok, yes I checked all our review queues and followed up all relevant people,
16:04:18 <kozhukalov_> still did not write ML thread, will send probably tomorrow, when the majority of patches will be on review
16:04:21 <mattymo> hi
16:04:30 <akislitsky> hi
16:04:33 <maximov> in result we have healthy status for all product related review queues: 0 stalled reviews.
16:04:44 <maximov> the only problem is in qa repositories:
16:04:53 <maximov> fuel-devops has 1 stalled review but core reviewers assigned to it,
16:05:04 <mihgen> #link  http://bit.ly/1G4Xsn9
16:05:04 <maximov> fuel-ostf has 2 stalled reviews
16:05:07 <mihgen> thanks maximov
16:05:47 <maximov> fuel-specs has 9 stalled reviews, but I ensured that in every review we have at least 1 core reviewer.
16:05:57 <maximov> so I consider my action item as done
16:06:03 <dpyzhov> maximov: how many days it takes for review to became stalled?
16:06:11 <maximov> 5 days
16:06:14 <dpyzhov> thanks
16:06:27 <mihgen> we need to monitor on weekly basis until we implement automation to escalate..
16:06:46 <mihgen> xarses: moving on?
16:06:46 <xarses> #action angdraug will update fuel-specs reviews to assign SME's to review https://etherpad.openstack.org/p/fuel-blueprints-8.0
16:06:59 <xarses> #topic Enhancements Team Status (ashtokolov)
16:07:13 <ashtokolov> hi folks
16:07:18 <ashtokolov> Enhancements status briefly:
16:07:28 <ashtokolov> Inbox - 66(was 62), In progress - 15(was 12), On review - 19(was 20), QA - 17(was 17), Done - 6(was 2)
16:07:36 <ashtokolov> and 8(was 12) to be sorted with Product Management
16:07:41 <ashtokolov> Total: 131 (was 125)
16:08:00 <ashtokolov> Any questions?
16:08:12 <dpyzhov> yep
16:08:22 <dpyzhov> we have 6 bugs that has need-bp tag
16:08:36 <dpyzhov> we need to address them somehow
16:08:54 <dpyzhov> As I see we don't have an owner for this activity
16:09:02 <angdraug> Product Management?
16:09:36 <dpyzhov> somebody should create blueprints and prioritise them
16:09:43 <mihgen> dpyzhov: may be ashtokolov should take it with dnovakovsky.. ?
16:09:56 <ashtokolov> Let's thirst of all check our blueprints
16:10:20 <ashtokolov> I'm working on simple script
16:10:39 <ashtokolov> and also I can do a trello board with unsorted bps
16:11:18 <ashtokolov> angdraug mihgen I think it means that I will do it
16:11:30 <ogelbukh> o/
16:11:31 <angdraug> thanks, let me know if I can help
16:11:32 <dpyzhov> please don't forget about bugs with 'need-bp' tag in your activity, thats all =)
16:11:37 <mihgen> we need some preliminary analysis and scoping
16:11:53 <ashtokolov> dpyzhov it's not my activity)
16:11:57 <mihgen> not necessarily taking it in this release timeframe
16:12:06 <ashtokolov> need-bp it means big stories
16:12:16 <ashtokolov> not small enhancements
16:12:29 <angdraug> and big stories covers the rought scoping part
16:12:41 <angdraug> so all we really need is capture requirements and prioritize
16:12:48 <angdraug> so PM
16:13:16 <dpyzhov> angdraug: PM will walk through all need-bp bugs and create blueprints? ok for me
16:13:48 <angdraug> ashtokolov: can you generate raw input for PM to go through?
16:14:08 <angdraug> at the level of detail like list of bugs with titles
16:14:16 <ashtokolov> angdraug Yes I'll do
16:14:31 <ashtokolov> action for me please
16:14:57 <xarses> ok, moving on?
16:15:05 <angdraug> yes please, and action for ashtokolov
16:15:06 <ashtokolov> moving on
16:15:07 <xarses> #topic UI Team Status (vkramskikh)
16:15:11 <vkramskikh> hi!
16:15:14 <vkramskikh> Hi, this week we fixed 11 bugs, the number of remaining bugs is 42. Currently we have only one high bug, all other are mediums and lower. I think during the next week we'll be able to fix about 10-15 bugs and then we'll mostly switch to implementation of new features.
16:15:29 <xarses> #topic ashtokolov will generate raw inpunt from need-bp bugs for PM to review
16:15:32 <xarses> oops
16:15:34 <xarses> #topic UI Team Status (vkramskikh)
16:15:53 <xarses> #action ashtokolov will generate raw inpunt from need-bp bugs for PM to review
16:15:54 <vkramskikh> (so when we switch to features, there still will be 1 person responsible for bugfixing)
16:15:56 <mihgen> thanks vkramskikh, you are making our bugfix graphs )
16:16:14 <dpyzhov> vkramskikh: thanks, really great progress
16:16:35 <angdraug> vkramskikh: have you seen my comment on https://review.openstack.org/#/c/231538/ ?
16:16:45 <vkramskikh> angdraug: yep
16:17:02 <angdraug> I wonder if it will impact asilenkov's design for https://launchpad.net/bugs/1503278
16:17:02 <openstack> angdraug: Error: malone bug 1503278 not found
16:17:03 <vkramskikh> but it is for Artem, isn't it?
16:17:21 <vkramskikh> i doubt so
16:17:40 <vkramskikh> I mentioned artem's activity in Expected OSCI impact section
16:17:41 <angdraug> ok, then we just need Artem to confirm that
16:17:59 <angdraug> no such thing as OSCI anymore, I think your spec template is old :)
16:18:13 <vkramskikh> ok, will check this
16:18:37 <angdraug> hm, no. OUR spec template is old :(
16:18:45 <vkramskikh> https://github.com/stackforge/fuel-specs/blob/master/specs/template.rst#expected-osci-impact
16:18:47 <vkramskikh> yep
16:19:08 <ogelbukh> why it should have osci at all, it already has infra impact
16:19:15 <angdraug> exactly
16:19:20 <angdraug> nm, I'll fix that
16:19:30 <xarses> action angdraug ?
16:19:30 <angdraug> moving on?
16:19:33 <angdraug> sure
16:19:34 <xarses> #topic Upgrade team status (ogelbukh)
16:20:09 <xarses> #action angdraug will update spec template to remove osci impact as its duplicate of infra
16:20:54 <ogelbukh> we're in bugfix phase for fuel-octane 6.1 to 7.0 version
16:21:52 <ogelbukh> we have some 10 inprogress bugs and got about 6 new ones from telco team recently
16:22:04 <ogelbukh> 2 of them are critical
16:22:30 <angdraug> eta?
16:22:38 <ogelbukh> our plan is to finish them by the next tuesday and release stable/7.0 on thursday
16:22:57 <ogelbukh> which is effectively the last day of current iteration, afaict
16:23:16 <angdraug> Wednesday is last day, Thursday is first day of next iteration
16:23:23 <ogelbukh> OK
16:23:33 <xarses> moving ?
16:23:39 <angdraug> even more strictly speaking Tuesday is last day and Wednesday is retro
16:23:42 <angdraug> yes, lets move
16:23:46 <xarses> #topic Liberty versions schema (2015.1.0-7.0 vs liberty-8.0)
16:24:03 <ogelbukh> this is relatively small question
16:24:17 <ogelbukh> there's no coordinated version number anymore
16:24:30 <ogelbukh> so we need to decide how we number openstack version in fuel
16:24:43 <angdraug> I think liberty-8.0 is going to be confusing vs liberty-1 milestones
16:24:50 <ogelbukh> absolutely
16:24:59 <angdraug> 8.0-liberty maybe?
16:25:04 <ogelbukh> I'm 100% against using symbolic versions :)
16:25:17 <ogelbukh> I'd go with just 8.0 fwiw
16:25:24 <iberezovskiy> mos8.0-liberty?
16:25:40 <angdraug> full-blown definition should "Fuel 8.0 for OpenStack Liberty"
16:25:46 <ogelbukh> we have Liberty mentioned in UI and elsewhere
16:26:04 <xarses> 8.0 is useless
16:26:07 <xarses> liberty
16:26:09 <ogelbukh> but I'm not sure if we need it at all in fuel version itself
16:26:16 <ogelbukh> xarses: why so?
16:26:18 <xarses> and a point version
16:26:28 <ogelbukh> xarses: what about nova 12.0.0 ? ^)
16:26:32 <xarses> because it's not supposed to be tied to fuel version
16:26:34 <ogelbukh> is it useful?
16:26:41 <ogelbukh> well
16:26:55 <xarses> manifests and release data is for that openstack version
16:26:56 <angdraug> good point about 8.0
16:26:59 <ogelbukh> I'm not talking about versioning of openstack
16:27:07 <angdraug> less places with hardcoded fuel version would be nice
16:27:27 <ogelbukh> it's about version of openstack included in version of fuel
16:27:33 <xarses> eventually we will really support multiple openstack versions
16:27:34 <ogelbukh> I'd suggest to get rid of it
16:27:40 <ogelbukh> right
16:28:04 <xarses> ok, lets raise it on the ML, but I think droping it will be best
16:28:06 <angdraug> what do we use this version field for?
16:28:18 <ogelbukh> path to puppet modules
16:28:23 <ogelbukh> primarily
16:28:37 <alex_didenko> for uploading task graph into appropriate realease via CLI
16:28:38 <ogelbukh> maybe something else, not sure
16:28:43 <angdraug> that's dependent of Fuel version
16:28:57 <ogelbukh> alex_didenko: it's fuel version, not openstack
16:28:59 <angdraug> is it 1:1 mapped to fuel version?
16:29:05 <ogelbukh> puppet modules are openstack version dependent
16:29:32 <angdraug> right now any given version of fuel has exactly 1 version of puppet modules
16:29:44 <ogelbukh> it's interesting question btw, how openstack-puppet is going to version their modules
16:29:58 <angdraug> they don't support 1:many either
16:29:59 <ogelbukh> angdraug: right
16:30:09 <ogelbukh> angdraug: it could change if we support multiple versions
16:30:10 <ogelbukh> :)
16:30:28 <angdraug> last time xarses proposed to allow support for multiple openstack versions in the same release of puppet-openstack it was met with resistance
16:30:31 <ogelbukh> we could ignore it for now, of course
16:30:33 <alex_didenko> don't we already support multiple versions?
16:30:35 <xarses> but 'liberty' will be enough to know this
16:30:43 <alex_didenko> if you upgrade fuel from 5.0 to 6.1
16:30:54 <mihgen> time folks
16:30:59 <xarses> angdraug: we will have to switch modules path for another release version and use module from another version
16:31:06 <ogelbukh> alex_didenko: you won't be able to deploy 5.0 anymore
16:31:10 <angdraug> lets take it to ML, looks like not that small of a question
16:31:14 <xarses> like I said, lets move to the ML
16:31:21 <xarses> #topic OpenStack Infra gate jobs for Fuel enabled by https://review.openstack.org/228204 are failing (angdraug, ashtokolov)
16:31:53 <xarses> #action ogelbukh will raise with libery version schema and how to change that in fuel to ML
16:32:05 <ogelbukh> xarses: already done :)
16:32:12 <angdraug> most of the gate jobs created by mihgen are currently failing
16:32:33 <ashtokolov> Folks, we are working on our integration with OpenStack Infra and especially with OpenStack-CI.
16:32:39 <angdraug> not having gates on openstack-infra is the last hurdle on the way to big tent, we should prioritize it
16:33:28 <ashtokolov> And we are working on fixing issues with repos structure. Like paths to tox.ini
16:33:30 <xarses> angdraug: so what do we need to do? assign cores to get the tests passing so we can move them to voting?
16:33:33 <angdraug> one way to track this would be to treat absense or failure of a gate job in a fuel repo as a critical bug
16:33:47 <angdraug> xarses: we don't need cores for that
16:33:50 <mihgen> I called for help yesterday.. ashtokolov - do we have any assignments / additional analysis
16:34:09 <ashtokolov> Please take a look on this document https://goo.gl/Xh66NZ
16:34:18 <ashtokolov> #link https://goo.gl/Xh66NZ
16:34:31 <ashtokolov> So I have a list of questions about this integration:
16:34:42 <ashtokolov> 1. Should we turn off python34 check for all repos?
16:35:08 <angdraug> ashtokolov: 1. we can, but only where we have to
16:35:24 <mihgen> python34 is ok if it continues to be non-voting
16:35:33 <ashtokolov> I saw only 2 or 3 repos which are ready for python34
16:35:47 <angdraug> #link http://governance.openstack.org/reference/project-testing-interface.html
16:35:56 <mihgen> I think we'd need to leave python34 in non-voting
16:36:00 <angdraug> "Projects which are compatible with Python 3 must also be able to do: Unit tests for python3.4"
16:36:02 <mihgen> and gradually get our code ready for it
16:36:14 <prmtl> did anyone looked how to run nailgun and ui tests on openstack infra?
16:36:28 <mihgen> let's make sure that we understand, it is 2nd priority now
16:36:30 <mihgen> not first
16:36:30 <angdraug> so leave it on and voting for repos where it already passes, and leave non-voting where it doesn't
16:36:43 <mihgen> first one is to enable in voting python27
16:36:50 <ashtokolov> ok, I got
16:36:59 <ashtokolov> 2. Which of these repos we are going to deprecate after the migration from stackforge?
16:37:16 <angdraug> #link https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement
16:37:29 <angdraug> ^ contains a list of fuel repos that we're deprecating
16:38:12 <ashtokolov> 3. We have a long list of repos with checks but w/o gates. We can fix checks but should we activate gates for it too? Or it’s an overhead?
16:38:34 <angdraug> 3. having gates for all repos is a requirement of PTI
16:38:39 <mihgen> +1
16:38:43 <ashtokolov> ok
16:38:50 <angdraug> that being said, we should focus on most active repos first
16:38:55 <ashtokolov> 4. Looks like there is no openstack gates for ruby. We have to ways: Use our jobs on Fuel-CI or try to add ruby job to OpenStack-CI
16:39:03 <angdraug> fuel-library and fuel-web should be top priority
16:39:15 <mihgen> try to use openstack infra where possible
16:39:19 <mihgen> let's go from simpler things
16:39:26 <angdraug> puppet-openstack runs rspec tests on openstack-infra
16:39:36 <ashtokolov> afaik no ruby checks
16:39:36 <angdraug> can't we just do the same?
16:39:50 <mihgen> angdraug: why do you think that we need to do fuel-web & fuel-library as 1st priority?
16:40:01 <mihgen> I'd say we should target those which are easier at 1st
16:40:14 <mihgen> keep kozhukalov working on fuel-web though
16:40:22 <ashtokolov> About Fuel-Library. First of all the biggest part of our modules are from upstream and were checked by openstack-gates before. So I think double check is useless. But we also have a short list of our own modules. And it looks like we have to create a special jenkins job in openstack-infra to cover it. mwhahaha aglarendil holser are you here?
16:40:26 <mihgen> but have other folks doing low hanging fruits first
16:40:50 <mwhahaha> we'll need to write some puppet jobs for fuel-library to run on infra
16:41:05 <mwhahaha> we might be able to reuse our fuel-ci syntax and noop tests
16:41:11 <alex_didenko> yep, for library tests we need only bundler. And puppet-openstack already has similar jobs
16:41:23 <angdraug> if we have gates for 90% of our repos where there's only 5% of our activity, I don't think it will go well with TC
16:41:43 <aglarendil> folks
16:41:44 <aglarendil> do
16:41:44 <aglarendil> we
16:41:45 <aglarendil> need
16:41:47 <aglarendil> to
16:41:51 <kozhukalov_> mihgen, just to clarify, I'm working on splitting fuel-web, but to make Openstack CI jobs green we need to do more
16:41:59 <aglarendil> add real gates for Fuel Library right now ?
16:42:11 <aglarendil> I mean, there are no similar jobs in openstack infra
16:42:23 <aglarendil> we cannot simply pick some of them and attach to fuel library
16:42:27 <mihgen> aglarendil: where we can't now, we can't now
16:42:49 <aglarendil> mihgen: I am sorry, my English grammar is lame and I did not get that
16:42:52 <mihgen> aglarendil: so we will continue Fuel CI where openstack infra has haps
16:43:15 <angdraug> ashtokolov: http://logs.openstack.org/48/229548/3/check/gate-puppet-nova-puppet-unit-3.3-dsvm-centos7/55f4dfc/console.html.gz
16:43:17 <aglarendil> okay, but openstack infra actually has zero jobs we can reuse right now
16:43:19 <xarses> we need to move along to get through the agenda, can we take this back to the ML?
16:43:21 <mihgen> ashtokolov: we need to assign people per repos... your doc is great
16:43:36 <mihgen> aglarendil: simple rspec? noop?
16:43:46 <ashtokolov> mihgen: For python checks we have to make changes in all our repos. It’s iterative process and unfortunately a lot of monkey work. Can we ask Maintainers to check for their repos?
16:43:47 <aglarendil> noop we will need to merge
16:43:51 <aglarendil> into openstack infra
16:44:00 <aglarendil> rspec is already done by upstream modules
16:44:05 <mihgen> ashtokolov: we should
16:44:09 <angdraug> aglarendil: see the link I've just posted ^
16:44:18 <angdraug> that's an example of rspec test in puppet-nova
16:44:22 <kozhukalov_> our current fuel library gates on fuel-ci are package based, right?
16:44:22 <aglarendil> puppet unit is already run in nova
16:44:26 <mihgen> ashtokolov: please organize it and get back with estimates..
16:44:29 <angdraug> exactly what we need for our own modules in library
16:44:31 <aglarendil> why do we need to rerun it?
16:44:39 <mihgen> time, we need to move on
16:44:44 <angdraug> I agree that we don't need to re-run for modules we integrate via librarian
16:44:52 <alex_didenko> +1
16:45:08 <iberezovskiy> +1
16:45:11 <mihgen> let's not try to decide everything now.. ashtokolov please organize it, and get back with questions if there are any in email
16:45:12 <xenolog13> +1
16:45:33 <mihgen> xarses: let's move ..
16:45:35 <xarses> #topic Bugfix team status (dpyzhov)
16:45:40 <dpyzhov> wow
16:45:44 <dpyzhov> at least
16:45:48 <dpyzhov> Here is our current stats. I’ll again show it in format “total (UI / python / library)"
16:45:48 <dpyzhov> Critical and high bugs: 46 (1/23/22). Last week it was 49 (1/26/22)
16:45:48 <dpyzhov> Medium, low and wishlist bugs: 193 (47/104/42). Last week it was 252 (64/125/63)
16:45:48 <dpyzhov> Features tracked as bug reports: 136. 105 are marked with ‘feature’ tag and 31 covered by blueprints. Last week it was 134 in total.
16:45:49 <dpyzhov> Technical debt bugs: 101 (1/77/23). Last week it was 88 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 9 (0/6/3)
16:45:49 <openstack> bug 193 in Launchpad itself "Unable to get back to the bug list after editing a bug" [Medium,Fix released] https://launchpad.net/bugs/193
16:46:04 <dpyzhov> So we big progress in medium/low/wishlist bugs. I can’t tell which effort made major contribution here. I was pushing hanged bugs, I was removing incorrectly assigned bugs, guys from several teams were fighting with bugs. We’ve merged at least 20 library+python bugfixes this week, actually.
16:46:11 <xarses> #action ashtokolov angdraug will update ML about status and direction of openstack infra gate jobs
16:46:21 <dpyzhov> Let me speak little bit more about Critical/High bugs. Numbers are pretty the same. There are 0 critical bugs. There are 5 incompete bugs. There are 20 bugs in progress and 4 assigned bugs. I’m not ready to share information about bugs income this week right now. Our Launchpad reporter tells about 15 high priority bugs fixed in last 7 days. But I’m not
16:46:21 <dpyzhov> sure it the number is correct. It shows 19 bugs created during the same period. Something is definitely wrong here. But for me it looks like we have huge income of new high priority bugs and it is not going to go any lower. I’ll try to analyse our bugs income and share results.
16:46:40 <dpyzhov> I'm typing damn fast
16:47:51 <xarses> =)
16:47:55 <xarses> thanks
16:47:57 <mihgen> dpyzhov: thank you. Looks like we are doing a great job in squashing medium
16:48:07 <dpyzhov> yep
16:48:08 <mihgen> for high, we need to investigate a source of them, I agree
16:48:21 <mihgen> thank you for driving this and detailed reports
16:48:25 <dpyzhov> I hope that our new taxonomy help us to have better control over bugs
16:48:25 <enikanorov_> may i bring a bug to team's attention?
16:48:34 <dpyzhov> sure
16:48:39 <enikanorov_> https://bugs.launchpad.net/fuel/+bug/1495466
16:48:39 <openstack> Launchpad bug 1495466 in Fuel for OpenStack "VNC console via horizon directs to wrong URL" [Medium,Confirmed] - Assigned to Fuel Documentation Team (fuel-docs)
16:49:03 <mihgen> enikanorov_: what about it?
16:49:10 <enikanorov_> this is an axample of very confusing UX that will cost us a number of support-hours
16:49:13 <xarses> enikanorov_: it's on the agenda
16:49:40 <dpyzhov> I saw this bug
16:49:43 <xarses> moving ?
16:49:50 <mihgen> yes let's move
16:49:53 <xarses> #topic Multirack status (alex_didenko)
16:49:53 <mihgen> but for this bug
16:50:00 <mihgen> we need a discussion or start a ML thread
16:50:03 <mihgen> I agree with enikanorov_
16:50:12 <mihgen> I don't like how we treat such UX bugs at the moment
16:50:22 <alex_didenko> We've finished scoping of multirack with static routes for 8.0. Some rough numbers in man weeks: software engineers 13, deployment engineers 5, UI 8, QA 15-17.
16:50:31 <alex_didenko> As you can see we need to do a lot of work in nailgun, UI and tests.
16:50:43 <alex_didenko> As for cross-multirack HA (controllers in different racks) we'll investigate the possibility of providing this by using external load-balancer.
16:50:51 <alex_didenko> It should be doable in 8.0 without additional changes in Fuel, already designed and scoped features should cover this use case. We just need to do some research and provide documentation on how to set it up.
16:51:19 <mihgen> alex_didenko: +1 on the approach, thank you
16:51:40 <mihgen> I thought that it's gonna take less though to complete baseline with static routes...
16:52:14 <angdraug> moving on?
16:52:19 <xarses> #topic Network config modularization status (rmoe)
16:52:31 <rmoe> As part of the Fuel modularization effort I implemented a PoC of a separate network configuration service using Flask-SQLAlchemy.
16:52:31 <rmoe> Recently I've converted it to Pecan. My upcoming plans are to expand the Pecan API service, finish implementing the client library and write a spec for this. aglarendil is also working on serializing the data out of this service for test purposes
16:52:40 * yottatsa is watching on cross-multirack HA
16:52:51 <rmoe> there is also some other modularization work going on right now, but others would need to speak to that
16:53:22 <mihgen> rmoe: thanks. did you start a design spec for this work.. ?
16:53:35 <rmoe> today I will
16:53:47 <angdraug> action for rmoe?
16:53:49 <mihgen> anyone works on serializers refactoring?
16:54:28 <rmoe> I'm not sure, aglarendil is working on network serialization as part of this change
16:54:37 <mihgen> aglarendil: will you provide a possible approaches on it in etherpad and share with everyone.. ?
16:54:43 <rmoe> evgenyl can probably speak to those plans as well
16:54:47 <mihgen> from architecture standpoint
16:54:51 <rmoe> other serializer work I mean
16:55:04 <angdraug> time
16:55:16 <evgenyl> Nobody is working on refactoring of current serializers.
16:55:22 <mihgen> thanks rmoe, let's move on
16:55:24 <angdraug> 4 minutes, 2 more topics
16:55:28 <xarses> #topic default FQDN for ssl https://bugs.launchpad.net/fuel/+bug/1495466 (sbog, xarses)
16:55:28 <mihgen> I'll poke aglarendil
16:55:29 <evgenyl> But as it was said aglarendil is working on networking part.
16:55:29 <openstack> Launchpad bug 1495466 in Fuel for OpenStack "VNC console via horizon directs to wrong URL" [Medium,Confirmed] - Assigned to Fuel Documentation Team (fuel-docs)
16:55:31 <akasatkin> Let's have some public docs on it
16:55:44 <mihgen> public docs on what.. ?
16:55:56 <mihgen> akasatkin: serializers refactoring.. ?
16:55:59 <akasatkin> so, etherpad as you mentionewd
16:56:10 <sbog_> We speak about it a little bit with Vitaly. We think that move public fqdn to wizard is rather bad idea. Have a blank field for fqdn by default also isn't so good. Seems that there is no really good solution. We can or disable TLS by default and have a blank field for public fqdn then or we can show a warning to user that also doesn't looks good.
16:56:13 <mihgen> yep, aglarendil promised to share in private conversation
16:56:49 <xarses> So in order to allow TLS/SSL configuration to be on by default we generate a default hostname of public.fuel.local . however this value is not correct for any end user because they will receive responses from services like keystone catalog, and in turn they get url's that they cant access because they where not aware that they needed to configure this value. The bug refrences nova vnc proxy but it impacts any service that returns the
16:56:50 <xarses> endpoint URI such as heat and murano
16:56:50 <xarses> so my though is that we have to change it so the user must set this value. my thought is to make the default blank but require a valid fqdn, this way the user must update the field
16:56:52 <angdraug> why is public fqdn in wizard a bad idea?
16:56:58 <vkramskikh> this issue is 100% consequence of having ssl enabled by default
16:57:29 <mihgen> xarses: +1
16:57:35 <mihgen> let's require a user to ENTER fqdn
16:57:35 <angdraug> vkramskikh: yes, but it doesn't make ssl enabled by default any less of a must-have
16:57:46 <mihgen> BUT user may not have DNS configured still
16:57:49 <vkramskikh> I think this is too low-level entry for a wizard. and in 8.0 we plan to move wizard config from UI description to components description, and this setting won't fit it
16:58:04 <angdraug> they should be forced to either enter fqdn or disable TLS
16:58:19 <mihgen> angdraug: +1
16:58:28 <vkramskikh> this would mean settings are invalid by default
16:58:33 <angdraug> yes
16:58:44 <sbog_> It's bad UX
16:58:51 <mihgen> why invalid by default?
16:58:55 <mihgen> why bad UX?
16:58:55 <xarses> honestly if ssl is enabled by default this impacts 100% of users. there for FQDN and ssl enabled needs to be in the wizard
16:59:01 <sbog_> Because you can't have blank fqdn
16:59:09 <angdraug> xarses: +1
16:59:12 <angdraug> time
16:59:18 <angdraug> we have one more topic and we can't skip it
16:59:25 <bookwar_> Last second announcement: migration from stackforge/ to openstack/ namespace is scheduled for this Saturday 17 October. This will cause disruption in CI and CI team will work over weekend to fix all the issues. Please don't plan any merges and active development for this weekend :)
16:59:26 <mihgen> let's have another topic
16:59:31 <xarses> #topic stackforge/ to openstack/ rename this weekend (bookwar)
16:59:52 <xarses> thanks bookwar_
16:59:57 <mihgen> bookwar_: thanks a lot for helping and making it over weekend..
16:59:57 <xarses> #endmeeting