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
*Subject
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 f
, 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
> wrote:
> > Adrian – can som
ed before. 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
wrote:
Although we are very close to HCF, I see no option but to continue remov
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 w
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 do
5 at 3:27 AM, Sergii Golovatiuk
> wrote:
>>
>> Hi,
>>
>> Finally we can deprecate nova-network ...
>> We should remove it from UI, nailgun logic and tests to have less
>> technical debt.
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> S
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/>
se that KVM acceleration is not possible.
Sheena, are you sure it works this way? Some time ago we didn't
support this. However, I fully support this idea and believe this is
the way to go. In this case the hypervisor entry could be called
something like "Qemu (+ KVM if available)".
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
wrote:
> We should collapse this into one entry - I don't have any preference
> on the naming convention, but as Fuel checks
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
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: OpenSt
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
atkin
On Fri, Oct 23, 2015 at 3:42 PM, Sheena Gregson
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 stand-alone deployment may be there, but the code
for th
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 plugin
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 (
https://blueprints.launchpad.net/fuel/+sp
Forwarding since Chris isn’t subscribed.
*From:* Chris Clason [mailto:ccla...@mirantis.com]
*Sent:* Friday, October 02, 2015 6:30 PM
*To:* Sheena Gregson ; OpenStack Development Mailing
List (not for usage questions)
*Subject:* Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC
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
work preparation and extra drivers to be presented
in an image), when a combination of different ML2 plugins or hypervisors
deployed (because you need to test all network underlayers or HVs).
So, all that means we need to make OSTF extendible by Fuel plugin's tests
eventually.
On Mon, Aug 10,
+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
*Subj
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 sur
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 Devel
+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
-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
wrote:
> I woul
Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi Sheena,
Sure, I can do it. Should I push tag only for last release or for all
releases that are available on PyPI?
Thanks,
Igor
On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson
wrote:
> So the o
n: 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
wrote:
Evgeniy –
For the items which you have listed actions, who should be responsible for
next steps?
Sheena
*From:* Evgeniy L [mailto:e...@m
ts on
this then?
On Wed, Jul 29, 2015 at 11:02 AM Sheena Gregson
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
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 deprec
Sheena Gregson
*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 standpoint, if I’m try
gii Golovatiuk,
Skype #golserge
IRC #holser
On Tue, Jul 28, 2015 at 6:25 PM, Sheena Gregson
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.
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@lists.openstack.or
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 t
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 Kalnitsk
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" 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 it. No MOS,
> fuel-li
: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, J
35 matches
Mail list logo
