[openstack-dev] [Fuel] [Plugin] 7.0 compute node re-deployment issue

[Sheena Gregson]

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:* Re: Fuel 7.0 compute node re-deployment issue



Thanks for the help Sheena.



Also, sometimes I see the following error in deployment on the nodes with
"controller" role :



[image: Inline image 1]



Also this occurs intermittently in a scenario wherein I add a controller
node to an existing deployment. When I looked at the Fuel puppet code; it
looks like it failed at creation of a "heat_domain_admin" user in the
following file:



https://github.com/openstack/fuel-library/blob/stable/7.0/deployment/puppet/heat/manifests/keystone/domain.pp



Can you also help provide pointers on this? Is this a known issue in Fuel
7.0?



Many Thanks.



On Wed, Jan 27, 2016 at 2:50 PM, Sheena Gregson 
wrote:

Hey Rohan –



Let me see who I can track down to help answer your questions.  I’ll do my
best to have an answer back to you (or the right people added to the
thread) tomorrow.



Sheena



*From:* Rohan PARULEKAR [mailto:rohan.s.parule...@nuagenetworks.net]
*Sent:* Wednesday, January 27, 2016 1:26 PM
*To:* sgreg...@mirantis.com
*Subject:* Fuel 7.0 compute node re-deployment issue



Hi Sheena,



Hope things are good.



I was re-directed to you by "aschultz" for the issue I am running into
while adding a controller node to my deployment. In this process my compute
node re-deployment is failing for the following reasons:



[image: Inline image 1]



I had a chat about this on the IRC channel and I was presented with 2
options: 1) We rename our packages and services to match Fuel
package/service names 2) Write our own netconfig.pp



Regarding option 2; is there a way I can re-use most of the Fuel's
netconfig and only modify bits to meet our needs i.e use_ovs to be set to
False or things like that? Also; when I do that can I disable Fuel's
netconfig operation and have my netconfig only work? Can you please help me
with this issue as I have been lurking with this for quite a long time.



I have also attached my current Fuel plugin rpm if you need.

-- 

*Thanks,*

*Rohan Parulekar*
*Software Engineer, Nuage Networks*





-- 

*Thanks,*

*Rohan Parulekar*
*Software Engineer, Nuage Networks*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel][plugins] Detached components plugin update requirement

[Sheena Gregson]

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 for usage questions)
*Subject:* [openstack-dev] [fuel][plugins] Detached components plugin
update requirement



Hi,



Recently I merged the change to master and 8.0 that moves one task from
Nailgun to Library [1]. Actually, it replaces [2] to allow operator more
flexibility with repository management.  However, it affects the detached
components as they will require one more task to add as written at [3].
Please adapt your plugin accordingly.



[1]
https://review.openstack.org/#/q/I1b83e3bfaebecdb8455d5697e320f24fb4941536

[2]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/orchestrator/tasks_serializer.py#L149-L190

[3] https://review.openstack.org/#/c/270232/1/deployment_tasks.yaml



--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] nova-network removal

[Sheena Gregson]

We should continue to support nova-network for 7.0 and prior environments,
so it won't be removed completely.  We should prevent users from creating
new environments on Mitaka/8.0 versions and later which use nova-network.

On Mon, Jan 18, 2016 at 9:18 AM, Igor Kalnitsky 
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 
> wrote:
> > Adrian – can someone from the PI team please confirm what testing was
> > performed?
> >
> >
> >
> > From: Roman Alekseenkov [mailto:ralekseen...@mirantis.com]
> > Sent: Friday, January 15, 2016 11:30 AM
> >
> >
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Fuel] nova-network removal
> >
> >
> >
> > I agree with Sheena. Sounds like removing support for nova-network would
> be
> > the best option, even though it's late.
> >
> >
> >
> > However, I'd like us to think about the impact on vCenter integration.
> > vCenter+nova-network was fully supported 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
> 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 you think?
> >
> >
> >
> > From: Roman Prykhodchenko [mailto:m...@romcheg.me]
> > Sent: Friday, January 15, 2016 8:04 AM
> > To: OpenStack Development Mailing List (not for usage questions)
> > 
> > Subject: Re: [openstack-dev] [Fuel] nova-network removal
> >
> >
> >
> > I’d like to add that nova-network support was removed from
> python-fuelclient
> > in 8.0.
> >
> >
> >
> > 14 січ. 2016 р. о 17:54 Vitaly Kramskikh 
> > написав(ла):
> >
> >
> >
> > Folks,
> >
> > We have a request on review which prohibits creating new envs with
> > nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks
> away
> > from HCF, and I think this is too late for such a change. What do you
> think?
> > Should we proceed and remove nova-network support in 8.0, which is
> > deprecated since 7.0?
> >
> >
> > --
> >
> > Vitaly Kramskikh,
> > Fuel UI Tech Lead,
> > Mirantis, Inc.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] nova-network removal

[Sheena Gregson]

Adrian – can someone from the PI team please confirm what testing was
performed?



*From:* Roman Alekseenkov [mailto:ralekseen...@mirantis.com]
*Sent:* Friday, January 15, 2016 11:30 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] nova-network removal



I agree with Sheena. Sounds like removing support for nova-network would be
the best option, even though it's late.



However, I'd like us to think about the impact on vCenter integration.
vCenter+nova-network was fully supported 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 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 you think?



*From:* Roman Prykhodchenko [mailto:m...@romcheg.me]
*Sent:* Friday, January 15, 2016 8:04 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] nova-network removal



I’d like to add that nova-network support was removed from
python-fuelclient in 8.0.



14 січ. 2016 р. о 17:54 Vitaly Kramskikh 
написав(ла):



Folks,

We have a request on review which prohibits creating new envs with
nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks away
from HCF, and I think this is too late for such a change. What do you
think? Should we proceed and remove nova-network support in 8.0, which is
deprecated since 7.0?


-- 

Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

[Sheena Gregson]

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 we have now.



*From:* Maciej Kwiek [mailto:mkw...@mirantis.com]
*Sent:* Thursday, January 14, 2016 5:59 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is
broken due to lack of disk space



Igor,



I will investigate this, thanks!



Artem,



I guess that if we have an untrusted user on master node, he could just put
something he wants to be in the snapshot in /var/log without having to time
the attack carefully with tar execution.



I want to use links for directories, this saves me the trouble of creating
hardlinks for every single file in the directory. Although with how
exclusion is currently implemented it can cause deleting log files from
original directories, need to check this out.



About your PS: whole /var/log on master node (not in container) is
currently downloaded, I think we shouldn't change this as we plan to drop
containers in 9.0.



Cheers,

Maciej



On Thu, Jan 14, 2016 at 12:32 PM, Artem Panchenko 
wrote:

Hi,

using symlinks is a bit dangerous, here is a quote from the man you
mentioned [0]:

