Re: [openstack-dev] [Fuel] Common fuel-core group for all Fuel projects

+1 to Lukasz. -1 to the proposal, we had it this way for a quite some time, and it was not good for the project (as Lukasz pointed out), why should a person who merges the code to the library have an access to merge the code to Nailgun/Astute without proper expertise. Those are different areas

Re: [openstack-dev] [Fuel] Nominate Artur Svechnikov to the fuel-web-core team

Hi Dmitry, It depends, but usually it takes half of working time to do reviews, I'm not sure if we can assume 25-30%, also finding a good reviewer usually is much harder than a person who can write the code, so it would be much more productive to encourage people to spend as much time as they can

Re: [openstack-dev] [Fuel][Plugins] One plugin - one Launchpad project

Hi Irina, I fully support the idea of creating separate launchpad project for each plugin, because plugins have different release cycles and different teams who support them. Fuel Plugin documentation [2] has to be updated with information for plugin developers (how to setup new project) and for

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

> necessary to merge such custom things into Ironic tree. Happily, Ironic > is > > smart enough to consume drivers using stevedore. About ironic-inspector > > the case is the same. Whether we are going to run it inside 'user > instance' > > or inside ramdisk it does not affect

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

ecause Shotgun is a generic > tool. Please review these [1], [2]. > > [1] https://review.openstack.org/#/c/298603 > [2] https://review.openstack.org/#/c/298615 > > > Btw, one of the ideas was to use Fuel task capabilities > to gather diagnostic snapshot. > > Vladimir Koz

Re: [openstack-dev] [Fuel] Newton Design Summit sessions planning

Hi, no problem from my side. On Thu, Apr 14, 2016 at 10:53 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > I'd like to request workrooms sessions swap. > > We have a session about Fuel/Ironic integration and I'd like > this session not to overlap with Ironic

Re: [openstack-dev] [Fuel] [Shotgun] Decoupling Shotgun from Fuel

Hi, Problems which I see with current Shotgun are: 1. Luck of parallelism, so it's not going to fetch data fast enough from medium/big clouds. 2. There should be an easy way to run it manually (it's possible, but there is no ready-to-use config), it would be really helpful in case if

Re: [openstack-dev] [fuel] Component Leads Elections

Hi, I'm not sure if it's a right place to continue this discussion, but if there are doubts that such role is needed, we should not wait for another half a year to drop it. Also I'm not sure if a single engineer (or two engineers) can handle majority of upcoming patches + specs + meetings around

Re: [openstack-dev] [Fuel][Infra] Nailgun extensions testing

Hi Roman, >> reasonable to just install it from PyPi (first we need to release Nailgun to PyPi) Yes there will be dependencies, but there should be a way to test core extensions (those which go to standard Fuel build) from master (or any other branch), so installing from pypi is not always an

[openstack-dev] [Fuel][Bareon][Ironic] The future of integration module

Hi, I would like to bring up discussion on Bareon [0] and Ironic integration and plans for the future. But first let me provide background information on the topic. Bareon is partitioning/provisioning system [1] which is based on Fuel-agent [2], currently it's in active development and will be

[openstack-dev] [Bareon] Weekly update

Hi, here is a weekly update from Bareon team. 1. Extensions testing procedure in Fuel (required for Bareon integration). 1.1. Spec is still in progress [0]. 1.2. Email was sent [1] to figure out the best way to do it in OpenStack Infra, we would appreciate for any help on that. 2. Bareon dynamic

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

On Thu, Mar 17, 2016 at 3:16 PM, Dmitry Tantsur <dtant...@redhat.com> wrote: > On 03/16/2016 01:39 PM, Evgeniy L wrote: > >> Hi Dmitry, >> >> I can try to provide you description on what current Nailgun agent is, >> and what are potential requirements

Re: [openstack-dev] [Fuel] [ironic] [inspector] Rewriting nailgun agent on Python proposal

Hi Dmitry, I can try to provide you description on what current Nailgun agent is, and what are potential requirements we may need from HW discovery system. Nailgun agent is a one-file Ruby script [0] which is periodically run under cron. It collects information about HW using ohai [1], plus it

