Hi Andrew,
I have some comments regarding to you action items
>> 2) Removing simple mode from the ui and tests
>> 3) Removing simple mode support from nailgun (maybe we leave it) and cli
We shouldn't do it, because nailgun should handle both versions of cluster.
What we have to do here is to use
Hi guys, I have to say something about beta releases.
As far as I know our beta release has the same version
5.1 as our final release.
I think this versions should be different, because in case
of some problem it will be much easier to identify what
version we are trying to debug.
Also from the
Hi Lukasz,
Regarding to 'Node agent authorization' do you have some ideas how it could
be done?
For me it looks really complicated, because we don't upgrade agents on
slave nodes and
I'm not sure if we will be able to do it in the nearest future.
Thanks,
On Tue, Sep 9, 2014 at 1:50 PM, Lukasz Ol
Hi,
We definitely need a person who will help with design for the feature.
Here is the list of open questions:
1. UI design for certificates uploading
2. CLI
3. diagnostic snapshot sanitising
4. REST API/DB design
5. background tasks for nailgun (?)
6. do we need separate container to certificat
Hi,
In most cases for plugin developers or fuel users it will be much
easier to just write command which he wants to run on nodes
instead of describing some abstract task which doesn't have
any additional information/logic and looks like unnecessary complexity.
But for complicated cases user will
Hi Andrew,
Comments inline.
Also could you please provide a link on OpenStack upgrade feature?
It's not clear why do you need it as a plugin and how you are going
to deliver this feature.
On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward wrote:
> So as part of the pumphouse integration, I've sta
Hi Dmitry,
Our current validation implementation is based on jsonschema,
we will figure out how to hack/configure it to provide more human
readable message
Thanks,
On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov wrote:
> That was my fault. I did not expect that timeout parameter is a mandatory
>
On Tue, Nov 25, 2014 at 10:40 AM, Andrew Woodward wrote:
> On Mon, Nov 24, 2014 at 4:40 AM, Evgeniy L wrote:
> > Hi Andrew,
> >
> > Comments inline.
> > Also could you please provide a link on OpenStack upgrade feature?
> > It's not clear why do you nee
Hi Dmitry,
I totally agree that the current approach won't work (and doesn't work
well).
I have several comments:
>> Each task will provide estimated time
1. Each task has timeout, lets use it as an estimate, I don't think
that we should ask to provide both of this fields, execution
est
Hi Vitaly,
I agree with you that conditions can be useful in case of complicated
plugins, but
at the same time in case of simple cases it adds a huge amount of
complexity.
I would like to avoid forcing user to know about any conditions if he wants
to add several text fields on the UI.
I have seve
Evgeniy,
>
> Responses inline:
>
> 2014-11-28 18:31 GMT+03:00 Evgeniy L :
>
>> Hi Vitaly,
>>
>> I agree with you that conditions can be useful in case of complicated
>> plugins, but
>> at the same time in case of simple cases it adds a huge amount of
>
Hi,
First let me describe what our plans for the nearest release. We want to
deliver
role as a simple plugin, it means that plugin developer can define his own
role
with yaml and also it should work fine with our current approach when user
can
define several fields on the settings tab.
Also I wou
On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh
wrote:
>
>
> 2014-12-10 16:57 GMT+03:00 Evgeniy L :
>
>> Hi,
>>
>> First let me describe what our plans for the nearest release. We want to
>> deliver
>> role as a simple plugin, it means that plugin de
other reason for that is plugins multiversioning,
we must know exactly which plugin with which version
is used for environment, and I don't see how "conditions" can help
us with it.
Thanks,
>
>>
>>
On Wed, Dec 10, 2014 at 8:23 PM, Vitaly Kramskikh
wrote:
>
>
Vitaly, what do you think about that?
On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L wrote:
>
> Hi,
>
> I don't agree with many of your statements but, I would like to
> continue discussion about really important topic i.e. UI flow, my
> suggestion was to add groups, for
Hi,
Recently we've discussed what plugins should look like from user point of
view [1].
On one of the meeting it was decided to have the next flow:
1. user installs fuel plugin (as usually with `fuel plugins install
fuel-plugin-name-1.0.0.fp`)
2. after that plugin can be seen on Plugins page, the
Hi,
Agree with Igor, I think we cannot just drop compatibility for fuel client
with 2.6 python, the reason is we have old master nodes which have
2.6 python, and the newer fuel client should work fine on these
environments.
Or we can try to install python 2.7 on the master during the upgrade.
As
he host system, not
into the container, hence in case if something goes wrong we cannot
make automatic rollback.
Thanks,
On Mon, Jan 12, 2015 at 8:24 PM, Dmitry Borodaenko wrote:
> On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L wrote:
> > Agree with Igor, I think we cannot just drop compatibilit
Hi,
Empty role is ready [1], thanks to granular deployment feature
I didn't have to hardcode some hacks in Astute again.
But there are several things which I want to mention/discuss:
1. in the patch you can see the name of the role and its description
I would like to ask you to verify it and
]
> https://review.openstack.org/#/c/147230/2/nailgun/nailgun/orchestrator/graph_configuration.py
> [2] https://review.openstack.org/#/c/137301/
>
> On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin wrote:
> > Answers inline.
> >
> > On Thu, Jan 15, 2015 at 1:21 AM, Evgen
umes on the same disk with Ceph's volumes. So I don't
see
how it can help here.
On Thu, Jan 15, 2015 at 11:47 PM, Andrew Woodward wrote:
> On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin wrote:
> > Answers inline.
> >
> > On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L
Hi,
1) +1 for warning
2) I don't think that we should delete tasks, it's a history which can be
useful,
for example for stats feature, also it's useful for debugging, but each task
should have created_at and updated_at fields, and from api you will be able
to get the latest tasks for specific env
Hi Dmitry,
We have plans to implement role as a plugin [1], but it
was decided to reduce the scope for 6.1 release and
the feature was postponed.
As a workaround you can use pre deployment hook
to perform some actions before any node is deployed.
Thanks,
[1] https://blueprints.launchpad.net/fue
Hi Dmitry,
The problem with merging is usually it's not clear how system performs
merging.
For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
3}]}, and I want
{'list': [{'k': 4}]} to be merged, what system should do? Replace the list
or add {'k': 4}?
Both cases should be covere
Hi Mike,
All of the items look nice. I have a small comment regarding to the docs.
I don't think that we should force plugin developer to write the docs in
Sphinx compatible format, I vote for Github compatible docs format,
and in case if we want to show this information somewhere else,
we can use
+1
On Fri, Jan 23, 2015 at 7:45 PM, Igor Kalnitsky
wrote:
> +1, no objections from my side.
>
> On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko
> wrote:
> > Hi folks!
> >
> > After moving python-fuelclient to its own repo some of you started
> asking a good question which is How do we mana
Hi,
I agree that this information is useless, but it's not really clear what
you are going
to show instead, will you completely remove the information about nodes for
deployment?
I think the list of nodes for deployment (without detailed list of changes)
can be useful
for the user.
Thanks,
On Mo
To be more specific, +1 for removing this information from UI, not from
backend.
On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L wrote:
> Hi,
>
> I agree that this information is useless, but it's not really clear what
> you are going
> to show instead, will you completely re
Hi,
As far as I remember we wanted to replace Astute with Mistral [1], do we
really want to have some intermediate steps (I mean salt) to do it?
[1] https://wiki.openstack.org/wiki/Mistral
On Wed, Jun 11, 2014 at 10:38 AM, Dmitriy Shulyak
wrote:
> Yes, in my opinion salt can completely replac
Hi,
In case of OpenStack patching you don't need to create any symlinks and
mount new directories, you can just create new subdirectory in
/var/www/nailgun with specific version of openstack, like /var/www/nailgun/
5.0.1. And then use it as a repository path for new OpenStack releases.
On Mon, J
Hi,
We had a meeting today about plugins on UI, as result of the meeting
we have two approaches and this approaches affect not only UX but
plugins itself.
*1st - disable/enable plugin on settings tab*
1. user installs the plugin
2. creates a cluster
3. configures and enables/disables pl
this way right now.
>
> Also, we should not forget about CLI.
> I can easily imagine how operator downloads cluster config (big cluster
> attributes file) and modifies it accordingly to turn on specific plugins.
> How we will manage plugins from cli if plugins will be managed from
> w
Hi,
I'm not sure if we should add the new state in this case, it looks like you
can get this
information dynamically, you already have the state of env which tells you
that
there are new ceph nodes, and there are no ready ceph nodes in the cluster
hence you should install ceph-mon on the controlle
, for API it's just one PUT) is MUCH simpler and much more
>> >> obvious, as I see.
>> >>
>> >>
>> >>
>> >> On Wed, Oct 8, 2014 at 8:34 AM, Vitaly Kramskikh
>> >> wrote:
>> >> > Hi,
>> >
s).
>>
>> Just my $2,
>> -DmitryB
>>
>> On Wed, Oct 8, 2014 at 9:18 AM, Nikolay Markov
>> wrote:
>> > Vitaly,
>> >
>> > Once again, as a plugin developer I don't care about how Sahara or
>> Murano is
>> > implemented. I
+1
On Fri, Oct 10, 2014 at 6:09 PM, Aleksandr Didenko
wrote:
> +1 for both.
>
> On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky
> wrote:
>
>> +1.
>>
>> On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin
>> wrote:
>> > Hi, Fuelers
>> >
>> > As you may have noticed our project is growing continuo
Hi everyone!
I would like to propose Igor Kalnitsky as a core reviewer on the
Fuel-web team. Igor has been working on openstack patching,
nailgun, fuel upgrade and provided a lot of good reviews [1]. In
addition he's also very active in IRC and mailing list.
Can the other core team members please
t; for example, so for different releases different plugins could be available.
>>
>> And please confirm that you also agree with the flow: the user install a
>> plugin, then he enables it on the plugin management page, and then he
>> creates an environment and on the fir
ow we plan to evolve it.
>
> Please confirm that we went this path.
>
> Thanks,
>
>
> On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L wrote:
>
>> Hi,
>>
>> We've discussed what we will be able to do for the current release and
>> what we will not be ab
s if an error occurs during plugin execution? Does it
>> (should it?) fail the deployment? Will we show user an error message
>> with
>> the name of plugin that failed?
>> 5. Shall we consider a separate place in UI (tab) for plugins?
>>
, I think we should not force it and
>> leave this decision to a plugin developer, so he can create just a single
>> checkbox or a section of the settings tab or a separate tab depending on
>> plugin functionality. Plugins should be able to modify arbitrary release
>> fields. For e
Hi Dmitry,
Thank you for being beta tester and for your feedback :)
On Wed, Oct 29, 2014 at 11:05 AM, Dmitry Ukov wrote:
> All,
> Recently I have tried plugins feature which was implemented for 6.x
> release. And that was really pleasant experience. Plugins work almost
> out-of-the box. I was a
Hi Dmitry,
Thank you for bringing it up, it's not only about CI, it really takes
a lot of developers time to run Nailgun unit/integration tests on local
machine, and it's must have priority task in technical debt scope.
Personally I'm ok with py.test, but we should improve db creation mechanism
i
Hi,
>> There was an idea to make a separate code freeze for repos
Could you please clarify what do you mean?
I think we should have a way to merge patches for the next
release event if it's code freeze for the current.
Thanks,
On Tue, Nov 11, 2014 at 2:16 PM, Vitaly Kramskikh
wrote:
> Folks,
Hi Sergii,
Sorry, but I don't like the idea of creating yet another type of iso, it
will complicate debugging process (because of different environments).
Disable authentication - if we have a feature, we should not disable it,
during the development we need to make sure that this feature works f
Hi,
I want to discuss here several bugs
1. Do we want to upgrade (deliver new packages) for netchecker and
mcagents? [1]
If yes, then we have to add a list of packages which are
installed on provisioning stage (e.g. netchecker/mcagent/something else)
in puppet, to run patching for this packages.
Hi,
I have several concerns about password changing.
>> Default password can be changed via UI or via fuel-cli. In case of
changing password via UI or fuel-cli password is not stored in any file
only in keystone
It's important to change password in /etc/fuel/astute.yaml
otherwise it will be impo
>> what do you think on this? Is someone addressing the issues mentioned by
>> Evgeny?
>>
>> Thanks,
>>
>>
>> On Fri, Jul 25, 2014 at 3:31 PM, Evgeniy L wrote:
>>
>>> Hi,
>>>
>>> I have several concerns about password changing.
&g
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 p
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
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 v
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
keys
--
> Javeria
>
> On Fri, Nov 6, 2015 at 1:41 PM, Evgeniy L wrote:
>
>> 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/as
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 run
inside the 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
+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
> > wrote:
>
>> Dear colleagues,
>>
>> I am
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? F
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 Kalnitsk
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* gate
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 an
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
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
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
Nailgun/Astut
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 sess
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
c.
> >
> > BTW, about a year ago (in Grenoble) we agreed that it is not even
> > 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
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
lks,
>
> 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
>
> # python-fuelclient [2]
&g
+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 well as against functio
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 support
> so the corres
+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.
>>>
>>>
>>> Aleksey Kasatkin
>>>
>>>
>>> On Mon, Dec 14, 2015 at 12:49 PM, Vladimi
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 w
+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 disc
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 data
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
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 somethin
nvironments. 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 holidays are Jan 1st-10th and you (wh
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
lementation
>
> 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 wrote:
> > Hi,
> >
> > Some time
rate 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, 2015 at 4:
gt; 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,
> Oleg Gelbuk
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
om> wrote:
>
>> 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.
>>
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 practi
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] http
sd and hdd
>
>
> Best regards,
> Svechnikov Artur
>
> On Tue, Jan 12, 2016 at 9:37 PM, Evgeniy L wrote:
>
>> Hi,
>>
>> For the last several weeks I've been working on algorithm (and prototype)
>> for dynamic allocation of volumes on disks.
>>
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 wrote:
> Hi Artur,
>
> You are correct, w
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
Evgeniy.
>
> On Fri, Feb 5, 2016 at 11:07 AM, Evgeniy L 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 required nodes
>> using fuel cli,
+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].
>
> Fuel Cores, please reply
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 sol
+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:
>
>> +1.
>>
>> Regards,
>>
Hi,
As an author of this part of pluggable architecture I can shade more light
on why it was implemented this way and why it's valuable to continue
supporting multi-release feature.
At the time it was implemented Fuel officially was supporting both Ubuntu
and CentOS, in order to simplify plugins
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 wrote:
> Hi,
>
> As an author of this part of pluggable architecture I can shade more light
> on why it was implemented this way and why it's valuable to
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 multi
Hi Sergiy,
Currently it's not possible to use generators in environment_config file,
the reason for this is generators get unwrapped before we add plugin's
attributes [1]. Could you please create a bug for fuel-python team, we'll
address this issue.
Thanks,
[1]
https://github.com/stackforge/fuel
+1 for enabling auto-abandon
Sergii, I think the period should be smaller, 2 weeks - 1 month,
if patch is important, the author will unabandon it.
Thanks,
On Wed, Jul 8, 2015 at 3:50 AM, Sergii Golovatiuk
wrote:
> 3 Months should be a good period. Sometimes, people have one month
> vacation th
Hi,
Agree, most of the python developers are familiar with Astute.
But at the same time it can look strange when we assign Astute (which is
written in Ruby)
bugs to the group which is called fuel-python :)
Thanks,
On Thu, Jul 16, 2015 at 2:21 PM, Alexander Kislitsky <
akislit...@mirantis.com> wr
Hi Steven, thank you for letting us know about your use case,
The problem is caused because since 6.1 release we run
part of network verification tasks before deployment [1], from
the code it can be seen, that this check is hardcoded [2], before
we send any deployment tasks, so we should figure ou
Hi,
The best option is to add new functionality to fuel2 only, but I
don't think that we can do that if there is not enough functionality
in fuel2, we should not ask user to switch between fuel and fuel2
to get some specific functionality.
Do we have some list of commands which is not covered in f
1 - 100 of 195 matches
Mail list logo