> The `--dereference' option is unsafe if an untrusted user can modify
directories while tar is running.

Hard links usage is much safer, because you can't use them for directories.
But at the same time implementation in shotgun would be more complicated
than with symlinks.

Anyway, in order to determine what linking to use we need to decide where
(/var/log or another partition) diagnostic snapshot will be stored.

p.s.

>This doesn't really give us much right now, because most of the logs are 
>fetched from master node via ssh due to shotgun being run in mcollective 
>container



AFAIK '/var/log/docker-logs/' is available from mcollective container and
mounted to /var/log/:

[root@fuel-lab-cz5557 ~]# dockerctl shell mcollective mount -l | grep
os-varlog
/dev/mapper/os-varlog on /var/log type ext4
(rw,relatime,stripe=128,data=ordered)

>From my experience '/var/log/docker-logs/remote' folder is most ' heavy'
thing in snapshot.

[0] http://www.gnu.org/software/tar/manual/html_node/dereference.html

Thanks!



On 14.01.16 13:00, Igor Kalnitsky wrote:

I took a glance on Maciej's patch and it adds a switch to tar command

to make it follow symbolic links

Yeah, that should work. Except one thing - we previously had fqdn ->

ipaddr links in snapshots. So now they will be resolved into full

copy?



I meant that symlinks also give us the benefit of not using additional

space (just as hardlinks do) while being able to link to files from

different filesystems.

I'm sorry, I got you wrong. :)



- Igor



On Thu, Jan 14, 2016 at 12:34 PM, Maciej Kwiek 
 wrote:

Igor,



I meant that symlinks also give us the benefit of not using additional space

(just as hardlinks do) while being able to link to files from different

filesystems.



Also, as Barłomiej pointed out the `h` switch for tar should do the trick

[1].



Cheers,

Maciej



[1] http://www.gnu.org/software/tar/manual/html_node/dereference.html



On Thu, Jan 14, 2016 at 11:22 AM, Bartlomiej Piotrowski

  wrote:

Igor,



I took a glance on Maciej's patch and it adds a switch to tar command to

make it follow symbolic links, so it looks good to me.



Bartłomiej



On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky
 

wrote:

Hey Maceij -



About hardlinks - wouldn't it be better to use symlinks?

This way we don't occupy more space than necessary

AFAIK, hardlinks won't occupy much space. They are the links, after all.

:)



As for symlinks, I'm afraid shotgun (and fabric underneath) won't

resolve them and links are get to snapshot As Is. That means if there

will be no content in the snapshot they are pointing to, they are

simply useless. Needs to be checked, though.



- Igor



On Thu, Jan 14, 2016 at 10:31 AM, Maciej Kwiek 


wrote:

Thanks for your insight guys!



I agree with Oleg, I will see what I can do to make this work this way.



About hardlinks - wouldn't it be better to use symlinks? This way we

don't

occupy more space than necessary, and we can link to files and

directories

that are in other block device than /var. Please see [1] review for a

proposed change that introduces symlinks.



This doesn't really give us much right now, because most of the logs

are

fetched from master node via ssh due to shotgun being run in

mcollective

container, but it's something! When we remove containers, this will

prove

more useful.



Regards,

Maciej Kwiek



[1] https://review.openstack.org/#/c/266964/



On Tue, Jan 12, 2016 at 1:51 PM, Oleg Gelbukh 


wrote:

I think we need to find a way to:



1) 

Re: [openstack-dev] [Fuel] nova-network removal

[Sheena Gregson]

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 you think?



*From:* Roman Prykhodchenko [mailto:m...@romcheg.me]
*Sent:* Friday, January 15, 2016 8:04 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] nova-network removal



I’d like to add that nova-network support was removed from
python-fuelclient in 8.0.



14 січ. 2016 р. о 17:54 Vitaly Kramskikh 
написав(ла):



Folks,

We have a request on review which prohibits creating new envs with
nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks away
from HCF, and I think this is too late for such a change. What do you
think? Should we proceed and remove nova-network support in 8.0, which is
deprecated since 7.0?


-- 

Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Removal of support for nova-network

[Sheena Gregson]

I agree – I don’t think we can change the user’s ability to manage old
releases.  This work should be about preventing the selection of
nova-network for new environments on 8.0 release and later – we should
restrict this via all methods of interaction, including UI, CLI and API if
possible.



*From:* Oleg Gelbukh [mailto:ogelb...@mirantis.com]
*Sent:* Tuesday, December 22, 2015 3:09 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Removal of support for nova-network



Sergii,



Nailgun will still have data of clusters with old releases, should they be
in the database backup. And it still has to be able to manage them.



--

Best regards,

Oleg Gelbukh



On Tue, Dec 22, 2015 at 11:58 AM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

Hi,



There won't be upgrade to 8.0. User will be able to backup and load data to
a new master node. nova-network has been deprecated for 2 releases so we
can remove it. If we remove it we can remove tests from acceptance testing
as well as from auto-tests so it should remove tech debt so will release
our QA/CI resources to focus on other tests.




--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser



On Tue, Dec 22, 2015 at 12:28 AM, Evgeniy L  wrote:

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 10:40 AM, Igor Kalnitsky 
wrote:

I don't think it's a good idea to drop support of 7.0 nova-network
setup in 8.0. We should keep compatibility for at least one release.


On Tue, Dec 22, 2015 at 9:15 AM, Aleksey Kasatkin
 wrote:
> Sergii,
>
> We could remove it completely from nailgun if support for 7.0 and earlier
is
> not required.
>
>
> Aleksey Kasatkin
>
>
> On Tue, Dec 22, 2015 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,
>> Skype #golserge
>> IRC #holser
>>
>> On Mon, Dec 21, 2015 at 5:01 PM, Sheena Gregson 
>> wrote:
>>>
>>> Hey guys –
>>>
>>>
>>>
>>> I know this has been a topic of a lot of discussion – Adrian informed me
>>> on Friday that QA has confirmed the multi-hypervisor use case has been
>>> tested successfully without nova-network, so we can finally deprecate
it!
>>>
>>>
>>>
>>> Users who want to deploy multiple hypervisors will need to use the Fuel
>>> DVS plugin (Neutron ML2 driver) to support their vCenter computes and
the
>>> KVM/QEMU computes can use Neutron + GRE/VXLAN.
>>>
>>>
>>>
>>> I’ve created a kind of “cover all the things” bug here:
>>> https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
>>> nova-network right now in Fuel, I have marked 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
>>>
>>> p: +1 650 646 3302 | e: sgreg...@mirantis.com
>>>
>>>
>>>
>>>
>>>
>>>
__
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
__
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Developme

[openstack-dev] [Fuel] Removal of support for nova-network

[Sheena Gregson]

Hey guys –



I know this has been a topic of a lot of discussion – Adrian informed me on
Friday that QA has confirmed the multi-hypervisor use case has been tested
successfully without nova-network, so we can finally deprecate it!



Users who want to deploy multiple hypervisors will need to use the Fuel DVS
plugin (Neutron ML2 driver) to support their vCenter computes and the
KVM/QEMU computes can use Neutron + GRE/VXLAN.



I’ve created a kind of “cover all the things” bug here:
https://bugs.launchpad.net/fuel/+bug/1528407.  Given the state of
nova-network right now in Fuel, I have marked 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/>

p: +1 650 646 3302 | e: sgreg...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

+1 as well – this makes intuitive sense to me as a user, we should include
something in the mouseover text explaining that KVM acceleration will be
used if possible based on hardware capabilities



*From:* Vladimir Kuklin [mailto:vkuk...@mirantis.com]
*Sent:* Monday, December 21, 2015 9:35 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard



+1 to Andrey



On Mon, Dec 21, 2015 at 6:12 PM, Andrey Danin  wrote:

I suggest to call this item in the Wizard as "QEMU-KVM" with the following
description:
"Select this option if you want to use QEMU as a hypervisor with capability
of KVM acceleration."



On Mon, Dec 21, 2015 at 5:22 PM, Igor Kalnitsky 
wrote:

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according
to Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

[1] https://en.wikipedia.org/wiki/Hypervisor

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration and
> defaults to QEMU in the case 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)".



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 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 attempts to use KVM acceleration and
> defaults to QEMU in the case that KVM acceleration is not possible.  We
> should keep this behavior and make the entry a single KVM/QEMU selection
> to eliminate the false perception of choice (and the ability for users to
> select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
> on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> 
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
> VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
> Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 

Andrey Danin
ada...@mirantis.com
skype: gcon.monolake


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





-- 

Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

According to Andrew Woodward (xarses), this is the current implementation.


-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Monday, December 21, 2015 8:23 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard

> Qemu is not a hypervisor This will be even more confusing.

It looks like hypervisor much more than libvirt. Moreover, according to
Wikipedia [1] (don't blame me guys) Qemu is Type-2 hypervisor.

[1] https://en.wikipedia.org/wiki/Hypervisor

> Today, when a user selects KVM, Fuel attempts to use KVM acceleration
> and defaults to QEMU in the case 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)".


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 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 attempts to use KVM acceleration
> and defaults to QEMU in the case that KVM acceleration is not
> possible.  We should keep this behavior and make the entry a single
> KVM/QEMU selection to eliminate the false perception of choice (and
> the ability for users to select the incorrect option).
>
> -Original Message-
> From: Bob Ball [mailto:bob.b...@citrix.com]
> Sent: Monday, December 21, 2015 7:32 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave
> Libvirt on Wizard
>
>> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
>> 
>> wrote:
>> > What about hypervisor "Qemu", and checkbox option on Settings tab -
>> > "Use KVM extension"?
>> Qemu is not a hypervisor This will be even more confusing.
>> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.
>
> Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT,
> Virtuozzo VM, LXC and KVM on ppc64 and s390x are all valid hypervisors
> to use with Libvirt and OpenStack (taken from
> http://docs.openstack.org/developer/nova/support-matrix.html)
>
> Bob
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt on Wizard

[Sheena Gregson]

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 attempts to use KVM acceleration and
defaults to QEMU in the case that KVM acceleration is not possible.  We
should keep this behavior and make the entry a single KVM/QEMU selection
to eliminate the false perception of choice (and the ability for users to
select the incorrect option).

-Original Message-
From: Bob Ball [mailto:bob.b...@citrix.com]
Sent: Monday, December 21, 2015 7:32 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][UX] Throw KVM\QEMU and leave Libvirt
on Wizard

> On Mon, Dec 21, 2015 at 1:43 PM, Igor Kalnitsky
> 
> wrote:
> > What about hypervisor "Qemu", and checkbox option on Settings tab -
> > "Use KVM extension"?
> Qemu is not a hypervisor This will be even more confusing.
> I think "Libvirt" + some tooltip which says "Qemu and KVM" will be ok.

Libvirt isn't a hypervisor either.  Note that Xen, Virtuozzo CT, Virtuozzo
VM, LXC and KVM on ppc64 and s390x are all valid hypervisors to use with
Libvirt and OpenStack (taken from
http://docs.openstack.org/developer/nova/support-matrix.html)

Bob

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in RabbitMQ

[Sheena Gregson]

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: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][FFE] Disabling HA for RPC queues in
RabbitMQ

Vova, Folks,

+1 to "set this option to false as an experimental feature"

Thanks,
Dims

On Wed, Dec 2, 2015 at 10:08 AM, Vladimir Kuklin 
wrote:
> Dmitry
>
> Although, I am a big fan of disabling replication for RPC, I think it
> is too late to introduce it so late by default. I would suggest that
> we control this part of OCF script with a specific parameter 'e.g.
> enable RPC replication' and set it to 'true' by default. Then we can
> set this option to false as an experimental feature, run some tests
> and decide whether it should be enabled by default or not. In this
> case, users who are interested in this, will be able to enable it when
> they need it, while we still stick to our old and tested approach.
>
> On Wed, Dec 2, 2015 at 5:52 PM, Konstantin Kalin 
> wrote:
>>
>> I would add on top of that Dmirty said that HA queues also increases
>> probability to have messages duplications under certain scenarios
>> (besides of that they are ~10x slower). Would Openstack services
>> tolerate if RPC request will be duplicated? What I've already learned
>> - No. Also if cluster_partition_handling=autoheal (what we currently
>> have) the messages may be lost as well during the failover scenarios
like non-HA queues.
>> Honestly I believe there is no difference between HA queues and non
>> HA-queues in RPC layer fail-tolerance in the way how we use RabbitMQ.
>>
>> Thank you,
>> Konstantin.
>>
>> On Dec 2, 2015, at 4:05 AM, Dmitry Mescheryakov
>>  wrote:
>>
>>
>>
>> 2015-12-02 12:48 GMT+03:00 Sergii Golovatiuk
:
>>>
>>> Hi,
>>>
>>>
>>> On Tue, Dec 1, 2015 at 11:34 PM, Peter Lemenkov 
>>> wrote:

 Hello All!

 Well, side-effects (or any other effects) are quite obvious and
 predictable - this will decrease availability of RPC queues a bit.
 That's for sure.
>>>
>>>
>>> Imagine the case when user creates VM instance, and some nova
>>> messages are lost. I am not sure we want half-created instances. Who
>>> is going to clean up them? Since we do not have results of
>>> destructive tests, I vote -2 for FFE for this feature.
>>
>>
>> Sergii, actually messaging layer can not provide any guarantee that
>> it will not happen even if all messages are preserved. Assume the
>> following
>> scenario:
>>
>>  * nova-scheduler (or conductor?) sends request to nova-compute to
>> spawn a VM
>>  * nova-compute receives the message and spawned the VM
>>  * due to some reason (rabbitmq unavailable, nova-compute lagged)
>> nova-compute did not respond within timeout (1 minute, I think)
>>  * nova-scheduler does not get response within 1 minute and marks the
>> VM with Error status.
>>
>> In that scenario no message was lost, but still we have a VM half
>> spawned and it is up to Nova to handle the error and do the cleanup in
that case.
>>
>> Such issue already happens here and there when something glitches.
>> For instance our favorite MessagingTimeout exception could be caused
>> by such scenario. Specifically, in that example when nova-scheduler
>> times out waiting for reply, it will throw exactly that exception.
>>
>> My point is simple - lets increase our architecture scalability by
>> 2-3 times by _maybe_ causing more errors for users during failover.
>> The failover time itself should not get worse (to be tested by me)
>> and errors should be correctly handler by services anyway.
>>

 However, Dmitry's guess is that the overall messaging backplane
 stability increase (RabitMQ won't fail too often in some cases)
 would compensate for this change. This issue is very much real -
 speaking of me I've seen an awful cluster's performance degradation
 when a failing RabbitMQ node was killed by some watchdog
 application (or even worse wasn't killed at all). One of these
 issues was quite recently, and I'd love to see them less frequently.

 That said I'm uncertain about the stability impact of this change,
 yet I see a reasoning worth discussing behind it.

 2015-12-01 20:53 GMT+01:00 Sergii Golovatiuk
:
 > Hi,
 >
 > -1 for FFE for disabling HA for RPC queue as we do not know all
 > side effects in HA scenarios.
 >
 > On Tue, Dec 1, 2015 at 7:34 PM, Dmitry Mescheryakov
 >  wrote:
 >>
 >> Folks,
 >>
 >> I would like to request feature freeze exception for disabling
 >> HA for RPC queues in RabbitMQ [1].
 >>
 >> As I already wrote in another thread [2], I've conducted tests
 >> which clearly show benefit we will get from that change. The
 >> change itself is a very sm

Re: [openstack-dev] [Fuel] Feature Freeze is soon

[Sheena Gregson]

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 soon



In order to be effective, I created an etherpad to go over:

https://etherpad.openstack.org/p/8.0-features-status



I'd like to call everyone to update status of blueprints, so that we can
have accurate picture of 8.0 deliverables. During the meeting, I'd like us
to quickly sync on FFEs and clarify status of major blueprints (if it won't
be updated by some reason).



In fact, we'd need to go over two first sections of etherpad (around 15
items now). I assume that 1 hour will be enough, and ideally to go quicker.
If I'm missing anything believed to be major, please move it in there.



Thanks,



On Tue, Dec 1, 2015 at 1:37 AM Vladimir Kuklin  wrote:

Mike I think, it is rather good idea. I guess we can have a couple of
requests still - although everyone is shy, we might get a little storm of
FFE's. BTW, I will file at least one.



On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov 
wrote:

Hi Fuelers,

we are couple of days away from FF [1]. I have not noticed any request for
feature freeze exception, so I assume that we pretty much decided what is
going into 8.0 and what is not.



If there are items which we'd like to ask exception for, I'd like us to
have this requested now - so that we all can spend some time on analysis of
what is done and what is left, and on risks assessment. I'd suggest to not
consider any exception requests on the day of FF, as it doesn't leave us
time to spend on it.



To make a formal checkpoint of what is in and what is out, I suggest to get
together on FF day, Wednesday, and go over all the items we have been
working on in 8.0. What do you think folks? For instance, in #fuel-dev IRC
at 8am PST (4pm UTC)?



[1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule

-- 

Mike Scherbakov
#mihgen



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





-- 

Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

[Sheena Gregson]

We do support Neutron for vCenter, but – as I mentioned a few months ago –
we do not yet have a fully vetted way to deploy the multi-hypervisor use
case with both KVM/QEMU and vCenter.  This depends on our ability to select
multiple networking options and align them to the correct hypervisors.



Per a conversation with Andrian Noga and his team yesterday, they are
finishing work on the component registry [1] which will enable the
multi-hypervisor, multi-network use case.  This work is being completed now.



My recommendation remains that we should avoid deprecating nova-network
until we have at least tested the basic multi-hypervisor use case with the
new functionality.  Can we remove nova-network after FF as a High priority
bug?



[1] https://review.openstack.org/#/c/229306/



*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]

*Sent:* Tuesday, December 01, 2015 1:37 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a deployment
option in Fuel?



Aleksey, can you clarify it? Why it can't be deployed? According to what I
see at our fakeUI install [1], wizard allows to choose nova-network only in
case if you choose vcenter.



Do we support Neutron for vCenter already? If so - we could safely remove
nova-network altogether.



[1] http://demo.fuel-infra.org:8000/



On Mon, Nov 30, 2015 at 4:27 AM Aleksey Kasatkin 
wrote:

This remains unclear.

Now, for 8.0, the Environment with Nova-Network can be created but cannot
be deployed (and its creation is tested in UI integration tests).
AFAIC, we should either remove the ability of creation of environments with
Nova-Network in 8.0 or return it back into working state.


Aleksey Kasatkin



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 the component registry (
https://blueprints.launchpad.net/fuel/+spec/component-registry) is still
not complete.  The component registry is required for a multi-HV
environment, because it provides compatibility information for Networking
and HVs.  In theory, landing this feature will enable us to configure DVS +
vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment.



While Andriy Popyvich has made considerable progress on this story, I
personally feel very strongly against deprecating nova-network until we
have confirmed that we can support *all current use cases* with the
available code base.



Are we willing to lose the multi-HV functionality if something prevents the
component registry work from landing in its entirety before the next
release?



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Friday, October 23, 2015 6:30 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a deployment
option in Fuel?



Hi,



As far as I know neutron code for VCenter is ready. Guys are still testing
it. Keep patience... There will be announce soon.


--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins][UX] Component registry

[Sheena Gregson]

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 plugins
are added to an existing release, the previously published plugins cannot
show that they are either (1) incompatible or (2) untested.



The proposed approach solves this problem.  Adding compatibility gives more
clarity to the users about known good combinations, and creating a gray
area for untested component combinations helps expose areas where we
haven’t done thorough testing and there may be issues, and users should
proceed with guidance/support.



*From:* Vitaly Kramskikh [mailto:vkramsk...@mirantis.com]
*Sent:* Monday, November 02, 2015 8:38 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins][UX] Component registry



Hi,

I think having both compatibility and incompatibility lists is a good idea.
I think we need just to show a warning if users pick options which are not
in compatibility list and disable options which are in incompatibility
list. We also need to be able to provide a message in case of
incompatibility: the current implementation of the wizard supports custom
messages in the wizard config and they are quite useful.



2015-11-02 16:16 GMT+07:00 Evgeniy L :

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 provide all of the information plugin developer knows, directly to
the user,

without us in the middle who make decisions based on incomplete data.



So lets ask plugin developer to specify a set of components which he tested

his plugin with. Plus a list of components which he tested with and he is
sure

that those are not going to working together.



On UI we can show explicitly, that this combination is tested and approved
to

be working, another combination is not working for sure (plugin developers
tested

it and explicitly specified), and there will be a lot of combination which
are going

to work together without problems, but we should say the user, that the
developer

didn't test it and he should test and use it carefully.



Thanks,



On Mon, Nov 2, 2015 at 11:22 AM, Andriy Popovych 
wrote:

Hi fuelers,

Currently we are working on feature component registry [1] which should
help us to prevent not logical compositions of different components in
wizard tab during cluster(environment) creation. Now we have a mechanizm
of 'restrictions' which is not flexible for components provided by
plugins. In our current approach we have two states for components -
compatible/incompatible which are described in compatibility matrix
based on OpenStack components (For example: cinder-vmware storage only
compatible with vCetner hypervisor and should work when only KVM uses).
In this case we allow user to choose only that components we defently
know works well with each other. Another approach tell us to have 3
states: compatible/incompatible/ and all other components about
compatibility with others we know nothing. In that case we should show
on wizard which components compatible, which not, and others which user
can enable on his own risk. So I need your opinions: should we allow for
user choose only that coponents which are tested and defently works or
prevent her/him from choosing which are defently not works and means
potentional risk of failing deployment when component about we know
nothing isn't work together.



[1] https://blueprints.launchpad.net/fuel/+spec/component-registry

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?

[Sheena Gregson]

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/+spec/component-registry) is still
not complete.  The component registry is required for a multi-HV
environment, because it provides compatibility information for Networking
and HVs.  In theory, landing this feature will enable us to configure DVS +
vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment.



While Andriy Popyvich has made considerable progress on this story, I
personally feel very strongly against deprecating nova-network until we
have confirmed that we can support *all current use cases* with the
available code base.



Are we willing to lose the multi-HV functionality if something prevents the
component registry work from landing in its entirety before the next
release?



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Friday, October 23, 2015 6:30 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a deployment
option in Fuel?



Hi,



As far as I know neutron code for VCenter is ready. Guys are still testing
it. Keep patience... There will be announce soon.


--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] FW: [Fuel] 8.0 Region name support / Multi-DC

[Sheena Gregson]

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



We are doing some technology evaluations with the intent of publishing
reference architectures at various scale points (500, 1500, 2000 etc). Part
of this work will be to determine how to best partition the nodes in to
regions based on scale limits of OpenStack components and workload
characteristics. The work we are doing increased in scope significantly, so
the first RA will be coming at the end of Q1 or early Q2.



We do plan on using some components of Fuel for our testing but the main
purpose is path finding. The work we do will eventually make it into Fuel,
but we are going to run in front of it a bit.



On Fri, Oct 2, 2015 at 9:19 AM Sheena Gregson  wrote:

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 wanted to comment here.



Regarding specifying region names in UI, is it possible to specify region
names in API?  And (apologies for my ignorance on this one) what is the
relative equivalence to environments in Fuel (e.g. 1 environment : many
regions, 1 environment == 1 region)?



*From:* Roman Sokolkov [mailto:rsokol...@mirantis.com]
*Sent:* Friday, October 02, 2015 5:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC



Folks,



i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
support.



My ask is about tiny(but useful) feature: give user ability to *specify
Region name in UI.*



Region name is already in every puppet module, so we just need to add this
to UI.



Do we have smth already?



More general question: What are our plans in regards Multi-DC?



Thanks



-- 

Roman Sokolkov,

Deployment Engineer,

Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com

-- 

Chris Clason

Director of Architecture

ccla...@mirantis.com

Mobile: +1.408.409.0295
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC

[Sheena Gregson]

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 wanted to comment here.



Regarding specifying region names in UI, is it possible to specify region
names in API?  And (apologies for my ignorance on this one) what is the
relative equivalence to environments in Fuel (e.g. 1 environment : many
regions, 1 environment == 1 region)?



*From:* Roman Sokolkov [mailto:rsokol...@mirantis.com]
*Sent:* Friday, October 02, 2015 5:26 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC



Folks,



i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
support.



My ask is about tiny(but useful) feature: give user ability to *specify
Region name in UI.*



Region name is already in every puppet module, so we just need to add this
to UI.



Do we have smth already?



More general question: What are our plans in regards Multi-DC?



Thanks



-- 

Roman Sokolkov,

Deployment Engineer,

Mirantis, Inc.
Skype rsokolkov,
rsokol...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] add health check for plugins

[Sheena Gregson]

I just realized I missed this thread when Andrey responded to it –
apologies!



I was thinking of things like – confirming VMware username and password are
accurate, confirming that SSL certificate chain is valid, etc. – some of
these are not plugin based, but I think there is value in enabling both
core components and plugins to specify tests that can be run prior to
deployment that will help ensure the deployment will not fail.



Does that make sense?  In this case, it is not confirming the deployment
was successful (post-deployment), it is checking known parameters for
validity prior to attempting to deploy (pre-deployment).



*From:* Samuel Bartel [mailto:samuel.bartel@gmail.com]
*Sent:* Monday, September 28, 2015 11:13 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for plugins



Hi,

Totally agree with you Andrey,

other use cases could be :

-for Ironic plugin, add test to validate that Ironic is properly deploy

-for LMA plugin check that metric and log are properly collect, that elk,
nagios or grafana dashboard are accessible

-for cinder netapp multi backend, check that different type of backend can
be crreated

and so on

So it would be very intersting to have enxtensibility ofr OSTF test





Samuel



2015-09-08 0:05 GMT+02:00 Andrey Danin :

Hi.

Sorry for bringing this thread back from the grave but it look quite
interesting to me.

Sheena, could you please explain how pre-deployment sanity checks should
look like? I don't get what it is.

>From the Health Check point of view plugins may be divided to two groups:


1) A plugin that doesn't change an already covered functionality thus
doesn't require extra tests implemented. Such plugins may be Contrail and
almost all SDN plugins, Glance or Cinder backend plugins, and others which
don't bring any changes in OSt API or any extra OSt components.


2) A plugin that adds new elements into OSt or changes API or a standard
behavior. Such plugins may be Contrail (because it actually adds Contrail
Controller which may be covered by Health Check too), Cisco ASR plugin
(because it always creates HA routers), some Swift plugins (we don't have
Swift/S3 API covered by Health Check now at all), SR-IOV plugins (because
they require special network 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, 2015 at 5:17 PM, Sheena Gregson 
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...@mirantis.com]
*Sent:* Monday, August 10, 2015 9:00 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for plugins



Hello Samuel,

This looks like an interesting idea. Do you have any concrete example to
illustrate your point (with one of your plugins maybe)?

BR,

Simon



On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel 
wrote:

Hi all,



actually with fuel plugins there are test for the plugins used by the CICD,
but after a deployment it is not possible for the user to easily test if a
plugin is crrectly deploy or not.

I am wondering if it could be interesting to improve the fuel plugin
framework in order to be able to define test for each plugin which would ba
dded to the health Check. the user would be able to test the plugin when
testing the deployment test.



What do you think about that?





Kind regards



Samuel


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 

Andrey Danin
ada...@mirantis.com
skype: gcon.monolake


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-re

Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for fuel-docs core

[Sheena Gregson]

+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 
*Subject:* Re: [openstack-dev] [Fuel] Nominate Olga Gusarenko for fuel-docs
core



+1

Nice!)



Alexander



On Fri, Sep 11, 2015 at 8:19 PM, Dmitry Borodaenko 
wrote:

+1

Great work Olga!



On Fri, Sep 11, 2015, 11:09 Irina Povolotskaya 
wrote:

Fuelers,



I'd like to nominate Olga Gusarenko for the fuel-docs-core.



She has been doing great work and made a great contribution

into Fuel documentation:

http://stackalytics.com/?user_id=ogusarenko&release=all&project_type=all&module=fuel-docs

It's high time to grant her core reviewer's rights in fuel-docs.

Core reviewer approval process definition:
https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess



-- 

Best regards,


Irina













__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL keys saving

[Sheena Gregson]

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 sure what the cost is of deploying Barbican (would this be on the
fuel-master as well?  Isn’t it getting crowded in there?).



Barbican currently has an integration available for a SafeNet Luna HSM,
which runs in the tens of thousands per device, so I don’t think it’s
reasonable to expect to use this for each customer environment (although
long-term we should be looking to provide a full/secure solution to
customers).



Sheena



*From:* Evgeniy L [mailto:e...@mirantis.com]
*Sent:* Monday, August 24, 2015 6:48 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] SSL keys saving



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 8.0 release.



Thanks,



On Mon, Aug 24, 2015 at 3:57 PM, John Dennis  wrote:

On 08/21/2015 05:10 AM, Stanislaw Bogatkin wrote:

Hi folks.

Today I want to discuss the way we save SSL keys for Fuel environments.
As you maybe know we have 2 ways to get a key:
a. Generate it by Fuel (self-signed certificate will be created in this
case). In this case we will generate private key, csr and crt in a
pre-deployment hook on master node and then copy keypair to the nodes
which needed it.

b. Get a pre-generated keypair from user. In this case user should
create keypair by himself and then upload it through Fuel UI settings
tab. In this case keypair will be saved in nailgun database and then
will serialized into astute.yaml on cluster nodes, pulled from it by
puppet and saved into a file.

Second way has some flaws:
1. We already have some keys for nodes and we store them on master node.
Store keys in different places is bad, cause:
1.1. User experience - user should remember that in some cases keys will
be store in FS and in some other cases - in DB.
1.2. It brings problems for implementation in other different places -
for example, we need to get certificate for properly run OSTF tests and
now we should implement two different ways to deliver that certificate
to OSTF container. The same for fuel-cli - we should somehow get
certificate from DB and place it in FS to use it.
2. astute.yaml is similar for all nodes. Not all of nodes needs to have
private key, but now we cannot control this.
3. If keypair data serializes into astute.yaml it means than that data
automatically will be fetched when diagnostic snapshot will created. So
in some cases in can lead to security vulnerability, or we will must to
write another crutch to cut it out of diagnostic snapshot.


So I propose to get rid of saving keypair in nailgun database and
implement a way to always saving it to local FS on master node. We need
to implement next items:

- Change UI logic that saving keypair into DB to logic that will save it
to local FS
- Implement according fixes in fuel-library



I have not been following this thread nor I do I know or understand all
your requirements but I wanted to bring to your attention the fact
OpenStack has a project called Barbican whose primary purpose is to safely
store keys, plus it has many other features for handling keys. Key handling
is tricky so rather than try to design something yourself perhaps it might
make sense to leverage the Barbican work.

https://wiki.openstack.org/wiki/Barbican/Incubation

http://www.rackspace.com/blog/keeping-openstack-secrets-safe-with-barbican/

http://www.slideshare.net/jarito030506/barbican-10-open-source-key-management-for-openstack


-- 
John



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] add health check for plugins

[Sheena Gregson]

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 Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] add health check for plugins



Hello Samuel,

This looks like an interesting idea. Do you have any concrete example to
illustrate your point (with one of your plugins maybe)?

BR,

Simon



On Mon, Aug 10, 2015 at 12:04 PM, Samuel Bartel 
wrote:

Hi all,



actually with fuel plugins there are test for the plugins used by the CICD,
but after a deployment it is not possible for the user to easily test if a
plugin is crrectly deploy or not.

I am wondering if it could be interesting to improve the fuel plugin
framework in order to be able to define test for each plugin which would ba
dded to the health Check. the user would be able to test the plugin when
testing the deployment test.



What do you think about that?





Kind regards



Samuel


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL for master node API

[Sheena Gregson]

+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 7.0 and for 3rd for 8.0



But I would suggest that we add an option to astute.yaml that a user can
set to true to force ssl and then he will need to install updated
nailgun-agent for older environments. In this case user will do this
concisely, knowing about potential caveats of forcing SSL.



On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L  wrote:

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 
wrote:

Hi guys,

in overall movement of Fuel to use secure sockets we think about wrapping
master node UI and API calls to SSL. But there are next caveat:



a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a
little. But if it will be rewritten in 7.0 and HTTPS on master node will be
forced by default, it will break upgrade from previous releases to 7.0 due
fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by
default and fuel-nailgun-agent on all environments won't upgraded, so it
won't be able to connect to master node after upgrade. It breaks seamless
upgrade procedure.



What options I see there:

1. We can forcedly enable SSL for master node and rewrite clients in 7.0 to
be able to work over it. In release notes for 7.0 we will write forewarning
that clients which want to upgrade master node from previous releases to
7.0 must also install new fuel-nailgun-agent to all nodes in all deployed
environments.



2. We can have both SSL and non-SSL versions enabled by default and rewrite
fuel-nailgun-client in 7.0 such way that it will check SSL availability and
be able to work in plain HTTP for legacy mode. So, for all new environments
SSL will be used by default and for old ones plain HTTP will continue to
work too. Master node upgrade will not be broken in this case.



3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save
both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
releases. It is just postponed version of first clause, so it doesn't seems
valid for me, actually.



I would be really glad to hear what you think about this. Thank you in
advance.



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





-- 

Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

Ah, my mistake - yes, please push tags for all of the plugin builder
versions.

-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Thursday, July 30, 2015 10:47 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback

Hi guys,

@Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it
[1].

@Sheena, fuel_plugins_builder isn't associated with Fuel releases.
Here's a list of all versions:

fuel-plugin-builder 2.0.4
fuel-plugin-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 
wrote:
> I would imagine we would want tags for any releases that have plugins
> associated, or we are planning to have plugins associated (so, 6.0,
> 6.1, 7.0).
>
> -Original Message-
> From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
> Sent: Thursday, July 30, 2015 9:46 AM
> To: OpenStack Development 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 only cores are Igor and Evgeniy?  Can one of you add tags for
>> the new release versions?
>>
>>
>>
>> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
>> Sent: Thursday, July 30, 2015 8:02 AM
>>
>>
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>>
>>
>>
>>
>> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>>
>> Hi Sheena,
>>
>>
>>
>> Created ticket to change the structure of the directories [1].
>>
>> And as far as I know any core can push tags 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
>> 
>> wrote:
>>
>> 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)
>> 
>> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>>
>>
>>
>> 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 this information permanently [1].
>>
>>
>>
>>>> a. We are doing the same mistake putting all things into one basket.
>>>> There should be 2 repositories. One for examples and one for fpb.
>>>> What's the goal of keeping fpb in directory and examples on top?
>>
>>
>>
>> These plugins are the data which are required for integration
>> testing,
>>
>> we test that plugin build is not broken, which we run when patch gets
>>
>> published. I see nothing wrong with having the data for integration
>> testing
>>
>> in the same repository with product which should be tested.
>>
>> Also in previous release we *removed* all the plugins which are not
>>
>> related to the builder itself, lbaas and glusterfs.
>>
>>
>>
>>>> This breaks a couple of things
>>
>>
>>
>> Having data for testing in the repository doesn't break anything.
>>
>>
>>
>>>> b. I cannot build fpm with simple
>>
>>
>>
>> That is a good point, we should move code from fuel_plugin_builder
>> directory
>>
>> on top level, and move data for testing into examples directory.
>>
>>
>>
>>>> c. There 

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

I would imagine we would want tags for any releases that have plugins
associated, or we are planning to have plugins associated (so, 6.0, 6.1,
7.0).

-Original Message-
From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com]
Sent: Thursday, July 30, 2015 9:46 AM
To: OpenStack Development 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 only cores are Igor and Evgeniy?  Can one of you add tags for
> the new release versions?
>
>
>
> From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
> Sent: Thursday, July 30, 2015 8:02 AM
>
>
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
>
>
>
>
> 2015-07-30 14:50 GMT+02:00 Evgeniy L :
>
> Hi Sheena,
>
>
>
> Created ticket to change the structure of the directories [1].
>
> And as far as I know any core can push tags 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
> 
> wrote:
>
> 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)
> 
> Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback
>
>
>
> 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 this information permanently [1].
>
>
>
>>> a. We are doing the same mistake putting all things into one basket.
>>> There should be 2 repositories. One for examples and one for fpb.
>>> What's the goal of keeping fpb in directory and examples on top?
>
>
>
> These plugins are the data which are required for integration testing,
>
> we test that plugin build is not broken, which we run when patch gets
>
> published. I see nothing wrong with having the data for integration
> testing
>
> in the same repository with product which should be tested.
>
> Also in previous release we *removed* all the plugins which are not
>
> related to the builder itself, lbaas and glusterfs.
>
>
>
>>> This breaks a couple of things
>
>
>
> Having data for testing in the repository doesn't break anything.
>
>
>
>>> b. I cannot build fpm with simple
>
>
>
> That is a good point, we should move code from fuel_plugin_builder
> directory
>
> on top level, and move data for testing into examples directory.
>
>
>
>>> c. There is no tags as I can see only stable/6.0
>
>
>
> Correct, tags should be added.
>
>
>
>>> d. There are no tests to improve code quality pep8 flask8, code
>>> coverage
>
>
>
> That is not true, there are more then one hundreds unit tests which we
> run
>
> for each patch with python 2.6 and python 2.7, also there are
> integration tests
>
> which check that for each patch we don't break validation and that we
> can
>
> build plugins for previous versions. Plus there are functional tests
> which are
>
> written by fuel-qa team, those tests check that we perform deployment
>
> with plugins and required functionality works correctly. Also there
> *is*
> pep8
>
> check [2].
>
>
>
>>> e. Repository doesn't follow community standards.
>
>
>
> I think this issue should be resolved with moving fuel_plugin_builder
> directory
>
> on level higher, if not, please provide more specific description what
> is wrong.
>
>
>
>>> 3. Setting tab ...
>
>
>
> Agree.
>
>
>
> [1]
> https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677
> &oldid=78204
>
> [2]
> https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_bui
> lder/tox.ini#L17-L21
>
>
>
> On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk
>  wrote:
>
> Hi,
>
> I have started 

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

So the only cores are Igor and Evgeniy?  Can one of you add tags for the
new release versions?



*From:* Sebastian Kalinowski [mailto:skalinow...@mirantis.com]
*Sent:* Thursday, July 30, 2015 8:02 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback







2015-07-30 14:50 GMT+02:00 Evgeniy L :

Hi Sheena,



Created ticket to change the structure of the directories [1].

And as far as I know any core can push tags 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 
wrote:

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.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



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 this information permanently [1].



>> a. We are doing the same mistake putting all things into one basket.
There should be 2 repositories. One for examples and one for fpb. What's
the goal of keeping fpb in directory and examples on top?



These plugins are the data which are required for integration testing,

we test that plugin build is not broken, which we run when patch gets

published. I see nothing wrong with having the data for integration testing

in the same repository with product which should be tested.

Also in previous release we *removed* all the plugins which are not

related to the builder itself, lbaas and glusterfs.



>> This breaks a couple of things



Having data for testing in the repository doesn't break anything.



>> b. I cannot build fpm with simple



That is a good point, we should move code from fuel_plugin_builder directory

on top level, and move data for testing into examples directory.



>> c. There is no tags as I can see only stable/6.0



Correct, tags should be added.



>> d. There are no tests to improve code quality pep8 flask8, code coverage



That is not true, there are more then one hundreds unit tests which we run

for each patch with python 2.6 and python 2.7, also there are integration
tests

which check that for each patch we don't break validation and that we can

build plugins for previous versions. Plus there are functional tests which
are

written by fuel-qa team, those tests check that we perform deployment

with plugins and required functionality works correctly. Also there *is*
pep8

check [2].



>> e. Repository doesn't follow community standards.



I think this issue should be resolved with moving fuel_plugin_builder
directory

on level higher, if not, please provide more specific description what is
wrong.



>> 3. Setting tab ...



Agree.



[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204

[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk 
wrote:

Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

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

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repos

Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

[Sheena Gregson]

I think it becomes challenging to communicate to users why some of the
nova-network flows show a warning and are not tested while others appear to
work without issue.



For example, a customer using multi-HV would see a successful nova-network
selection, but if they change to using only KVM/QEMU, it would show a
warning.  This seems weird to me from a user perspective.



That’s not to say we can’t do it, I’m just not sure I see the value we are
providing to users by providing unsupported and/or untested flows that are
difficult to message correctly.



*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 1:14 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network



I'm fine with removing the related code from Fuel then, but I'm not Ok with
introducing limitations code.



If we don't want to remove the code (and I believe we don't because of
backward compatibility reasons), then why don't we just add a warning that
this is deprecated / unsopported? And QA will not focus their efforts 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 upstream and will relatedly be
deprecated in Fuel – AFAIK, there is a goal to deprecate nova-network
entirely in Fuel 8.0 -  we should reduce the number of customers who are
even able to use this as the networking underlay to only reflect customers
who absolutely require it.



There is not sufficient value in supporting nova-network for other use
cases.



*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 12:47 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network



Folks,

why do we even want to introduce restrictions?



Please see

https://bugs.launchpad.net/fuel/+bug/1470488

about locking nova-network.



We already suffer from locked Settings tab in our API.



Instead, we just need to introduce a warning, that this option is
deprecated and it's on risk of a user to use it. We want Fuel to be
flexible, and not too prescriptive.



Thanks,

-- 

Mike Scherbakov
#mihgen

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network

[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 deprecate nova-network
entirely in Fuel 8.0 -  we should reduce the number of customers who are
even able to use this as the networking underlay to only reflect customers
who absolutely require it.



There is not sufficient value in supporting nova-network for other use
cases.



*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 12:47 PM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network



Folks,

why do we even want to introduce restrictions?



Please see

https://bugs.launchpad.net/fuel/+bug/1470488

about locking nova-network.



We already suffer from locked Settings tab in our API.



Instead, we just need to introduce a warning, that this option is
deprecated and it's on risk of a user to use it. We want Fuel to be
flexible, and not too prescriptive.



Thanks,

-- 

Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

It’s also worth mentioning that there has been discussion about
transitioning current “core” components of Fuel to plugins (like Ceph or
the current vCenter implementation).



In these cases, as with others, displaying the plugin’s functionality in
its logical location from a user perspective will be incredibly important
to ensuring the user has a positive and successful experience.



*From:* Patrick Petit [mailto:ppe...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 7:56 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>; 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 trying to
deploy something like Contrail, I would like to see all of my Networking
configuration options together (including the Contrail plugin) so that I
can make an intelligent selection in the context of networking.



Agreed


When plugins are not related to a specific space, I personally as a user
would expect to see a generic “Plugins” grouping in the Settings tab to
reduce sub-group proliferation (I probably don’t need a sub-group for every
plugin).



I know that in conversations with Patrick (cc’d for input) he has mentioned
wanting to have the plugins define the space they should be displayed in,
as well, including spaces where core component settings are made.



Absolutely. I think the plugins paradigme should be considered more of an
implementation artefact than a logical grouping of functionality. I think
that what we need is a mechanism by which plugins are free to make that
logical grouping of settings in a way that is meaningful and consistent
from an end-user standpoint.


I agree that name validation could probably be improved – the names right
now correspond either to the plugin name or to the name of the section that
existed in the previous version.  This initial iteration breaks down
subgroups but does not change any of the section naming conventions or do
anything else to make the Settings space more manageable.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 5:24 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



Sheena, I still have concerns regarding #3. I am sending attachment how
it's implemented. Firstly, it's bad practice to mix core and plugin
functionality. Also we do not validate names. When there are several
plugins it's very hard to find all of them

I am giving a sketch how it should be IMO


--
Best regards,
Sergii 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.  We could potentially prioritize updates to the Plugin
SDK for soon-to-be-released features ahead of the standard release notes
and user guide updates to ensure that plugin developers have access to this
information earlier?  A number of the docs team members will be getting
together in late August to discuss how to improve documentation, I will add
this as a topic if we don’t feel there is good resolution on the mailing
list.

*+Alexander/Evgeny to cc for their input*



#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in
the tab which should make it significantly easier for a user to find plugin
settings.  Each plugin will create a new sub-group in the Settings tab,
like Access (and others) in the screenshot below.





I don’t have any insight on the GitHub issues, so I will wait for others to
weigh in on your concerns there.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 9:51 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel][Plugins] Feedback



Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

c. There

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

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 trying to
deploy something like Contrail, I would like to see all of my Networking
configuration options together (including the Contrail plugin) so that I
can make an intelligent selection in the context of networking.



When plugins are not related to a specific space, I personally as a user
would expect to see a generic “Plugins” grouping in the Settings tab to
reduce sub-group proliferation (I probably don’t need a sub-group for every
plugin).



I know that in conversations with Patrick (cc’d for input) he has mentioned
wanting to have the plugins define the space they should be displayed in,
as well, including spaces where core component settings are made.



I agree that name validation could probably be improved – the names right
now correspond either to the plugin name or to the name of the section that
existed in the previous version.  This initial iteration breaks down
subgroups but does not change any of the section naming conventions or do
anything else to make the Settings space more manageable.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Wednesday, July 29, 2015 5:24 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



Sheena, I still have concerns regarding #3. I am sending attachment how
it's implemented. Firstly, it's bad practice to mix core and plugin
functionality. Also we do not validate names. When there are several
plugins it's very hard to find all of them

I am giving a sketch how it should be IMO


--
Best regards,
Sergii 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.  We could potentially prioritize updates to the Plugin
SDK for soon-to-be-released features ahead of the standard release notes
and user guide updates to ensure that plugin developers have access to this
information earlier?  A number of the docs team members will be getting
together in late August to discuss how to improve documentation, I will add
this as a topic if we don’t feel there is good resolution on the mailing
list.

*+Alexander/Evgeny to cc for their input*



#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in
the tab which should make it significantly easier for a user to find plugin
settings.  Each plugin will create a new sub-group in the Settings tab,
like Access (and others) in the screenshot below.





I don’t have any insight on the GitHub issues, so I will wait for others to
weigh in on your concerns there.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 9:51 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel][Plugins] Feedback



Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

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

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add ow

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

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.org>
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback



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 this information permanently [1].



>> a. We are doing the same mistake putting all things into one basket.
There should be 2 repositories. One for examples and one for fpb. What's
the goal of keeping fpb in directory and examples on top?



These plugins are the data which are required for integration testing,

we test that plugin build is not broken, which we run when patch gets

published. I see nothing wrong with having the data for integration testing

in the same repository with product which should be tested.

Also in previous release we *removed* all the plugins which are not

related to the builder itself, lbaas and glusterfs.



>> This breaks a couple of things



Having data for testing in the repository doesn't break anything.



>> b. I cannot build fpm with simple



That is a good point, we should move code from fuel_plugin_builder directory

on top level, and move data for testing into examples directory.



>> c. There is no tags as I can see only stable/6.0



Correct, tags should be added.



>> d. There are no tests to improve code quality pep8 flask8, code coverage



That is not true, there are more then one hundreds unit tests which we run

for each patch with python 2.6 and python 2.7, also there are integration
tests

which check that for each patch we don't break validation and that we can

build plugins for previous versions. Plus there are functional tests which
are

written by fuel-qa team, those tests check that we perform deployment

with plugins and required functionality works correctly. Also there *is*
pep8

check [2].



>> e. Repository doesn't follow community standards.



I think this issue should be resolved with moving fuel_plugin_builder
directory

on level higher, if not, please provide more specific description what is
wrong.



>> 3. Setting tab ...



Agree.



[1]
https://wiki.openstack.org/w/index.php?title=Fuel%2FPlugins&diff=78677&oldid=78204

[2]
https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21



On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk 
wrote:

Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

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

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a
plan how to address them.

Thank you in advance.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Fuel][Plugins] Feedback

[Sheena Gregson]

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 the standard release notes
and user guide updates to ensure that plugin developers have access to this
information earlier?  A number of the docs team members will be getting
together in late August to discuss how to improve documentation, I will add
this as a topic if we don’t feel there is good resolution on the mailing
list.

*+Alexander/Evgeny to cc for their input*



#3 Settings tab is getting a facelift in 7.0 and there are now subgroups in
the tab which should make it significantly easier for a user to find plugin
settings.  Each plugin will create a new sub-group in the Settings tab,
like Access (and others) in the screenshot below.





I don’t have any insight on the GitHub issues, so I will wait for others to
weigh in on your concerns there.



Sheena



*From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com]
*Sent:* Tuesday, July 28, 2015 9:51 AM
*To:* OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
*Subject:* [openstack-dev] [Fuel][Plugins] Feedback



Hi,

I have started digging into plugins recently. There are many positive
things though I would like to point to some problem areas

1. Documentation

a. It doesn't include the features of 7.0. There are many outstanding
features, though I needed to ping the developers to ask how these features
work. It means that it's almost impossible to develop plugins for upcoming
releases. The external developer needs to wait for documentation so it
creates a lag between release and plugin release.

b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended
to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent
to 12.04

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

2. Github repository [2] is messed up

a. We are doing the same mistake putting all things into one basket. There
should be 2 repositories. One for examples and one for fpb. What's the goal
of keeping fpb in directory and examples on top? This breaks a couple of
things

b. I cannot build fpm with simple

pip install git+https://

Instead I am forced to do

git clone https://

cd fuel-plugins

pip install .



c. There is no tags as I can see only stable/6.0

d. There are no tests to improve code quality pep8 flask8, code coverage

e. Repository doesn't follow community standards.



3. Setting tab

When plugin is installed, it's very hard to find in. In setting tab it's
somewhere between A and Z

How is user supposed to find it? There should be a separator between Core
features and plugins. User must easily find, configure, enable/disable them.

P.S. I am asking everyone to add own concerns so we'll be able to make a
plan how to address them.

Thank you in advance.


[1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation
[2] https://github.com/stackforge/fuel-plugins
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][Plugins] Plugins on separate launchpad projects

[Sheena Gregson]

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 Kalnitsky; OpenStack Development Mailing List (not for usage
questions)
*Subject:* Re: [openstack-dev] [Fuel][Plugins] Plugins on separate
launchpad projects



Igor, thanks for your comments. Please see below.

Patrick

On 25 Jul 2015 at 13:08:24, Igor Kalnitsky (ikalnit...@mirantis.com) wrote:

Hello Patrick,

Thank you for raising this topic. I think that it'd be nice to create
a separate projects for Fuel plugins if it wasn't done yet.

Yes there is a launchpad project for fuel plugins although it’s currently
not possible to create blueprints in that project.

But that’s not what I meant. I meant dedicated projets for each fuel
plugins or for a group of fuel plugins if desired.

For example a project for LMA series of fuel plugins.

Fuel
plugins have different release cycles and do not share core group. So
it makes pretty much sense to me to create separate projects.

Correct. We are on the same page.



Otherwise, I have no idea how to work with LP's milestones since again
- plugins have different release cycles.

Thanks,
Igor

On Fri, Jul 24, 2015 at 8:27 PM, Patrick Petit  wrote:
> Hi There,
>
> I have been thinking that it would make a lot of sense to have separate
> launchpad projects for Fuel plugins.
>
> The main benefits I foresee….
>
> - Fuel project will be less of a bottleneck for bug triage and it should
be
> more effective to have team members do the bug triage. After all, they are
> best placed to make the required judgement call.
> - A feature can be spread across multiple plugins, like it’s the case with
> LMA toolchain, and so it would be better to have a separate project to
> regroup them.
> - It is counter intuitive and awkward to create blueprints for plugins in
> Fuel project itself in addition to making it cluttered with stuffs that
> unrelated to Fuel.
>
> Can you please tell me what’s your thinking about this?
> Thanks
> Patrick
>
> --
> Patrick Petit
> Mirantis France
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.

[Sheena Gregson]

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-library, FFE please, we don't use any of those tags. No need to spam
> Keystone team too, as it's configuration related to Fuel only at this point
> of time.
>
> Thank you,
>
> On Thu, Jul 23, 2015 at 10:50 AM Alexander Makarov 
> wrote:
>
>>
>> -- Forwarded message --
>> From: Alexander Makarov 
>> Date: Thu, Jul 23, 2015 at 5:30 PM
>> Subject: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for
>> Fernet tokens support.
>> To: Vitaly Sedelnik , Eugene Bogdanov <
>> ebogda...@mirantis.com>, Igor Marnat , Ilya
>> Elterman , Mike Scherbakov <
>> mscherba...@mirantis.com>, Roman Alekseenkov 
>>
>>
>> Colleagues,
>>
>> I would like to request an exception from the Feature Freeze for Fernet
>> tokens support added to the fuel-library in the following CR:
>> https://review.openstack.org/#/c/201029/
>>
>> Keystone part of the feature is implemented in the upstream and the
>> change impacts setup configuration only.
>>
>> Please, respond if you have any questions or concerns related to this
>> request.
>>
>> Thanks in advance.
>>
>> --
>> Kind Regards,
>> Alexander Makarov,
>> Senior Software Developer,
>>
>> Mirantis, Inc.
>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>
>> Tel.: +7 (495) 640-49-04
>> Tel.: +7 (926) 204-50-60
>>
>> Skype: MAKAPOB.AJIEKCAHDP
>>
>>
>>
>> --
>> Kind Regards,
>> Alexander Makarov,
>> Senior Software Developer,
>>
>> Mirantis, Inc.
>> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>>
>> Tel.: +7 (495) 640-49-04
>> Tel.: +7 (926) 204-50-60
>>
>> Skype: MAKAPOB.AJIEKCAHDP
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> Mike Scherbakov
> #mihgen
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel] SSL feature status

[Sheena Gregson]

I believe the last time we discussed this, the majority of people were in
favor of enabling SSL by default for all public endpoints, which would be
my recommendation.



As a reminder, this will mean that users will see a certificate warning the
first time they access the Fuel UI.  We should document this as a known
user experience and provide instructions for users to swap out the
self-signed certificates that are enabled by default for their own internal
CA certificates/3rd party certificates.



*From:* Mike Scherbakov [mailto:mscherba...@mirantis.com]
*Sent:* Wednesday, July 22, 2015 1: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, 2015 at 11:06 PM Stanislaw Bogatkin 
wrote:

Hi,



we have a spec that says we disable SSL by default and it was successfully
merged with that, no one was against such decision. So, if we want to
enable it by default now - we can. It should be done as a part of our usual
process, I think - I'll create a bug for it and fix it.



Current status of feature is next:

1. All codebase for SSL is merged

2. Some tests for it writing my QA - not all of them are done yet.



I'll update blueprints as soon as possible. Sorry for inconvenience.



On Mon, Jul 20, 2015 at 8:44 PM, Mike Scherbakov 
wrote:

Hi guys,

did we enable SSL for Fuel Master node and OpenStack REST API endpoints by
default? If not, let's enable it by default. I don't know why we should not.



Looks like we need to update blueprints as well [1], [2], as they don't
seem to reflect current status of the feature.



[1] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints

[2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints



Stas, as you've been working on it, can you please provide current status?



Thanks,



-- 

Mike Scherbakov
#mihgen



-- 

Mike Scherbakov
#mihgen
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev