ork with. If we 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 wrote:
>
>> Aleksey,
>>
>> Yes, my point is those parts should be als
;> I agree here with Evgeniy. Even if it's not a trivial change, we cannot
>> leave a new API in such shape.
>>
>> 2015-07-24 11:41 GMT+02:00 Evgeniy L :
>>
>>> Hi Igor,
>>>
>>> I don't agree with you, some basic validation is essential
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 previ
right now - stability.
>
> Thanks,
> Igor
>
> [1]: https://bugs.launchpad.net/fuel/+bug/1476779
>
> On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L wrote:
> > Hi,
> >
> > Since the feature is essential, and changes are small, we can accept it
> as
> >
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 to
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 %>" wh
ike to understand how much it will take 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,
>
&g
coming so it would be nice to have a policy for the time all commands
> will move to new fuel2.
>
>
>>
>> On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L wrote:
>>
>>> Hi,
>>>
>>> The best option is to add new functionality to fuel2 only, but I
>>&
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 with
+1
On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov 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 make system. And I
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
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,
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
+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 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
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
+1
On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky
wrote:
> +1. Alex's doing a great job!
>
> On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko
> wrote:
> > +1
> >
> >
> __
> > OpenStack Development Mailing List (not for us
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
wrote:
> Hi folks
>
> In some plugin such as the nfs for glance or nova and the n
+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 :
>
>> +1, indeed Julia's reviews are very thorough.
>>
>> P.
>>
>> On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote:
>> > Hi,
>> >
>> > I'd like to no
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
> https://wik
1/ +1
2/ +1
3/ +1
On Tue, Apr 14, 2015 at 2:45 PM, Aleksey Kasatkin
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 <
>> s
+1
On Mon, Apr 13, 2015 at 1:37 PM, Vladimir Kuklin
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 <
>> aurlap...@mi
+1
On Fri, Apr 10, 2015 at 1:35 PM, Roman Prykhodchenko wrote:
> +1. Sebastian does great job in reviews!
>
> > 10 квіт. 2015 о 12:05 Igor Kalnitsky
> написав(ла):
> >
> > Hi Fuelers,
> >
> > I'd like to nominate Sebastian Kalinowski for the both fuel-web-core
> > [1] and python-fuelclient-core
+1 from me
On Wed, Mar 25, 2015 at 12:35 PM, Mike Scherbakov
wrote:
> +1
>
> On Wed, Mar 25, 2015 at 12:17 PM, Christopher Aedo
> wrote:
>
>> +1 from me, this is a great suggestion.
>>
>> -Christopher
>>
>> On Wed, Mar 25, 2015 at 12:10 PM, Dmitry Borodaenko
>> wrote:
>> > Fuelers,
>> >
>> > I
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 o
+1, because those patches are simple don't look destructive.
On Mon, Mar 16, 2015 at 7:43 PM, Roman Prykhodchenko 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 we are unbl
Hi,
I would like to announce that we've published a simple guide [1],
which describes how to migrate plugin from old format to new one,
it can be useful for those who develop the plugins on development
version of Fuel (6.1).
Plugins doc is a bit outdated, it will be updated soon.
The biggest cha
Hi,
Some time ago we merged a patch [1] for fuel client which allowed
to install plugins on the host system, it was a bad design decision
because by design fuelclient should work remotely from another
machine, but it was a good decision from UX point and there was
not time to implement it properly
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 wrote:
> Hi, fuelers,
>
> As you
make granular
>> tasks based for this, but we need to move 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, Evg
+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
wrote:
> +1 for separate tasks/graph validation
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.
We
uns_from: master_once
>> provider:
>> push_certs:
>> runs_from: master
>> provider: bash
>> role: [*]
>>
>> On Thu, Jan 29, 2015 at 2:07 PM, Vladimir Kuklin
>> wrote:
>>
>>> Evgeniy,
>>>
>>> I am not suggesting t
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
for
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 itsel
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]
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055528
ection, and impact of a feature. As a side effect, well defined specs
> can also serve as documentation for the feature. While the discussion is
> common on the spec, this should be done on a merged spec.
>
> On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L wrote:
>
>> Hi,
>>
>
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 Vari
t; DNS Servers. 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 wrote:
>
>> Vladimir,
>>
>> It's no clear how it's going to he
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 c
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 wrote:
>>
>>> Hi Dmitry,
>>>
>>> I'm not sure if we should
Jan 29, 2015 at 1:05 AM, Andrew Woodward wrote:
> On Wed, Jan 28, 2015 at 3:06 AM, Evgeniy L 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 th
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 to
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
w
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 interf
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
w
; access database or other 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 wrote:
>
>> Hi Dmitry,
>>
>> The problem with merg
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,
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
+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 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
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 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,
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
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
]
> 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
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
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,
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
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
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
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:
>
>
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
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
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 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
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
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,
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
>
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,
>> 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 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 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
, 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
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?
>>
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
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
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
+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
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
, 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,
>> >
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
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,
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
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,
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 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 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 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
>> 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,
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
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 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,
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,
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
101 - 195 of 195 matches
Mail list logo