[openstack-dev] [Fuel] Plans on networking modularisation

Hi, We've been working on networking modularisation, during this activity Nailgun is being fixed [0] in order to provide better layer boundary between network related code and the rest of the system. The purpose of this email is: 1. To make sure that this activity is known in Fuel team. 2. To

Re: [openstack-dev] [Fuel] Rewriting nailgun agent on Python proposal

Hi Alexander, thanks for bringing this up. >From your list of problems the only problem which I see is 1st, 2nd and 3rd are solvable even with current implementation. Also I don't think that we should continue developing our own HW discovery mechanism, we should consider switching to

Re: [openstack-dev] [Bareon] Weekly update

On Mon, Mar 14, 2016 at 6:53 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, here is update from Bareon team. > 1. The team was actively helping with reviews/debugging/triage/designs for > Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the > code is merged [7],

[openstack-dev] [Bareon] Weekly update

Hi, here is update from Bareon team. 1. The team was actively helping with reviews/debugging/triage/designs for Fuel 9.0 release [0-6].2. Changing deployment data with extensions, the code is merged [7], also bug is fixed [8].3. Extensions testing procedure spec is still in progress [9].4. Dynamic

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, thanks for clarification. On Fri, Mar 11, 2016 at 9:42 AM, Mike Scherbakov wrote: > Thank you for comments folks. > Clarifications, with the feedback incorporated: > 1) We can install plugin developed against 8 to Fuel Mitaka (9). But it > won't appear in the

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

Hi, +1, it's very hard to use current representation of logs for debugging, everybody goes to the node and tries to find required logs, instead of reimplementing debugging friendly tool it would be better to get something ready to use on the master. Thanks, On Fri, Mar 11, 2016 at 12:05 PM,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

ramework for every change to the framework, so that we can > have > > -1 right away if something goes wrong. > > > > I've started separate thread on general thoughts about backward > > compatibility and multiple releases support, which actually affects > > examples: [1

Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions

Hi Mike, comments are inline. On Thu, Mar 10, 2016 at 10:30 AM, Mike Scherbakov wrote: > Hi folks, > in order to make a decision whether we need to support example plugins, > and if actually need them [1], I'd suggest to discuss more common things > about plugins. > >

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

coverage? > > On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "templates" the plugin which is create by just "fpb >> --create plugin-name"? >> It doesn't cover enough, package inst

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Ilya, What do you mean by "templates" the plugin which is create by just "fpb --create plugin-name"? It doesn't cover enough, package installation and all range of tasks executions. Thanks, On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov wrote: > Igor, i completely agree,

Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?

Hi, Plugin examples mustn't be removed, those plugins are part of integration tests for fuel plugin builder, which should be able to build any version of plugin. So there are two ways to solve the problem: 1. Before test run update compatibility matrix for plugins automatically. 2. Continue

Re: [openstack-dev] [Fuel] UI code freeze

Hi, Thank you for your work, really happy to see it done. So as far as I can see from now on in fuel-web repository we have only Nailgun project. Is it correct? On Fri, Feb 26, 2016 at 3:53 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > Dear colleagues, > > We are ready for moving

Re: [openstack-dev] [Fuel][Solar] Integration in 9.0

Hi Jedrzej, >> Maybe instead blueprint in 1st step should we create full blown fuel-spec? If there is anything to be discussed in implementation, or there are different options to do it, it's better to have blueprint and spec, so everybody will be able to see what the integration looks like.

