16:01:26 <kozhukalov_> #startmeeting Fuel
16:01:27 <openstack> Meeting started Thu Nov 12 16:01:26 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:30 <openstack> The meeting name has been set to 'fuel'
16:01:33 <kozhukalov_> hey guys
16:01:37 <ikalnitsky> o/
16:01:38 <sbog> hey
16:01:38 <yottatsa> hi!
16:01:39 <Damjanek> Hi
16:01:40 <kozhukalov_> agenda as usual
16:01:41 <xenolog13> \~/
16:01:41 <monester> hi
16:01:48 <angdraug> o/
16:01:52 <fzhadaev> Hi
16:01:58 <kozhukalov_> #link https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda
16:02:10 <ashtokolov> hi
16:02:11 <rvyalov> hi
16:02:18 <asvechnikov> hi
16:02:19 <akasatkin> hi
16:02:27 <kozhukalov_> #topic Action Items from last meeting
16:02:35 <kozhukalov_> dklenov will figure out the current status of persistent interface naming (ubuntu bootstrap)
16:02:52 <kozhukalov_> dklenov around?
16:02:57 <fzhadaev> Ok. I think I will
16:03:12 <fzhadaev> And... AFAIK Persistent interface naming task is now in progress by ashtokolov.
16:03:13 <mwhahaha> hi
16:03:32 <mattymo> hi
16:03:35 <aderyugin> 0/
16:03:40 <kozhukalov_> fzhadaev, has the spec been merged?
16:04:19 <fzhadaev> No AFAIK
16:04:23 <fzhadaev> https://review.openstack.org/#/c/236848/
16:05:05 <kozhukalov_> tests failed
16:05:59 <kozhukalov_> asyriy ashtokolov please make sure this spec passes tests
16:05:59 <ikalnitsky> fzhadaev: are we going to implement this spec in 8.0 ?
16:06:13 <kozhukalov_> ok, moving on
16:06:26 <kozhukalov_> vkramskikh will review the spec https://review.openstack.org/241202 to make sure everything is clear and it is enough info
16:06:28 <vkramskikh> hi, the spec is still not populated with instructions from asilenkov and didn't have +1 from CI until the last moment. will review when it's close to reviewable state
16:06:59 <fzhadaev> ikalnitsky: I think it sholud be done in current iteration
16:07:07 <kozhukalov_> ci guys, could you please help to review and discuss this spec
16:07:29 <kozhukalov_> asilenkov, around?
16:07:56 <angdraug> bookwar: ^
16:08:01 <kozhukalov_> could you please give the necessary instructions in the spec?
16:08:08 <angdraug> spec says "Infra impact: none", is that really true?
16:08:15 <cfouts> hi
16:08:34 <kozhukalov_> kozhukalov will review all requests in fuel-main
16:09:08 <kozhukalov_> not all of them but many of them have been reviewed since last meeting
16:09:14 <ashtokolov> folks, fyi: enhancements team is working only on nailgun and nailgun-agent support for new interface naming
16:09:19 <kozhukalov_> nurla will poke tatyana or someone else to review all requests in fuel-ostf
16:09:31 <kozhukalov_> nurla, around?
16:09:40 <kozhukalov_> monester will make sure that people from MAINTAINERS are added as reviewers automatically
16:10:14 <kozhukalov_> monester, could you please give any comments on this task?
16:10:20 <angdraug> #link https://bugs.launchpad.net/fuel/+bug/1497655
16:10:20 <openstack> Launchpad bug 1497655 in Fuel for OpenStack "Add reviewers automatically based on MAINTAINERS data" [High,Confirmed] - Assigned to Alexander Charykov (acharykov)
16:10:21 <monester> Script to add reviews is ready, now I need to integrate it with our repos using jenkins or try to add a hook to the openstack gerrit. Also I can't find spec with fixed format of MAINTAINERS file, so I make it compatible with files from fuel-* repos.
16:10:22 <angdraug> looks like not done
16:11:16 <monester> review  https://review.fuel-infra.org/#/c/12228/
16:12:04 <monester> mihgen is there any spec with fixed format of MAINTAINERS file?
16:12:08 <angdraug> there's no spec for the format, if you come up with a formal definition of it lets add it to http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
16:12:16 <kozhukalov_> monester any eta on when jenkins-jobs patches will be ready?
16:12:37 <ikalnitsky> angdraug: +1. let's fix format in team structure
16:13:11 <monester> I want to try integrate it as a hook in gerrit, so not to checkout repos every time which would be done by jenkins
16:13:43 <kozhukalov_> zuul?
16:14:09 <monester> so there I need help from openstack-infra team, I'll try to point out this question with them
16:14:11 <angdraug> why zuul?
16:14:41 <kozhukalov_> angdraug, i don't know, why not?
16:14:57 <angdraug> igorbelikov bookwar: can you folks help monester with his gerrit hook problem?
16:15:03 <monester> right now you can review the script
16:15:05 <kozhukalov_> zuul is a standard tool to listen gerrit events and run jenkins jobs?
16:15:10 <kozhukalov_> right?
16:15:14 <igorbelikov> angdraug sure
16:15:17 <angdraug> zuul listens to merge events
16:15:20 <bookwar> kozhukalov the point here is not to run jenkins job at all
16:15:29 <igorbelikov> kozhukalov_ zuul is not suited for this task
16:15:34 <bookwar> but do all changes server side on Gerrit
16:15:42 <kozhukalov_> ok, maybe i am wrong
16:16:00 <kozhukalov_> moving on?
16:16:11 <bookwar> so we need to discuss option to install this gerrit hook with Openstack Infra
16:16:21 <bookwar> yes, let's move on
16:16:44 <kozhukalov_> first topic we've just discussed
16:16:50 <kozhukalov_> #topic external snapshots in fuel-devops https://blueprints.launchpad.net/fuel/+spec/system-test-external-snapshots (akaszuba)
16:17:12 <angdraug> akaszuba is not around, lets push this to next week
16:17:24 <kozhukalov_> ok
16:17:35 <kozhukalov_> #topic Telco Team Status (fzhadaev)
16:17:48 <fzhadaev> Telko team is continue work on Ubuntu bootstrap feature. Here is the current status:
16:17:50 <fzhadaev> 1) Fuel menu was changed. All commits are merged.
16:17:55 <fzhadaev> 2) Bootstrap creation script enhancements - all basic functionality is done, but some of commits are still in active review and testing stage.
16:17:59 <fzhadaev> 3) Nailgun-agent enhancement - add ability to collect information about loaded bootstrap image uuid. Commit is on review.
16:18:03 <fzhadaev> 4) Work on CLI for bootstrap images management was started.
16:18:06 <fzhadaev> 5) Work on changes related to fuel-library was started.
16:18:11 <fzhadaev> 6) Fuel menu and bootstrap image modifications were shown on demo. According to feedback that was received during demo it was decided to:
16:18:14 <fzhadaev> 6.1) Do not delete CentOS bootstrap image, but use Ubuntu by default.
16:18:18 <fzhadaev> 6.2) Make additional changes in fuel menu for better User Experience.
16:18:24 <kozhukalov_> fzhadaev, 1) including pbr?
16:18:41 <fzhadaev> Nope. It wasn't related to BP
16:19:05 <kozhukalov_> 2) yes, we need to review, the ball is on our side
16:19:09 <ikalnitsky> fzhadaev: so basically, we're building ubuntu bootstrap image during master node deployment ? and it's already in master, right?
16:19:36 <kozhukalov_> 3) we've just discussed this with alexey zvyagintsev
16:19:44 <fzhadaev> ikalnitsky: nope. it's not merged now
16:19:48 <kozhukalov_> and agreed about how to do this
16:20:10 <mihgen> fzdarsky: so when exactly image build happens?
16:20:26 <mihgen> when we run puppet to install master node containers /configure them?
16:20:53 <angdraug> fzhadaev: ^
16:21:09 <fzhadaev> mihgen: When all changes will be merged this will happen during master node deployment
16:21:40 <angdraug> mihgen is asking about which specific stage of master node deployment
16:21:50 <kozhukalov_> fzhadaev, ok, like it does now bootstrap-image-builder shell script, right?
16:22:27 <fzhadaev> yes, but we'll have an ability to build images manualy after master node will be deployed
16:22:38 <kozhukalov_> fzhadaev, great
16:22:38 <mihgen> do we expect our master node install time to be extended? if so, for how much?
16:22:49 <angdraug> can you skip this during master node deployment?
16:22:52 <kozhukalov_> i think that exactly what we need
16:22:56 <fzhadaev> angdraug: yes
16:22:59 <angdraug> is there an option to provide a pre-cooked image?
16:23:18 <angdraug> any other way to make life easier in an environment without internet access?
16:23:26 <ikalnitsky> if master node deployment time will be increased (and it should), we have to increase our timeouts in fuel-qa tests.
16:23:54 <angdraug> ikalnitsky: no, lets agree not to increase master node deployment time instead
16:24:05 <angdraug> at least not in an automated test environment
16:24:06 <kozhukalov_> angdraug, why should we skip this? fuelmenu allows to choose the flavor of bootstrap image. if centos is choosen then we don't spend time for building image, if ubuntu, we should build
16:24:15 <fzhadaev> angdraug: we'll have an ability to skip building image aand import pre-builded image after master node will be deployed
16:24:21 <ikalnitsky> how can you can achieve this? by placing pre-cooked image?
16:24:39 <ikalnitsky> we anyway should do some tests that image could be automatically built during master node deployment
16:24:41 <angdraug> +1 -- can this be triggered from fuel-qa?
16:25:07 <kozhukalov_> fzhadaev, it is even better
16:25:48 <angdraug> if so, we can have just one fuel-qa test scenario where image build is tested during master node deploy
16:25:57 <mihgen> time folks. fzhadaev - it should be in the spec, so please let us know where to look for all these answers
16:25:59 <angdraug> and in all other scenarios, save time and upload a pre-build image
16:26:13 <mattymo> we have verify that the image can be built too^
16:26:15 <mihgen> +1 to angdraug
16:26:17 <mattymo> test coverage is important
16:26:34 <kozhukalov_> ok, guys, i think the progress here is good and all the details can be discussed either in ML or chat
16:26:44 <fzhadaev> spec: https://review.openstack.org/#/c/229063/
16:26:48 <kozhukalov_> moving on?
16:27:09 <kozhukalov_> #topic Enhancements Team Status (ashtokolov)
16:27:36 <ashtokolov> Enhancements weekly status: Inbox - 62(was 65), In progress - 12(was 12), On review - 23(was 25), QA - 15(was 17), Done - 24(was 16)
16:27:42 <ashtokolov> Fix committed+Fix released = 39 (was 33)
16:27:58 <ashtokolov> also we are working on new network naming
16:28:09 <ashtokolov> support multiple floating ranges
16:28:31 <ashtokolov> and openstack-ci integration
16:28:42 <kozhukalov_> ashtokolov, about persistent naming. are you following this spec https://review.openstack.org/#/c/236848/ ?
16:28:59 <mihgen> thanks ashtokolov, any work on enabling plugin after env is deployed?
16:29:49 <ashtokolov> kozhukalov_ yes we do, Alexaner Gordeev and Vova Sharshov are reviewing it
16:30:38 <kozhukalov_> moving on? comments on plugin stuff?
16:30:41 <ashtokolov> mihgen: we try to figure out what was made in this feature by mixed team
16:31:04 <ashtokolov> because it was in their backlog till last week...
16:31:39 <kozhukalov_> #topic Mixed Team Status (damjanek)
16:31:54 <Damjanek> Fuel Mixed team is currently working on feature which enables adjusting OpenStack configuration parameters in post-deployment phase:
16:31:58 <Damjanek> 1. We have completed research on puppet modules idempotence - done.
16:32:02 <Damjanek> 2. We've created puppet resource for handling configuration changes - merged.
16:32:06 <Damjanek> 3. We're working on allowing to change config values via API and CLI - in development.
16:32:10 <Damjanek> 4. We're working on keyston/nova/neutron granular tasks to allow configuration change - in development.
16:32:53 <Damjanek> s/keyston/keystone/
16:33:12 <kozhukalov_> any q here?
16:33:14 <yottatsa> Damjanek is there any bp?
16:33:28 <Damjanek> yottatsa: Yup. Here - https://review.openstack.org/#/c/239897/
16:33:33 <yottatsa> thnx
16:33:36 <Damjanek> n/p
16:33:52 <kozhukalov_> Damjanek, thanks, moving on then
16:33:52 <angdraug> so, enabling plugins after env is deployed?
16:34:14 <angdraug> ashtokolov: Damjanek: can you sync up in #fuel-dev after the meeting?
16:34:25 <Damjanek> angdraug: Sure thing
16:34:33 <angdraug> lets move on then
16:35:07 <kozhukalov_> #topic UI Team status (vkramskikh)
16:35:15 <vkramskikh> Hi! Here are the results of Iteration #2:
16:35:15 <vkramskikh> - Multirack support: 1 of 3 stories merged, 2 stories left: support of node network groups on the networks tab (was moved to iteration #3) and view of all available nodes. We plan to complete both stories by the end of the next week.
16:35:15 <vkramskikh> - Support IP ranges for all networks in UI - done
16:35:15 <vkramskikh> - GUI support for Ironic - done, but still waiting to merge https://review.openstack.org/#/c/229879/
16:35:16 <vkramskikh> - Segment settings tab logically - was converted to an Epic and new stories were added as it seems it's not possible to segment the tab properly without splitting some existing groups. This will require update of puppet manifests - we'll reach for help from library guys after we update openstack.yaml.
16:35:20 <vkramskikh> - Webpack - done, we finally got the new package with JS libraries merged after 6 week of being blocked. Though the process of its updating isn't established yet - we've filed another update request on Monday, and it's still not updated yet. That's sad - I thought it won't be taking more than 1-2 days.
16:35:24 <vkramskikh> - Separate deployment and provisioning in UI - most likely will be moved out of 8.0 due to very poor quality of the backend
16:35:27 <vkramskikh> For Iteration #3 we plan to finish Multirack support and Segment settings tab logically epics and also deliver support for bootstrap images and link to external plugin dashboards. Thanks.
16:37:06 <kozhukalov_> webpack you mean npm bundle?
16:37:25 <vkramskikh> npm bundle is a prerequisuite for this quite big change
16:37:34 <vkramskikh> https://review.openstack.org/#/c/219036/
16:38:09 <angdraug> looks merged to me )
16:38:16 <vkramskikh> yes
16:38:25 <vkramskikh> but we also wanted to establish the process
16:38:28 <kozhukalov_> aha, but it took a lot more than was expected
16:38:30 <vkramskikh> for updating the bundle
16:38:40 <vkramskikh> and it seems the speed of updates isn't good enough
16:39:01 <ikalnitsky> vkramskikh: you said "very poor quality of backend".
16:39:04 <ikalnitsky> what's wrong with it?
16:39:08 <vkramskikh> as the update request filed on monday is still not processed
16:39:15 <vkramskikh> jaranovich: could you comment please?
16:39:15 <ikalnitsky> do we have ticker or bp that should improve it?
16:39:26 <jaranovich> yes
16:39:28 <jaranovich> See the following issues with provisioning:
16:39:28 <jaranovich> - no notification about finished provisioning on UI
16:39:28 <jaranovich> - ready provisioning task has message = null, so there is nothing to show the user on UI after finished provisioning
16:39:28 <jaranovich> - provisioned nodes has pending_addition flag = False, so user can not change node roles, disks, ifc configuration, or even delete from environment without depolyment
16:39:38 <angdraug> vkramskikh: link to update request from monday?
16:40:06 <vkramskikh> angdraug: https://bugs.launchpad.net/fuel/+bug/1514512
16:40:06 <openstack> Launchpad bug 1514512 in Fuel for OpenStack "JS modules bundle needs to be updated" [Medium,In progress] - Assigned to Fuel build team (fuel-build)
16:40:18 <jaranovich> moreover, deployment of provisioned node(s) fails constantly
16:40:35 <jaranovich> >> Deployment has failed. Method granular_deploy. Deployment failed on nodes 1.
16:40:45 <jaranovich> this is an error message after failed deployment
16:40:57 <kozhukalov_> deployment fails constantly? sounds like a CRITICAL bug
16:41:02 <jaranovich> was tested on ISOs
16:41:15 <ikalnitsky> jaranovich: thanls. (1) and (2) second are easy to fix, and UI anyway shouldn't rely on these. but yeah (3), perhaps, we should manage our blags more precisely.
16:41:22 <ikalnitsky> jaranovich: but how that works from CLI then?
16:41:51 <angdraug> asilenkov: any comment on why your commits for bug linked by vkramskikh above are not merged yet?
16:41:52 <ikalnitsky> i believe you guys doing something wrong, or in some unusual way. perhaps there's a bug and we should fix it, but the main case should work
16:42:18 <vkramskikh> jaranovich: could you please give ikalnitsky a link to the request?
16:42:31 <vkramskikh> with UI change which calls provisioning separately
16:42:35 <jaranovich> i don't know about CLI but i can file a bug about failed deploy and attach logs there. Also, I use /api/clusters/x/provision/ url to launc provisioning process
16:42:37 <jaranovich> is it Ok?
16:42:43 <jaranovich> ikalnitsky: ^^
16:43:00 <ikalnitsky> it should.. but i think you have to pass a list of node there
16:43:05 <ikalnitsky> ok, let's move on
16:43:11 <ikalnitsky> we can discuss the issue a bit later
16:43:12 <angdraug> lets make sure there's a bug
16:43:13 <ikalnitsky> thank you
16:43:20 <angdraug> and yes lets move on
16:43:33 <jaranovich> thank you, will create a bug
16:43:44 <kozhukalov_> thanks guys
16:43:57 <kozhukalov_> #topic Multirack status (akasatkin)
16:44:02 <akasatkin> 3 stories were completed during last iteration:
16:44:17 <akasatkin> 1. Make additional setup of dnsmasq on master node when admin network parameters are changed in any node network group. User should do that by hands now.
16:44:41 <akasatkin> 2. It should be allowed to allocate VIP in any node group to allow proper separation of HA services into different nodes.
16:44:42 <akasatkin> 3. Make it possible to set floating IP range from non-default node network group. So, it will be possible to deploy controller nodes in any node group.
16:45:12 <akasatkin> The following is in progress now:
16:45:13 <akasatkin> There is an ability to share network between several node network groups or to use separate L2/L3 parameters for each node network group.
16:45:13 <akasatkin> We have limited resources so it seems that the following may be out of scope:
16:45:13 <akasatkin> 1. It should be allowed to set user-defined IP for any VIP. This IP can even be out of any environment's networks. (It should be discussed how to reduce its scope.)
16:45:13 <akasatkin> 2. There is a special case when network managed by dhcp (PXE network) needs VIPs to be assigned. IP addresses should be excluded from Admin networks' IP ranges (i.e. from DHCP ranges). This can be done manually as a workaround.
16:45:36 <akasatkin> That's it.
16:45:45 <kozhukalov_> akasatkin, thanks
16:46:01 <kozhukalov_> any q?
16:46:46 <kozhukalov_> #topic Granularize monolyth Neutron task status. (svasilenko)
16:46:55 <xenolog13> "Granularizing Neutron" feature is done, main code merged more than week ago. Tests merged last week.
16:46:55 <xenolog13> Some of network plugins for 8.0 may be affected.
16:46:56 <xenolog13> blueprint: https://blueprints.launchpad.net/fuel/+spec/make-neutron-deployment-task-more-granular
16:48:17 <ikalnitsky> xenolog13: i remember that the patch has a lot of hardcoded "net04" / "net04_ext" stuff. have we get rid if this?
16:48:35 <ikalnitsky> since it blocks one of my patches
16:48:48 <xenolog13> No, Enchacement team works on it.
16:49:09 <ikalnitsky> any eta?
16:49:31 <mihgen> xenolog13: thanks Sergey. can we separate api / data plane to different nodes?
16:50:18 <mattymo> ikalnitsky, xenolog13 the naming still needs to be done and it should be exposed to the user
16:50:20 <xenolog13> this feature doesn't affect nailgun
16:50:32 <mattymo> I think we're clear to finally merge your portion ikalnitsky
16:51:14 <ikalnitsky> mattymo: xenolog13 just said we didn't get rid of it?
16:51:21 <xenolog13> ikalnitsky, net04* names hardcode used only if network names not given from YAML
16:51:56 <mattymo> ikalnitsky, we're still going forward with what's on review. xenolog13 is referring to the neutron_config values in astute.yaml that we already discussed
16:51:59 <angdraug> a hardcode is a hardcode
16:52:11 <mattymo> angdraug, there's a default if the value isn't present in astute.yaml (so we can do it in pieces)
16:52:21 <mattymo> otherwise we break CI and someone cries
16:52:38 <bookwar> thanks, mattymo
16:52:51 <kozhukalov_> one more topic left in our agenda
16:53:00 <angdraug> are you saying you will remove the hardcode before the feature is finished?
16:53:08 <kozhukalov_> are we done here?
16:53:11 <mattymo> angdraug, yes
16:53:24 <angdraug> ok, lets move on then
16:53:36 <kozhukalov_> Too much question like "how to extend bridge mappings" into Neutron. Proposal of micro-feature. (svasilenko)
16:53:47 <xenolog13> last time too many peoples interested two question:
16:53:47 <xenolog13> How to make provider networks by fuel?
16:53:47 <xenolog13> How to make multiple external (floating) networks?
16:53:47 <xenolog13> Unfortunately Fuel does not support out of box such features.
16:53:47 <xenolog13> I propose following changes:
16:53:48 <xenolog13> If we authomatize calculation of bridge mapping and vlan-ID mappings from neutron_config hash
16:53:50 <xenolog13> we will got ability for flexible create required configuration.
16:53:52 <xenolog13> After this each plugin-writers wil have ability
16:53:54 <xenolog13> to override neutron configuration and add his own non-standart mappings to our default.
16:53:56 <xenolog13> This changes not so complicated.
16:53:58 <xenolog13> Also this changes will cober bugs, like bug/1515197, bug/1489718.
16:54:00 <xenolog13> This changes give us ability to implement provider networks as plugin, because FF is coming.
16:54:37 <angdraug> what components need to be changed to support that?
16:55:21 <xenolog13> change some hardcode in Nailgun (1 python developer/1day)
16:55:36 <angdraug> is that all?
16:55:45 <xenolog13> make function for generate required resources (1 puppet end/2 days)
16:56:14 <xenolog13> s/end/engineer/g
16:56:27 <angdraug> 3 person-days looks cheap to me
16:56:33 <angdraug> what about testing and documentation?
16:56:36 <mihgen> xenolog13: this sounds like a good idea
16:57:03 <kozhukalov_> enchancments team?
16:57:14 <angdraug> will existing tests be affected by this change?
16:57:15 <xenolog13> I can make small blueprint and loop test for this task.
16:57:55 <xenolog13> Yes, we has test for current configuration, but for extended configuration we should add some new
16:58:02 <mihgen> it's probably more for unit-like tests and get partner team to review / play with code
16:58:21 <angdraug> mihgen: +1
16:58:30 <angdraug> lets do it
16:58:46 <kozhukalov_> ok, if we have people for this, let's do this, probably we first need a little bit for formal description
16:58:49 <xenolog13> +1
16:58:55 <kozhukalov_> 2 minutes
16:59:02 <angdraug> open discussion?
16:59:11 <kozhukalov_> no time
16:59:15 <kozhukalov_> closing
16:59:29 <kozhukalov_> thanks everyone
16:59:34 <kozhukalov_> #endmeeting