Fuel team,
Can someone please review the issues Rohan is having and provide
answers/suggestions to help him complete his plugin?
Thanks,
Sheena
*From:* Rohan PARULEKAR [mailto:rohan.s.parule...@nuagenetworks.net]
*Sent:* Thursday, January 28, 2016 4:35 AM
*To:* Sheena Gregson <sg
If there is a new requirement for plugin developers, I would also make sure
it is documented here: https://wiki.openstack.org/wiki/Fuel/Plugins
*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Wednesday, January 20, 2016 10:59 AM
*To:* OpenStack Development Mailing List (not
com>
wrote:
> Roman, Sheena,
>
> You meant to remove nova-network completely? Or only for new
> environments? Should we support nova-network for old (let's say, 7.0)
> clusters?
>
> Thanks,
> Igor
>
> On Fri, Jan 15, 2016 at 10:03 PM, Sheena Gregson <sgreg...@
Although we are very close to HCF, I see no option but to continue removing
nova-network as I understand it is not currently functional or well-tested
for the Mitaka release. We must either remove it or test it, and we want
to remove it anyway so that seems like the better path.
*Mike*, what
I’ve also seen the request multiple times to be able to provide more
targeted snapshots which might also (partially) solve this problem as it
would require significantly less disk space to grab logs from a subset of
nodes for a specific window of time, instead of the more robust grab-all
solution
Since we are now
recommending DVS or NSX backends, I'd like the team to explicitly confirm
that those configurations have been tested.
Thanks,
Roman
On Fri, Jan 15, 2016 at 6:43 AM, Sheena Gregson <sgreg...@mirantis.com>
wrote:
Although we are very close to HCF, I see no option but
debt.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson <sgreg...@mirantis.com>
>> wrote:
>>>
>>> Hey guys –
>>>
>>>
it as Critical.
Let’s start the conversation on here and make sure all the bases are
covered – if additional bugs need to be logged or there’s administrative
overhead, let me know and I’ll be happy to help out!
Sheena Gregson | Sr. Product Manager | Mirantis <http://www.mirantis.com/>
We should collapse this into one entry - I don't have any preference on
the naming convention, but as Fuel checks to see whether the hardware is
capable of performing KVM acceleration, there's no reason to continue
giving a selection to the user regarding KVM.
Today, when a user selects KVM, Fuel
dea and believe this is the way to
go. In this case the hypervisor entry could be called something like
"Qemu (+ KVM if available)".
On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:
> We should collapse this into one entry - I don't have any pre
ke "Qemu (+ KVM if available)".
On Mon, Dec 21, 2015 at 4:04 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:
> We should collapse this into one entry - I don't have any preference on
> the naming convention, but as Fuel checks to see whether the hardware is
> capabl
Is the meeting at 8am PST today?
*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]
*Sent:* Wednesday, December 02, 2015 1:57 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Feature Freeze is
This seems like a totally reasonable solution, and would enable us to more
thoroughly test the performance implications of this change between 8.0
and 9.0 release.
+1
-Original Message-
From: Davanum Srinivas [mailto:dava...@gmail.com]
Sent: Wednesday, December 02, 2015 9:32 AM
To:
orking state.
Aleksey Kasatkin
On Fri, Oct 23, 2015 at 3:42 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:
As a reminder: there are no individual networking options that can be used
with both vCenter and KVM/QEMU hypervisors once we deprecate nova-network.
The code for vCenter as a stan
This seems like a reasonable approach. As mentioned earlier in the thread,
our current framework allows plugins to declare which components they could
not work with, so we already have information about “incompatibility” for a
number of plugins. The issue with this approach is that, as new
As a reminder: there are no individual networking options that can be used
with both vCenter and KVM/QEMU hypervisors once we deprecate nova-network.
The code for vCenter as a stand-alone deployment may be there, but the code
for the component registry (
Plans for multi-DC: my understanding is that we are working on developing a
whitepaper in Q4 that will provide a possible OpenStack multi-DC
configuration, but I do not know whether or not we intend to include Fuel
in the scope of this work (my guess would be no). Chris – I copied you in
case you
Forwarding since Chris isn’t subscribed.
*From:* Chris Clason [mailto:ccla...@mirantis.com]
*Sent:* Friday, October 02, 2015 6:30 PM
*To:* Sheena Gregson <sgreg...@mirantis.com>; OpenStack Development Mailing
List (not for usage questions) <openstack-dev@lists.openstack.org>
*
2015 at 5:17 PM, Sheena Gregson <sgreg...@mirantis.com>
wrote:
I like that idea a lot – I also think there would be value in adding
pre-deployment sanity checks that could be called from the Health Check
screen prior to deployment. Thoughts?
*From:* Simon Pasquier [mailto:spasqu...@miranti
+1 Thanks for being a great docs contributor and community member.
*From:* Alexander Adamov [mailto:aada...@mirantis.com]
*Sent:* Monday, September 14, 2015 5:44 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Cc:* Olga Gusarenko
We could certainly use the pre-existing Barbican capabilities, which would
provide a reasonably easy and clean interface for key storage. However,
this does not afford much (if any) additional security without the
introduction of a Hardware Security Module as the Barbican back-end, and
I’m not
I like that idea a lot – I also think there would be value in adding
pre-deployment sanity checks that could be called from the Health Check
screen prior to deployment. Thoughts?
*From:* Simon Pasquier [mailto:spasqu...@mirantis.com]
*Sent:* Monday, August 10, 2015 9:00 AM
*To:* OpenStack
+1 to #2
*From:* Vladimir Kuklin [mailto:vkuk...@mirantis.com]
*Sent:* Tuesday, August 04, 2015 6:25 AM
*To:* OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
*Subject:* Re: [openstack-dev] [Fuel] SSL for master node API
I am for 2nd option for
correction: I'm not a core in fuel-plugins ;)
[1] https://bugs.launchpad.net/fuel/+bug/1479785
On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com
wrote:
Evgeniy –
For the items which you have listed actions, who should be responsible for
next steps?
Sheena
*From
into the repository,
Sebastian, Igor and I.
One correction: I'm not a core in fuel-plugins ;)
[1] https://bugs.launchpad.net/fuel/+bug/1479785
On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson
sgreg...@mirantis.com
wrote:
Evgeniy –
For the items which you have listed actions, who should
-builder 2.0.3
fuel-plugin-builder 2.0.2
fuel-plugin-builder 2.0.1
fuel-plugin-builder 2.0.0
fuel-plugin-builder 1.0.2
fuel-plugin-builder 1.0.1
I can push tags for them.
Thanks,
Igor
[1] https://bugs.launchpad.net/fuel/+bug/1479785
On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson
We restricted this because allowing nova-network to be used as an underlay
for all possible combinations added QA time and effort to supporting a soon
to be deprecated option.
As nova-network is being deprecated upstream and will relatedly be
deprecated in Fuel – AFAIK, there is a goal to
, 2015 at 11:02 AM Sheena Gregson sgreg...@mirantis.com
wrote:
We restricted this because allowing nova-network to be used as an underlay
for all possible combinations added QA time and effort to supporting a soon
to be deprecated option.
As nova-network is being deprecated upstream
Gregson sgreg...@mirantis.com
*Subject:* RE: [openstack-dev] [Fuel][Plugins] Feedback
On 29 Jul 2015 at 14:41:48, Sheena Gregson (sgreg...@mirantis.com) wrote:
Hey Sergii –
I don’t know if I agree with the statement that it’s bad practice to mix
core and plugin functionality. From a user
#golserge
IRC #holser
On Tue, Jul 28, 2015 at 6:25 PM, Sheena Gregson sgreg...@mirantis.com
wrote:
Hey Sergii –
This is excellent feedback, thank you for taking the time to provide your
thoughts.
#1 I agree that the documentation lag is challenging – I’m not sure how to
best address this. We
Hey Sergii –
This is excellent feedback, thank you for taking the time to provide your
thoughts.
#1 I agree that the documentation lag is challenging – I’m not sure how to
best address this. We could potentially prioritize updates to the Plugin
SDK for soon-to-be-released features ahead of
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)
Patrick –
Are you suggesting one project for all Fuel plugins, or individual projects
for each plugin? I believe it is the former, which I prefer – but I wanted
to check.
Sheena
*From:* Patrick Petit [mailto:ppe...@mirantis.com]
*Sent:* Saturday, July 25, 2015 12:25 PM
*To:* Igor
That's my fault, I asked him to send it as I thought it also required
review for FFE.
On Jul 23, 2015 1:45 PM, Mike Scherbakov mscherba...@mirantis.com wrote:
Alexander,
as this is purely Fuel related thing, please send a new one with right
subject. It has to be [fuel] in subject, and that's
:12 AM
*To:* Stanislaw Bogatkin; Sheena Gregson
*Cc:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [Fuel] SSL feature status
Thanks Stas. My opinion is that it has to be enabled by default. I'd like
product management to shine in here. Sheena?
On Tue, Jul 21
35 matches
Mail list logo