Re: [openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

dae...@mirantis.com > wrote: > If the spec is not going to require code changes in 9.0/Mitaka, why not > simply target it for 10.0/Newton? > > On Thu, Feb 25, 2016 at 05:21:55PM +0300, Evgeniy L wrote: > > Hi, > > > > We have a spec where we are trying to do research and d

[openstack-dev] [Fuel] Question about Feature Freeze Exceptions for non-invasive features

Hi, We have a spec where we are trying to do research and describe how we are going to test extensions [0], we will not be able to land it before feature freeze, so should we get feature freeze exception for it? Or it will not be a problem to merge it even after FF? The spec itself is more about

[openstack-dev] [Bareon] Weekly update

Hi, Here is weekly update from Bareon team. 1. 3 specs from Cray team were merged [0], roadmap was properly adjusted [1] 2. Changing deployment data using extensions in Nailgun [2], spec is merged, code is on review [3] 3. Extensions testing procedure, spec is in progress [4] 4. Dynamic

Re: [openstack-dev] [Fuel] Wildcards instead of

Hi, +1 to Igor, plugin developer should be able to granularly define what she/he wants to be executed on the node, without assumptions from our side. `exclude` - field doesn't look like a good solution to me, it will be hard to support and migrate plugins to newer version OpenStack release. I

Re: [openstack-dev] [fuel][nailgun][volume-manager][fuel-agent] lvm metadata size value. why was it set to 64M?

Hi Alexander, I was trying to trace the change and found 3 year old commit, yes it's hard to recover the reason [0]. So what we should ask is what is a right way to calculate lvm metadata size and change this behaviour. I would suggest at least explicitly set metadata size on Nailgun side to the

Re: [openstack-dev] [fuel] Fuel plugins: lets have some rules

Hi, I have some comments on CI for plugins, currently there is a good instruction on how to install your own CI and using fuel-qa write your own tests [0], since just running BVT is not enough to make sure that plugin works, we should provide a way for a plugin developer to easily extend

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

That is awesome, happy to finally see it enabled! On Mon, Feb 15, 2016 at 9:32 PM, Anastasia Urlapova wrote: > Aleksey, great news! > > On Mon, Feb 15, 2016 at 7:36 PM, Alexey Shtokolov > wrote: > >> Fuelers, >> >> Task based deployment engine

[openstack-dev] [Bareon] Weekly update

Hi, After the discussion with some folks, we agreed that it might be useful for the community to start sending weekly updates on what Bareon team is working on and what is our progress. So here is a first weekly update from Bareon team. 1. Data pipelines for Nailgun integration (changing

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

ould you please clarify what multi-package is? Thanks, On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Ilya, >> >> What do you mean by "d

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

ve some things which are related to the deployment specified in the root and some in specific release. There is consistent mechanism to specify such kind of things, lets just use it. Thanks, On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov <ikutu...@mirantis.com> wrote: > > > On Fri, Feb

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Ilya, >> My opinion that i've seen no example of multiple software of plugins versions shipped in one package or other form of bundle. Its not a common practice. With plugins we extend Fuel capabilities, which supports multiple operating system releases, so it's absolutely natural to extend

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Sorry for the typo "s/I can shade more light/I can shed more light/" On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, > > As an author of this part of pluggable architecture I can shade more light > on why it was implemented this way and w

Re: [openstack-dev] [Fuel] Task Based Deployment Is at Least Twice Faster

+1 On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > +1 to enable it ASAP. > > It will also affect our deployment tests (~1 hour vs. ~2.5 hours). > > Vladimir Kozhukalov > > On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin > wrote:

Re: [openstack-dev] [Fuel] Nominate Fedor Zhadaev for the fuel-menu-core team

+1 On Mon, Feb 8, 2016 at 12:54 PM, Igor Kalnitsky wrote: > Hey Fuelers, > > I'd like to nominate Fedor Zhadaev for the fuel-menu-core team. > Fedor's doing good review with detailed feedback [1], and has > contributes over 20 patches during Mitaka release cycle [2]. >

[openstack-dev] [Bareon][Fuel] Best practises on syncing patches between repositories

Hi, Some time ago we started Bareon project [1], and now we have some fixes landed to fuel-agent only, the question is what are the best practises on keeping two repos in sync with possibility to resolve conflicts manually? Cherry-picking patches manually doesn't look like the most error prone

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

om> wrote: > Thanks Evgeniy. > > On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L <e...@mirantis.com> wrote: > >> Hi Simon, >> >> As far as I know it's expected behaviour (at least for the current >> release), and it's expected that user reruns deployment on requir

Re: [openstack-dev] [Fuel][Plugins] question on the is_hotpluggable feature

Hi Simon, As far as I know it's expected behaviour (at least for the current release), and it's expected that user reruns deployment on required nodes using fuel cli, in order to install plugin on a live environment. It depends on specific role, but "update_required" field may help you, it can be

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi, In addition I've generated several examples in order to show how current prototype allocates the volumes [0]. Thanks, [0] http://bareon-allocator.readthedocs.org/en/latest/examples.html On Wed, Jan 13, 2016 at 2:14 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi Artur, > >

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

allocate a single volume on ssd and hdd > > > Best regards, > Svechnikov Artur > > On Tue, Jan 12, 2016 at 9:37 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Hi, >> >> For the last several weeks I've been working on algorithm (and prototype) >> for dyna

[openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi, For the last several weeks I've been working on algorithm (and prototype) for dynamic allocation of volumes on disks. I have some results [0] and would like to ask you to review it and provide some feedback. Our plan is to implement it as an external driver for Bareon [1]. Thanks, [0]

Re: [openstack-dev] [fuel] github can't sync with git because of big uploading

Hi, You should probably talk to infra team on this issue #openstack-infra channel. I see several ways what can be done here: 1. recreate the repo 2. create a repo with different name Also there is possibility to remove from the commit those files and push using --force, but it's a very bad

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

te: > >> I agree with Evgeny: from work organization it would more optimal to have >> 2 repos. API and system facing programming are completely different >> domains, requiring different skill sets. In my opinion separation would >> lower the entry barriers. >> >>

Re: [openstack-dev] [Fuel] Removal of support for nova-network

Hi, We mustn't touch Nailgun's logic, otherwise after upgrade user won't be able to manage her/his old nova Cluster. So lets just remove it from UI. Also as far as I know we should provide a way to manage old clusters not for a release, but for a couple of years. Thanks, On Tue, Dec 22, 2015 at

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

ro' having ConfigDB separate from Solar is that it will > simplify transition from current Fuel architecture by breaking it into more > definite stages and reducing the number of components Solar have to be > integrated with. > > -- > Best regards, > Oleg Gelbukh > > On Wed, Dec 16, 20

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

> > The point is that for Solar integration, we still need integration points, > and the less of them we have, the more simple the transition is going to > be.. > As described above, there will be a single integration point, data processor. > > -- > Best regards, > Ole

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

Hi Andrew, It doesn't look fair at all to say that we use Postgres specific feature for no reasons or as you said "just because we want". For example we used Arrays which fits pretty well for our roles usage, which improved readability and performance. Or try to fit into relational system

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

h additional efforts on fixing 2 >>> different environments. Let's just think from the point of development >>> velocity here and at delay such changes for at least after NY. Because if >>> we do it immediately after SCF there will be a whole bunch of holidays and >>> Russian hol

[openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

Hi, Some time ago, we’ve started a discussion [0] about Fuel modularisation activity. Due to unexpected circumstances POC has been delayed. Regarding to partitioning/provisioning system, we have POC with a demo [1] (thanks to Sylwester), which shows how the integration of Fuel and Bareon [2] can

Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations

Hi, Since older Postgres doesn't introduce bugs and it won't harm new features, I would vote for downgrade to 9.2 The reasons are: 1. not to support own package for Centos (as far as I know 9.3 for Ubuntu is already there) 2. should Fuel some day be a part of upstream Centos? If yes, or there is

Re: [openstack-dev] [Fuel][Bareon] Fuel & Bareon integration (fuel modularisation)

y, and start production ready implementation > > For what reason do we need a separate repo? I thought API will be a > part of bareon repo. Or bareon is just a provisioning agent, which > will be driven by bareon-api? > > On Thu, Dec 17, 2015 at 12:29 PM, Evgeniy L <e...@mirantis.com>

[openstack-dev] [All][Bareon][Fuel][Ironic] New project: Bareon (provisioning system)

We are happy to introduce Bareon [0], which is a fork of fuel_agent [1] project which have been developed under Fuel’s umbrella. Bareon provides flexible and data driven interface to perform actions which are related to operating system installation. In contrary to standard kickstart and preseed

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

Hi Dmitry, I also don't think that we should duplicate the data in configdb, because in this case there will be +2 additional interfaces which will require to covert the data into configdb and after that from configdb to Solar, which seems redundant overhead. But we should be able to put the

Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node

+1 to Vladimir Kozhukalov, Entire point of moving branches creation to SCF was to perform such changes as early as possible in the release, I see no reasons to wait for HCF. Thanks, On Wed, Dec 16, 2015 at 10:19 AM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote: > -1 > > We already

Re: [openstack-dev] [Fuel] Nominate Bulat Gaifulin for fuel-web & fuel-mirror cores

+1 On Tue, Dec 15, 2015 at 12:33 PM, Anastasia Urlapova wrote: > +1 > > On Mon, Dec 14, 2015 at 3:20 PM, Roman Vyalov > wrote: > >> +1 >> >> On Mon, Dec 14, 2015 at 3:05 PM, Aleksey Kasatkin > > wrote: >> >>> +1. >>> >>>

Re: [openstack-dev] [Fuel] Experimental Task Based Deployment Landed into Master

+1 It's really good job folks. On Sat, Dec 12, 2015 at 2:25 AM, Vladimir Kuklin wrote: > Fuelers > > I am thrilled to announce that task based deployment engine [0] has been > just merged into Fuel master. We checked it against existing BVT test cases > for regressions as

Re: [openstack-dev] [Fuel] Dropping Python 2.6

Hi Roman, We've discussed it [1], so +1 [1] https://openstack.nimeyo.com/67521/openstack-dev-fuel-dropping-python2-6-compatibility On Mon, Dec 14, 2015 at 5:05 PM, Roman Prykhodchenko wrote: > Fuelers, > > Since Mitaka OpenStack Infra has no resources to test python 2.6

Re: [openstack-dev] [Fuel] Christmas Core Cleanup

com> wrote: > Hey folks, > > In an effort to do some housekeeping, I clean up the list of core > reviewers in Fuel. > > According to Stackalytics the following cores show a low contribution rate: > > # fuel-web [1] > > * Dmitry Shulyak > * Evgeniy L >

[openstack-dev] [Fuel] Dropping python2.6 compatibility

Hi, During Fuel master migration to CentOS7 there was found a problem that tests get failed [0] for python2.6 As far as I can see it's a common practise to drop python2.6 compatibility [1], shouldn't we switch tests to work with python2.7 instead of python2.6? It looks like fuelclient will be

Re: [openstack-dev] [Fuel] Patch size limit

Hi Maciej, thank you for bringing this up, +1, but we should discuss the limit, personally for me it's ok to review 400loc patches, if the patch covers only one bug-fix/feature implementation. So if everybody is agree, we should: 1. update contribution guide 2. create a task for *non-voting*

Re: [openstack-dev] [Fuel] Fuel Python Gerrit Dashboard

Thanks Igor, it's very helpful, Also if you forget where to get the link, use the documentation [1]. I think something like that may also be useful for library and QA team. Thanks, [1] https://wiki.openstack.org/wiki/Fuel#Development_related_links On Mon, Nov 30, 2015 at 3:29 PM, Igor

Re: [openstack-dev] [Fuel] [Fuel UI] Support of separate provisioning is blocked by backend issues

Hi, I have several comments, just to make sure, that we are on the same page here. Current API calls for provisioning/deployment are used by developers and fuel hackers, and by design there was removed all validation. So shouldn't there be some more user friendly API calls which have validation?

Re: [openstack-dev] [Fuel] Master node upgrade

he containers (such as puppet >>>> manifest changes). There shouldn't be a need to back up the entire >>>> containers. >>>> >>>> The information we would lose would include the IP configuration >>>> interfaces besides the one used for the Fuel PXE

Re: [openstack-dev] [Fuel] shotgun code freeze

+1 to Dmitry, thanks for pushing this activity Vladimir. On Friday, 6 November 2015, Dmitry Pyzhov wrote: > Great job! We are much closer to removal of fuel-web repo. > > On Tue, Oct 27, 2015 at 7:35 PM, Vladimir Kozhukalov < > vkozhuka...@mirantis.com >

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Javeria, In your case, I think it's easier to generate config on the target node, using puppet for example, since the information which you may need is placed in /etc/astute.yaml file. Also it may be a problem to retrieve all required information about the cluster, since API is protected with

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

onclusion. > > > -- > Javeria > > On Fri, Nov 6, 2015 at 1:41 PM, Evgeniy L <e...@mirantis.com> wrote: > >> Javeria, >> >> In your case, I think it's easier to generate config on the target node, >> using puppet for example, since the information wh

Re: [openstack-dev] [Fuel] Master node upgrade

Hi Vladimir, Cannot say anything about 1st option, which is to use official Centos scripts, because I'm not familiar with the procedure, but since our installation is not really Centos, I have doubts that it's going to work correctly. 2nd option looks less risky. Also we should decide when to

Re: [openstack-dev] [Fuel] Default PostgreSQL server encoding is 'ascii'

Hi, I believe we don't have any VirtualBox specific hacks, especially in terms of database configuration. By "development env" Vitaly meant fake UI, when developer installs and configures the database by himself, without any iso images, so probably his db is configured correctly with utf-8. Also

Re: [openstack-dev] [Fuel][Plugins] Role for Fuel Master Node

Hi Javeria, As far as I know there is no way to run the task on Fuel master host itself. Since MCollective is installed in the container and tasks get executed using MCollective, as a workaround you may try to ssh from the container to the host. Also I have several additional questions: 1. what

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

Hi, The main reason why I think we should get all of the three states is we don't know exactly if those plugins (which developer didn't specify) are compatible or not, so we should not make any assumptions and prevent the user from enabling any plugins she/he wants. The best we can do here is to

Re: [openstack-dev] [Fuel] Modularization activity POC

ct that them bring a set of classical problems (e.g. >> duplication of domain entities) we will win more than loose. :) >> >> If there will be any specs or design meetings, please send me invite - >> I'd gladly join discussions. >> >> Thanks, >> Igor >>

Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun

Hi, I have a comment regarding to when/where run translators. I think data processing (fetching + validation + translation) should be done as a separate stage, this way when we start deployment, we are sure that we have everything we need to perform deployment, but I understand that there might

[openstack-dev] [Fuel] Modularization activity POC

Hi, We are starting Fuel modularization POC activity which is basically in one sentence can be explained as "Use Fuel without Fuel", it means that we want to provide for a user a way to use some good things from Fuel, without entire master node and other parts which user doesn't need. Currently

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Nginx. Thanks, On Fri, Oct 9, 2015 at 11:45 AM, Roman Prykhodchenko <m...@romcheg.me> wrote: > I’d say even if it will be a separate service it’s better to proxy > requests through Nailgun’s API to have a single entry point. > > 9 жовт. 2015 р. о 10:23 Evgeniy L <e...@mirantis.com&g

Re: [openstack-dev] [Fuel] Plugins related functionality in Fuel Client

Hi, +1, but I think it's better to spawn separate service, instead of adding it to Nailgun. Thanks, On Fri, Oct 9, 2015 at 1:40 AM, Roman Prykhodchenko wrote: > Folks, > > it’s time to speak about Fuel Plugins and the way they are managed. > > Currently we have some methods

Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session

Hi Mike, According to the description of the role, I wouldn't say that the role is less architectural than political, since PTL should review designs and resolve conflicts between cores (which are usually technical), PTL should also have strong skills in software architecture, and understanding

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

Hi Dmitry, Thanks for the information. >> My personal opinion is that we can ignore our medium-priority technical debt bugs for now. We should fix them but there is nothing that cannot be postponed here. We will continue fixing them in background. The only exception here should be bugs related

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

Hi, Just a small note, we shouldn't remove it completely from Nailgun codebase, because we still have old environments to support, we should remove it from newest releases only. Thanks, On Thu, Oct 1, 2015 at 1:10 AM, Mike Scherbakov wrote: > Hi team, > where do we

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

Hi Mike, thanks, now it's clear. On Thu, Sep 3, 2015 at 9:19 AM, Mike Scherbakov wrote: > Thank you all for the feedback. > > > Dims - > > > 1) I'd advise to codify a proposal in fuel-specs under a 'policy' > directory > > I think it's great idea and I'll do it. > > >

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

will definitely affect quality. So the suggestion is to collect metrics *only* to prove that some improvement in the process helped or didn't help. On Thu, Aug 27, 2015 at 5:58 PM, Evgeniy L e...@mirantis.com wrote: Hi Mike, I have several comments. SLA should be the driver of doing timely reviews

Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues

Hi Mike, I have several comments. SLA should be the driver of doing timely reviews, however we can’t allow to fast-track code into master suffering quality of review ... As for me the idea of SLA contradicts to qualitative reviews. Another thing is I got a bit confused by the difference

Re: [openstack-dev] [Fuel] SSL keys saving

mechanisms already in place, of course there is no overhead. Regards, A. On Fri, Aug 21, 2015 at 12:43 PM, Evgeniy L e...@mirantis.com wrote: Hi Adam, I'm not sure if understand you correctly, what do you mean by overhead for certificate provisioning? We already have all the mechanisms

Re: [openstack-dev] [Fuel] SSL keys saving

Hi John, I agree, that we didn't have these problems if we used Barbican and looks like it's a good tool for our needs. But since we are in Hard Code Freeze we should fix it somehow without introducing big changes in our current architecture. But it would be a nice to see it as an improvement in

Re: [openstack-dev] [Fuel] SSL keys saving

define REST API for provisioning certificates. I'm rather for simplified approach, consisting of Shell / Puppet scripts for certificate upload/management. Regards, A. On Fri, Aug 21, 2015 at 12:20 PM, Evgeniy L e...@mirantis.com wrote: Hi Stanislaw, I agree that user's certificates

Re: [openstack-dev] [Fuel] SSL keys saving

Hi Stanislaw, I agree that user's certificates mustn't be saved in Nailgun database, in cluster attributes, in this case it can be seen in all the logs, which is terrible security problem, and we already have a place where we keep auto-generated certificates and ssh-keys, and those are copied to

Re: [openstack-dev] [Fuel] SSL for master node API

Hi, +1 to 2nd solution, in this case old environments will work without additional actions. Agents for new environments, CLI and UI will use SSL. But probably for UI we will have to perform redirect on JS level. Thanks, On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin sbogat...@mirantis.com

Re: [openstack-dev] [Fuel][Plugins] Feedback

: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Tuesday, July 28, 2015 11:54 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev

Re: [openstack-dev] [fuel] Fuel plugin as docker containers images

Hi Konstantin, I'm not sure if we track such feature anywhere. But one of the reasons to use containers on the master was to deliver plugin specific containers, so they don't intersect and don't break Fuel master dependencies. Do you have some specific use case for that? Thanks, On Mon, Jul 27,

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

{ and [ as a start if a dict or an array. [3] - Templates are for people who do not care about Jinja/ERB (maybe some familiar with Puppet/Chef), so no confusion. On Tue, Jul 28, 2015 at 10:57 AM, Sergey Vasilenko svasile...@mirantis.com wrote: On Mon, Jul 27, 2015 at 1:10 PM, Evgeniy L e

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

/string/#advanced-templates On Tue, Jul 28, 2015 at 12:25 PM, Sergey Vasilenko svasile...@mirantis.com wrote: On Tue, Jul 28, 2015 at 11:52 AM, Evgeniy L e...@mirantis.com wrote: Hi Alexander, I don't agree with your statements [1] - I just uses % and % to substitute values. It's what

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

Aleksey, here is working version [1]. Evgeniy, do we need to remove jinja before July 30th ? With this issue feature can leave, and it won't have huge user impact. At the same time by design we didn't want to have anything except substitution, hence it's probably as Sergey mentioned is a bug.

Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

, Evgeniy L e...@mirantis.com wrote: So, to summarise, +1 from me, we accept the changes which are required for the feature as feature freeze exceptions: 1. Fuel client changes [1] 2. Validation [2] 3. Change tokens in template language Sebastian, Igor, correct? [1] https

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

wrote: Evgeniy, 3. Change tokens in template language I'm not sure what do you mean here. Could you please clarify? Perhaps I missed something. Thanks, Igor On Mon, Jul 27, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: So, to summarise, +1 from me, we accept the changes which

Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature

cant provide usable feedback from bad data in the template then the feature is useless. I could argue that its a critical UX defect. On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote: Aleksey, Yes, my point is those parts should be also included in the scope of FFE

  1   2   >