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
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
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
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,
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
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
by
Evgeny?
Thanks,
On Fri, Jul 25, 2014 at 3:31 PM, Evgeniy L e...@mirantis.com wrote:
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
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 dshul...@mirantis.com
wrote:
Yes, in my opinion salt
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
attributes file) and modifies it accordingly to turn on specific plugins.
How we will manage plugins from cli if plugins will be managed from
wizard?
On Tue, Oct 7, 2014 at 5:17 PM, Evgeniy L e...@mirantis.com wrote:
Hi,
We had a meeting today about plugins on UI, as result of the meeting
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
Ceph nodes.
2014-10-07 21:17 GMT+07:00 Evgeniy L e...@mirantis.com:
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
that
it'll be executed.
How will it work with your approach?
08 Окт 2014 г. 20:00 пользователь Vitaly Kramskikh
vkramsk...@mirantis.com написал:
Hi, responses inline.
2014-10-08 21:09 GMT+07:00 Evgeniy L e...@mirantis.com:
Hi,
Vitaly, I understand your concerns about UX
+1
On Fri, Oct 10, 2014 at 6:09 PM, Aleksandr Didenko adide...@mirantis.com
wrote:
+1 for both.
On Fri, Oct 10, 2014 at 5:01 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1.
On Fri, Oct 10, 2014 at 12:35 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
Hi, Fuelers
As you may
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
an environment and on the first step he can uncheck some plugins
which he doesn't want to use in that particular environment.
2014-10-09 20:11 GMT+07:00 Evgeniy L e...@mirantis.com:
Hi,
Vitaly, I like the idea of having separate page, but I'm not sure if it
should be on releases page.
Usually
it.
Please confirm that we went this path.
Thanks,
On Mon, Oct 13, 2014 at 7:31 PM, Evgeniy L e...@mirantis.com wrote:
Hi,
We've discussed what we will be able to do for the current release and
what we will not be able to implement.
We have not only technical problems, but also we don't
17, 2014 at 9:32 AM, Mike Scherbakov
mscherba...@mirantis.com wrote:
Thanks, Evgeny, excellent work!
Roman, I believe we are green with the feature. Watch yourself.
Mike Scherbakov
#mihgen
On Oct 17, 2014 8:25 PM, Evgeniy L e...@mirantis.com wrote:
Hi guys, here are the videos from
was a plugin, it should be able to extend
wizard config to add new options to Storage pane. If vCenter was a plugin,
it should be able to set maximum amount of Compute nodes to 0.
2014-10-20 21:21 GMT+07:00 Evgeniy L e...@mirantis.com:
Hi guys,
*Romans' questions:*
I feel like we should
Hi Dmitry,
Thank you for being beta tester and for your feedback :)
On Wed, Oct 29, 2014 at 11:05 AM, Dmitry Ukov du...@mirantis.com wrote:
All,
Recently I have tried plugins feature which was implemented for 6.x
release. And that was really pleasant experience. Plugins work almost
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
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
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 xar...@gmail.com wrote:
So as part of the pumphouse
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 du...@mirantis.com wrote:
That was my fault. I did not expect that timeout parameter
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
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
On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:
2014-12-10 16:57 GMT+03:00 Evgeniy L e...@mirantis.com:
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
Evgeniy L e...@mirantis.com:
On Wed, Dec 10, 2014 at 6:50 PM, Vitaly Kramskikh
vkramsk...@mirantis.com wrote:
2014-12-10 16:57 GMT+03:00 Evgeniy L e...@mirantis.com:
Hi,
First let me describe what our plans for the nearest release. We want
to deliver
role as a simple plugin, it means
Vitaly, what do you think about that?
On Fri, Dec 12, 2014 at 5:58 PM, Evgeniy L e...@mirantis.com 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 plugin
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,
+1
On Fri, Jan 23, 2015 at 7:45 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1, no objections from my side.
On Fri, Jan 23, 2015 at 6:04 PM, Roman Prykhodchenko m...@romcheg.me
wrote:
Hi folks!
After moving python-fuelclient to its own repo some of you started
asking a good
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
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 e...@mirantis.com 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 remove
Hi Dmitry,
I've read about inventories and I'm not sure if it's what we really need,
inventory provides you a way to have some kind of nodes discovery
mechanism, but what we need is to get some abstract data and convert
the data to more tasks friendly format.
In another thread I've mentioned
be done on a merged spec.
On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com wrote:
Hi,
+1 to Dmitriy's comment.
We can spend several month on polishing the spec, will it help
to release feature in time? I don't think so.
Also with your suggestion we'll get a lot of patches over 2
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
:21 AM, Evgeniy L e...@mirantis.com wrote:
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
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 xar...@gmail.com wrote:
On Thu, Jan 15, 2015 at 3:11 AM, Andrey Danin ada...@mirantis.com wrote:
Answers inline.
On Thu, Jan 15, 2015 at 1:21 AM, Evgeniy L e...@mirantis.com
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
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]
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
Hi Przemyslaw,
Thanks for bringing up the topic. A long time ago we had similar topic,
I agree that the way it works now is not good at all, because it leads to
a lot of problems, I remember the time when our tests were randomly
broken because of deadlocks and race conditions with fake thread.
+1 to extract validators for granular deployment tasks
Dmitry, do you mean that we should create some cli to generate graph
picture? Or just make it as a module and then use it in Nailgun?
Thanks,
On Tue, Feb 17, 2015 at 4:31 PM, Dmitriy Shulyak dshul...@mirantis.com
wrote:
+1 for separate
that way.
Also, how are the astute tasks read into the environment? Same as with
the others?
fuel rel --sync-deployment-tasks
On Fri, Feb 13, 2015 at 7:32 AM, Evgeniy L e...@mirantis.com wrote:
Andrew,
It looks like what you've described is already done for ssh keys [1].
[1] https
Hi,
Since fuel plugins are going to be moved [1] from fuel-plugins repository
[2],
the only project which will be there is fuel plugin builder and plugins
examples
which are related to fuel plugin builder testing.
Currently fuel plugin builder has its own release cycle, but we don't have
tags
Hi Andrey,
I agree that it's useful to know compatibility between releases and
previous versions
of plugins, but I'm not 100% sure that tag comments is the best place to
keep such
information, does it make sense to use Changelog.txt file for such
information instead?
Regarding to versioning
Hi,
+1 for having primary-controller role in terms of deployment.
In our tasks user should be able to run specific task on primary-controller.
But I agree that it can be tricky because after the cluster is deployed, we
cannot say who is really primary, is there a case when it's important to
know
sources of information and retrieve data in the
way this task wants it instead of adjusting the task to the only
'astute.yaml'.
On Thu, Jan 22, 2015 at 8:59 PM, Evgeniy L e...@mirantis.com wrote:
Hi Dmitry,
The problem with merging is usually it's not clear how system performs
merging
Hi Dmitry,
I'm not sure if we should user approach when task executor reads
some data from the file system, ideally Nailgun should push
all of the required data to Astute.
But it can be tricky to implement, so I vote for 2nd approach.
Thanks,
On Wed, Jan 28, 2015 at 7:08 PM, Aleksandr Didenko
Dmitry,
But why to add another interface when there is one already (rest api)?
I'm ok if we decide to use REST API, but of course there is a problem which
we should solve, like versioning, which is much harder to support, than
versioning
in core-serializers. Also do you have any ideas how it
wrote:
Thank you guys for quick response.
Than, if there is no better option we will follow with second approach.
On Wed, Jan 28, 2015 at 7:08 PM, Evgeniy L e...@mirantis.com wrote:
Hi Dmitry,
I'm not sure if we should user approach when task executor reads
some data from the file system
AM, Andrew Woodward xar...@gmail.com wrote:
On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L e...@mirantis.com wrote:
Hi,
+1 for having primary-controller role in terms of deployment.
Yes, we need to continue to be able to differentiate the difference
between the first node in a set of roles
Hi,
+1 to Dmitriy's comment.
We can spend several month on polishing the spec, will it help
to release feature in time? I don't think so.
Also with your suggestion we'll get a lot of patches over 2 thousands
lines of code, after spec is merged. Huge patches reduce quality,
because it's too hard
. Then all this data is aggregated and transformed somehow.
After that it is shipped to the deployment layer. That's how I see it.
On Thu, Jan 29, 2015 at 2:18 PM, Evgeniy L e...@mirantis.com wrote:
Vladimir,
It's no clear how it's going to help. You can generate keys with one
tasks
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
Hi Dmitry!
1. as I mentioned above, we should have an interface, and if interface
doesn't
provide required information, you will have to fix it in two places,
in Nailgun and in external-serializers, instead of a single place i.e.
in Nailgun,
another thing if astute.yaml is a bad
in case if something goes wrong we cannot
make automatic rollback.
Thanks,
On Mon, Jan 12, 2015 at 8:24 PM, Dmitry Borodaenko dborodae...@mirantis.com
wrote:
On Mon, Jan 12, 2015 at 9:10 AM, Evgeniy L e...@mirantis.com wrote:
Agree with Igor, I think we cannot just drop compatibility for fuel
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.
, 2015 at 2:07 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
Evgeniy,
I am not suggesting to go to Nailgun DB directly. There obviously should
be some layer between a serializier and DB.
On Thu, Jan 29, 2015 at 9:07 PM, Evgeniy L e...@mirantis.com wrote:
Vladimir,
1) Nailgun DB
Just
Hi,
Recently we've had discussions in the ML [1] and on weekly IRC
meeting [2] about specs and whether they should be merged before
or after the patches for feature get merged.
Lets continue the discussion in this thread.
[1]
+1, because those patches are simple don't look destructive.
On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko m...@romcheg.me wrote:
Hi folks,
due to some technical issues we were unable to merge Cliff integration
patches to keep ISO build jobs alive.
Since now the problem is fixed and
Hi folks,
I agree, lets create separate repo with its own cores and remove
fuel_development from fuel-web.
But in this case I'm not sure if we should merge the patch which
has links to non-stackforge repositories, because location is going
to be changed soon.
Also it will be cool to publish it
+1 from me
On Wed, Mar 25, 2015 at 12:35 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
+1
On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo ca...@mirantis.com
wrote:
+1 from me, this is a great suggestion.
-Christopher
On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko
Hi Andrey,
I don't have enough details to make some conclusions, but if the
problem can be solved with some python script which gets the data
and converts it into more readable format, lets do it this way.
Thanks,
On Wed, Feb 25, 2015 at 10:59 PM, Andrey Danin ada...@mirantis.com wrote:
Hi,
Hi Emma,
If you don't need additional elements on UI, just create
environment_config.yaml with
{} value for attributes key, i.e. attributes: {}
Thanks,
On Fri, Apr 24, 2015 at 6:03 PM, Emma Gordon (projectcalico.org)
e...@projectcalico.org wrote:
The fuel plugin wiki
+1
On Tue, May 5, 2015 at 12:55 PM, Sebastian Kalinowski
skalinow...@mirantis.com wrote:
+1
2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com:
+1, indeed Julia's reviews are very thorough.
P.
On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
Hi,
I'd like to
1/ +1
2/ +1
3/ +1
On Tue, Apr 14, 2015 at 2:45 PM, Aleksey Kasatkin akasat...@mirantis.com
wrote:
1/ +1
2/ +1
3/ +1
Aleksey Kasatkin
On Tue, Apr 14, 2015 at 12:26 PM, Tatyana Leontovich
tleontov...@mirantis.com wrote:
3/ +1
On Tue, Apr 14, 2015 at 11:49 AM, Sergii Golovatiuk
+1
On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko m...@romcheg.me wrote:
+1. Sebastian does great job in reviews!
10 квіт. 2015 о 12:05 Igor Kalnitsky ikalnit...@mirantis.com
написав(ла):
Hi Fuelers,
I'd like to nominate Sebastian Kalinowski for the both fuel-web-core
[1]
+1
On Mon, Apr 13, 2015 at 1:37 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:
+1
On Mon, Apr 13, 2015 at 11:37 AM, Alexander Kislitsky
akislit...@mirantis.com wrote:
Andrew shows great attention to the details. +1 for him.
On Mon, Apr 13, 2015 at 11:22 AM, Anastasia Urlapova
Hi Samuel,
Currently it's not possible to change partitioning schema of Fuel roles,
but you can change partitioning in post_deployment tasks of your plugin.
Thanks,
On Wed, May 27, 2015 at 9:38 AM, Samuel Bartel samuel.bartel@gmail.com
wrote:
Hi folks
In some plugin such as the nfs for
+1
On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:
+1. Alex's doing a great job!
On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
svasile...@mirantis.com wrote:
+1
__
OpenStack
Hi,
Currently it's not possible to configure your service before image is
uploaded,
because for pre deployment stage it's too early, and for post deployment
stage
it's too late. As a workaround I can suggest uploading TestVM image once
more
after new backend gets configured.
On Wed, Jul 1, 2015
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
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
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
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
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,
{ 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
/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
:
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
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
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.
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
, 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
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
Hi,
Since the feature is essential, and changes are small, we can accept it as
a,
feature freeze exceptions.
But as far as I know there is a very important ticket [1] which was created
in
order to get patches merged faster, also I still have concerns regarding to
ERB style template % if3 % which
to finish
this work and additional resources required.
We need to switch to bugfix work, and the more we continue working on
features / enhancements, the less confidence I have that we can meet HCF
deadline.
Thanks,
On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote:
Hi
.
Thanks,
Igor
[1]: https://bugs.launchpad.net/fuel/+bug/1476779
On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote:
Hi,
Since the feature is essential, and changes are small, we can accept it
as
a,
feature freeze exceptions.
But as far as I know there is a very
, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote:
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
Hi Andrew,
I don't agree with you, user should be able to name the node any way he
wants why there should be a constraint which is related to some internal id
in Nailgun database? For example if he deleted node-5 and then he wants
to replace this node with another one, he can and should be able
Hi,
I've read the tickets and wondering, how can we remove zabbix completely
from Nailgun/UI? We still have old environments which should be able
to support zabbix, or it is not the case for experimental? In this case we
should
warn the user, that after upgrade he will not be able manage his
not a trivial change, we cannot
leave a new API in such shape.
2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com:
Hi Igor,
I don't agree with you, some basic validation is essential part of
any handler and our API, currently it's easy to get meaningless 500 error
(which is unhandled exception
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
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
Hi,
The patch into Nailgun requires additional work to do, but as far as I can
see
it doesn't affect any other parts of the system, also it's implemented as an
extension, which means if the feature will introduce bugs which we won't
be able to fix in a required time, it can be easily disabled
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
At the moment we have several core reviewers for the fuel-main project.
Roman Vyalov is responsible for merging of infrastructure-related
variables and for the lists of packages.
I am responsible for merges in
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
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
1 - 100 of 187 matches
Mail list logo
