On Mon, Jun 6, 2016 at 7:18 PM, Ihar Hrachyshka <[email protected]> wrote:
> > > On 06 Jun 2016, at 16:44, Sean M. Collins <[email protected]> wrote: > > > > I agree, it would be convenient to have something similar to what Nova > > has: > > > > > https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/versions.py#L59-L60 > > > > We should put some resources behind implementing micro versioning and we > > could end up with something similar. > > > > It would also be nice to have the agents report their version, so it > > bubbles up into the agent-list REST API calls. > > Agents already report a list of object versions known to them: > > > https://github.com/openstack/neutron/blob/master/neutron/db/agents_db.py#L258 > > In theory, we can deduce the version from there. The versions are reported > through state reports. Not sure if it’s exposed in API. > In my case I mostly need to know the version of neutron server, in particular if it's still Mitaka or Newton already. This is what Dan's concern is about in https://review.openstack.org/#/c/246910/: if we're upgrading cluster from Mitaka to Newton and at some point have nova upgraded but neutron still of Mitaka version, than live migration will be broken (nova will wait for event which neutron does not send). But if we can know neutron version we can solve the issue. > > Ihar > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
