[openstack-dev] [api] [cinder] backup restore in api v2

[Artem Goncharov]

Hi all,

I have recently faced an interesting question: is there no backup restore
functionality in block-storage api v2? There is possibility to create
backup, but not to restore it according to
https://developer.openstack.org/api-ref/block-storage/v2/index.html#backups-backups.
Version v3 ref contain restore function. What is also interesting, that
cinderclient contain the restore function for v2. Is this just a v2
documentation bug (what I assume) or was it an unsupported function in v2?

Thanks,
Artem
__
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] [sdk] Propose adding Dmitry Tantsur to openstacksdk-core

[Artem Goncharov]

+1

On Fri, 10 Aug 2018, 14:06 Monty Taylor,  wrote:

> Hey everybody,
>
> I'd like to propose Dmitry Tantsur (dtantsur) as a new openstacksdk core
> team member. He's been diving in to some of the hard bits, such as
> dealing with microversions, and has a good grasp of the resource/proxy
> layer. His reviews have been super useful broadly, and he's also helping
> drive Ironic related functionality.
>
> Thoughts/concerns?
>
> Thanks!
> Monty
>
> __
> 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] [openstackclient][openstacksdk] why does openstackclient rely on openstacksdk for get a network client

[Artem Goncharov]

Hi,

No. Not right. Idea is to unify CLI for all projects inside of the
python-openstackclient and obsolete all individual python-XXXclients. This
can be achieved by using the openstacksdk. Network module was just first in
the row, where the progress stucked a bit.

Regards,


On Tue, Jun 19, 2018 at 6:15 PM, 李健  wrote:

> Hello everyone
> ---
> CentOS Linux release 7.3.1611
> OpenStack Version: Newton
> # rpm -qa | egrep "(openstacksdk|openstackclient)"
> python-openstackclient-3.2.1-1.el7.noarch
> python2-openstacksdk-0.9.5-1.el7.noarch
> 
> The openstack CLI is implemented by python-openstackclient.
> In the python-openstackclient package, the function make_client(instance)
> is used to obtain the client for each service (openstackclient/xxx/client.py),
> I noticed that almost all core services are import their own
> python2-xxxclient to get the client, for example:
> image/client.py --> import glanceclient.v2.client.Client
> compute/client.py --> import novaclient.client
> volume/client.py --> import cinderclient.v2.client.Client
>
> But only the network service is import openstacksdk to get the client, as
> follows:
> network/client.py --> import openstack.connection.Connection
>
> So, my question is, why does the network service not use the
> python2-neutronclient to get the client like other core projects, but
> instead uses another separate project(openstacksdk)?
> My personal opinion, openstacksdk is a project that can be used
> independently, it is mainly to provide a unified sdk for developers, so
> there should be no interdependence between python-xxxclient and
> openstacksdk, right?
>
> For any help, thks
>
>
> __
> 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-dev] [all][sdk] Integrating OpenStack and k8s with a service broker

[Artem Goncharov]

Hi Zane,

> Would you be interested in working on a new project to implement this
> integration? Reply to this thread and let's collect a list of volunteers
> to form the initial core review team.

Yes, I would also like to join. That's exactly what I am looking at in my
company as part of K8 over OpenStack offering.

Regards,
Artem
__
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] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Artem Goncharov]

Thanks a lot Michael.

On Fri, 27 Apr 2018, 19:57 Michael Johnson, <johnso...@gmail.com> wrote:

> Hi Artem,
>
> You are correct that the API reference at
> https://developer.openstack.org/api-ref/network/v2/index.html#pools is
> incorrect. As you figured out, someone mistakenly merged the long
> dead/removed LBaaS v1 API specification into the LBaaS v2 API
> specification at that link.
>
> The current, and up to date load balancing API reference is at:
> https://developer.openstack.org/api-ref/load-balancer/v2/index.html
>
> This documents the Octavia API which is a superset of the the LBaaS v2
> API, so it should help you clarify any issues you run into.
>
> That said, due to the deprecation of neutron-lbaas and spin out from
> neutron we decided to explicitly not support neutron-lbaas in the
> OpenStack Client. neutron-lbaas is only supported using the neutron
> client.  You can continue to use the neutron client CLI with
> neutron-lbaas through the neutron-lbaas deprecation cycle.
>
> When you move to using Octavia you can switch to using the
> python-octaviaclient OSC plugin.
>
> Michael
>
> On Wed, Apr 25, 2018 at 5:51 AM, Artem Goncharov
> <artem.goncha...@gmail.com> wrote:
> > Hi all,
> >
> > after working with OpenStackSDK in my cloud I have found one difference
> in
> > the Neutron LBaaS (yes, I know it is deprecated, but it is still used).
> The
> > fix would be small and fast, unfortunately I have faced problems with the
> > API description:
> > - https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
> > that the LB pool has healthmonitor_id attribute (what eventually also
> fits
> > reality of my cloud)
> > - https://developer.openstack.org/api-ref/network/v2/index.html#pools
> (which
> > is referred to from the previous link in the deprecation note) describes,
> > that the LB pool has healthmonitors (and healthmonitors_status) as list
> of
> > IDs. Basically in this regards it is same as
> > https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
> > - unfortunately even
> >
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
> > describes Pool.healthmonitors (however it also contains
> >
> https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
> > sample with the Pool.healthmonitor_id)
> > - OpenStackSDK contains network.pool.health_monitors (with underscore)
> >
> > I want to bring this all in an order and enable managing of the
> loadbalancer
> > through OSC for my OpenStack cloud, but I can't figure out what is the
> > correct behavior here.
> >
> > Can anybody, please, help in figuring out the truth here?
> >
> > Thanks,
> > Artem
> >
> >
> __
> > 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-dev] [api] [lbaas] Neutron LBaaS V2 docs incompatibility

[Artem Goncharov]

Hi all,

after working with OpenStackSDK in my cloud I have found one difference in
the Neutron LBaaS (yes, I know it is deprecated, but it is still used). The
fix would be small and fast, unfortunately I have faced problems with the
API description:
- https://wiki.openstack.org/wiki/Neutron/LBaaS/API_2.0#Pools describes,
that the LB pool has *healthmonitor_id* attribute (what eventually also
fits reality of my cloud)
- https://developer.openstack.org/api-ref/network/v2/index.html#pools
(which
is referred to from the previous link in the deprecation note) describes,
that the LB pool has *healthmonitors* (and *healthmonitors_status*) as list
of IDs. Basically in this regards it is same as
https://wiki.openstack.org/wiki/Neutron/LBaaS/API_1.0#Pool description
- unfortunately even
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/lbaas-v2.inc
describes
*Pool.healthmonitors* (however it also contains
https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/samples/lbaas/pools-list-response2.json
sample
with the *Pool.healthmonitor_id*)
- OpenStackSDK contains *network.pool.health_monitors* (with underscore)

I want to bring this all in an order and enable managing of the
loadbalancer through OSC for my OpenStack cloud, but I can't figure out
what is the correct behavior here.

Can anybody, please, help in figuring out the truth here?

Thanks,
Artem
__
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